Cross-Border Transfer Under a New Adequacy Decision

Fact 1 (adequacy revocation for the sector) is the most decisive. If the destination no longer has adequacy for health-adjacent processing, the SCCs must carry the full weight - but SCCs alone are not a transfer mechanism that guarantees an essentially equivalent level of protection; they require a TIA that concludes the destination law and practices, plus supplementary measures, achieve that. A revocation that specifically targets the company's sector means the baseline assumption underlying the original TIA has changed. The transfer cannot continue on the old analysis without a fresh TIA.

Fact 2 (new sub-processor in an uncovered country) is a close second and is independently fatal: a sub-processor transfer to a country not assessed in the TIA is an unassessed transfer. It also likely breaches the SCC onward-transfer clause unless the same clauses flow down and the sub-processor is disclosed.

Fact 3 (encryption defeated in practice) undermines the supplementary measures. Encryption at rest is meaningless if feature files are written unencrypted to a shared bucket. The TIA's stated measure does not match operational reality, which means the TIA's conclusion is unsupported.

Fact 4 (two declined requests) is relevant but not decisive. Declined requests are evidence of effective legal resistance, but they do not prove the absence of government access, and the company cannot rely on the subsidiary's own log as complete. It is a data point for the TIA, not a safe harbor.

Bottom line: the transfer should be suspended or restructured pending a new TIA. Facts 1–3 each independently break the current basis; Fact 1 sets the frame.

Encryption is a strong measure only when it holds under the threat model. Here it does not, for three reasons:

1. The pipeline decrypts in memory and writes plaintext features. The measure must cover the data as transferred and as processed, not just at rest. If the subsidiary can read plaintext, so can anyone with access to the subsidiary's environment - including a government compelled to produce it.
2. Key custody. If the subsidiary or its cloud provider holds the keys, encryption does not prevent access. The TIA should specify that keys remain with the EU exporter or a jurisdiction outside the recipient's reach.
3. The intermediate feature files are derived personal data. They may be re-identifiable. They must be in scope of the measure, not treated as a harmless byproduct.

What else the TIA must address:

• The new sub-processor and its country: assess that jurisdiction's access laws, add it to the SCC flow-down, and update the sub-processor list.
• The sector-specific adequacy change: reassess whether the destination still provides essentially equivalent protection for health-adjacent data, and document the reasoning.
• Government access: incorporate the request log as evidence but also assess the legal framework, not just observed requests.
• Onward transfers and redress: confirm the subsidiary's obligations and the availability of a redress mechanism for data subjects.
• Practical alternatives: pseudonymization before transfer, federated training that keeps raw data in the EU, or moving training to an adequate jurisdiction.

The auditor's point: a supplementary measure is only as good as its operational enforcement. A TIA that cites a control the pipeline bypasses is not a valid TIA.

A TIA is a snapshot; the transfer needs a living control. Require:

• Trigger-based review: a documented list of events that force a TIA refresh - adequacy changes, new sub-processors, new destination countries, changes to the processing pipeline, government-access requests, and legal developments. The sector adequacy revocation should have fired this trigger; the fact that it did not is itself a finding.
• Sub-processor register with country mapping, reconciled quarterly against the subsidiary's actual vendor list. The new third-country sub-processor should have appeared here before use.
• Technical conformance testing: periodic verification that the pipeline matches the TIA's stated measures - e.g., a test that feature files are encrypted and keys are held outside the recipient's control. This is a control test, not a policy review.
• Government-access log review with a defined threshold for escalation, plus confirmation that the log is complete (not self-reported only).
• Transfer register listing each flow, mechanism, TIA date, and next review date.
• DPO sign-off on each refresh, with the reasoning documented.

Verification approach: sample three transfers from the register, trace each to a current TIA and a sub-processor entry, and test one technical measure per transfer. If any transfer lacks a current TIA or a matching technical control, it is an open finding.