The Support Team That Could See Everything

The draft is wrong to say 'no further steps are needed'. Map the flows:

1. EU customer → US company (controller-to-processor). Covered only if the SCC module and the parties' roles match (module two, controller-to-processor). The customer is not DPF-certified, so the customer's status is irrelevant - what matters is whether the US importer is DPF-certified. If the importer is certified and the transfer is within scope, DPF can be the mechanism; if not, SCCs apply. The draft conflates the two.
2. US company → Manila support team. This is an onward transfer to a third country. SCCs contain onward-transfer clauses requiring the importer to ensure the recipient is bound by equivalent obligations - typically by entering separate SCCs with the Manila entity or applying the same module. A TIA alone is not a transfer mechanism; it is the assessment that sits alongside one.
3. US hosting. If the US importer is DPF-certified, DPF may cover it; otherwise SCCs plus a TIA. The draft's blanket 'SCCs cover everything' ignores that SCCs must be executed between the right parties for each hop.

The gap: the Manila onward transfer likely lacks its own executed mechanism. TIAs being 'complete' does not substitute for a lawful transfer tool.

A TIA is not a formality; it must be specific to the flow and the law of the destination. For the Manila flow it should cover:

• Nature of the data and the transfer - including special-category data in free-text tickets, which raises the stakes.
• Relevant Philippine law and practice - the Data Privacy Act and, critically, the scope of government access: what powers exist for authorities to compel disclosure, whether there is independent oversight, redress, and whether the powers are proportionate and clearly defined.
• Practical likelihood of access given the data type and sector.
• Supplementary measures where the assessment shows gaps: strong encryption at rest and in transit with keys held outside the reach of the recipient where feasible; pseudonymisation or masking of special-category fields in the ticket UI; access controls and logging; a documented policy and training for handling government requests, including challenge/transparency where lawful; data minimisation so free-text fields do not become a data lake.
• A conclusion on whether the measures bring the transfer to an essentially equivalent level of protection - and if not, the transfer should not proceed.

The exam point: TIAs must be substantive and documented, and they must actually drive measures. A completed TIA that changes nothing is a red flag.

Sequence:

1. Validate the request. Is it lawful, in writing, properly scoped, and from a competent authority? A vague or overbroad request should be challenged.
2. Notify the controller (the EU customer) without undue delay, unless legally prohibited from doing so (e.g. a gag order). The SCCs require the importer to notify the exporter of legally binding requests and, where permitted, to challenge them.
3. Challenge or narrow where possible. Use available legal routes to resist disproportionate or overbroad requests; document the attempt.
4. Minimise disclosure. Provide only what is strictly required - not the whole ticket corpus.
5. Record everything. Keep an audit trail: the request, the assessment, the response, what was disclosed.
6. Escalate. If the request conflicts with the SCC obligations, the importer must notify the exporter and, if it cannot resolve the conflict, consider suspending the transfer.

The draft answer's silence on government access is the real weakness: SCCs and TIAs exist precisely because this scenario is foreseeable, and the response must be a documented, challenge-first process - not automatic compliance.