- 01Standard Contractual Clauses alone do not legitimize a non-adequate transfer post-Schrems II — a TIA documenting the importer's legal environment and supplementary measures is mandatory.
- 02EDPB Recommendations 01/2020 set the structure: six steps, evidence trail required at each, conclusion must be defensible to a regulator who has read the local surveillance laws.
- 03Three supplementary measures consistently move 'high residual risk' to 'acceptable': customer-held encryption keys, EEA-held re-identification material, and split-knowledge architectures.
- 04Generic 'encrypted at rest and in transit' language is the most cited boilerplate in EDPB enforcement — it is treated as no measure at all.
- 05EU–US Data Privacy Framework (2023) is helpful for self-certified US importers but does not eliminate the TIA — onward transfers and access by US authorities still require analysis.
After the CJEU's Schrems II decision in 2020 and the EDPB's Recommendations 01/2020, exporting personal data from the EEA requires more than Standard Contractual Clauses. Controllers must conduct a Transfer Impact Assessment (TIA) that examines the importer's local legal environment and the supplementary measures in place.
Five years on, regulators have built up a body of enforcement that tells us, in practical terms, what a defensible TIA looks like — and what kind of document earns a fine. This piece is the field guide for the CISO who has to sign the TIA, the GRC engineer who has to assemble it, and the platform engineer who has to ship the supplementary measures.
The 2023 EU–US DPF did not retire the TIA.
The EU–US Data Privacy Framework reinstated an adequacy bridge for self-certified US recipients — but only for the data the recipient processes under the framework. Onward transfers, sub-processors outside the framework, and bulk-access by US authorities under FISA 702 still require a TIA. Treat DPF as a useful input, not a substitute.
The six EDPB steps — and what each one is really asking
Recommendations 01/2020 prescribe a six-step methodology. Each step is an evidence checkpoint that an enforcement authority will reconstruct independently if they audit you. Below is the operational interpretation of each step.
Step 3 is where most TIAs collapse.
Regulators ask for the local-law analysis first because it is the easiest place to detect boilerplate. A TIA that cites 'US law generally' instead of FISA 702 + EO 12333 + the relevant CLOUD Act provisions is treated as evidence of inadequate diligence. Cite specific statutes by section number.
/EDPB_TIA_STEPS
| Step | Question to answer | Required artifact |
|---|---|---|
| 1 · Map | Where exactly is the data going, and via which sub-processors? | Data flow diagram + sub-processor list with jurisdictions |
| 2 · Identify transfer tool | SCC, BCR, derogation, or adequacy decision? | Executed contract + adequacy reference |
| 3 · Assess effectiveness | Does local law allow disproportionate access by authorities? | Local-law analysis with citations to specific statutes |
| 4 · Supplementary measures | What technical / contractual / organizational measures are in place? | Architecture description + measure-to-risk mapping |
| 5 · Procedural steps | Are SCCs amended, BCRs updated, contracts re-papered? | Signed addendums + version history |
| 6 · Re-evaluate | How often will this analysis be refreshed? | Documented review cadence + change-trigger list |
Supplementary measures that move the residual-risk verdict
Across our 2023–2025 TIA work for EEA controllers, three categories of measure consistently moved the EDPB's effectiveness verdict from 'insufficient' to 'sufficient'. The pattern: the importer must be technically incapable of producing usable plaintext to its local authorities, even under compulsion.
- 01Customer-held encryption keys — keys generated and stored in an EEA-located KMS or HSM under the controller's exclusive operational control. The importer holds ciphertext only; an order against the importer cannot compel decryption that the importer cannot perform.
- 02EEA-held re-identification material — pseudonymized data is exported, but the lookup table mapping pseudonyms to identities never leaves the EEA. The importer's view of any record is incapable of identifying a data subject without information they do not possess.
- 03Split-knowledge / multi-party computation — the data is sharded across two or more importers in different jurisdictions, with no single party holding enough to reconstruct the record. Effective for analytics workloads where joins happen under MPC protocols.
What does NOT count as a supplementary measure.
Provider-managed encryption (BYOK with the provider holding HSM access), encryption applied by the importer to data that the importer can also decrypt, and 'transparency reports' from the importer are all explicitly identified by the EDPB as insufficient on their own. They are useful as defense in depth — never as the load-bearing control.
A reference architecture for the customer-held-key pattern
The most-deployed supplementary measure we ship in 2026 is the customer-held-key pattern with an EEA HSM. Below is the simplified topology — the importer never sees plaintext for any record under the regime.
/REF_ARCH · customer-held-key (EEA → US importer)
[ EU Controller (EEA) ]
│
├──► [ EEA HSM / KMS ] (key never leaves EEA)
│ │ envelope-encrypts payload
│ ▼
└──► [ US Importer (processor) ] (sees ciphertext only)
│
▼
processing on ciphertext or
confidential-compute enclave
│
▼
result re-encrypted to EU controller
│
▼
[ EU Controller decrypts via EEA HSM ]
# Compulsion model:
# Order against US importer → ciphertext returned → useless.
# Order against EU controller → governed by EU law, GDPR Art. 48
# blocks third-country authority orders.
The boilerplate that earns fines — concrete examples
Across CNIL, the Irish DPC, the Dutch AP, and the Berlin BlnBDI enforcement decisions, four specific TIA boilerplate patterns recur in fining decisions. Treat the appearance of any of them in a draft TIA as a structural defect, not a wording issue.
- 01'All data is encrypted in transit and at rest' — used without specifying who holds the keys; treated as no measure
- 02'The processor undertakes to challenge any unlawful access requests' — contractual-only measure; cannot bind a foreign authority
- 03'Risk is acceptable in light of business need' — without quantified risk + supplementary measures, treated as inadequate diligence
- 04'US law provides comparable protections' — without specific statutory analysis, treated as evidence the controller did not perform Step 3
TIA as a living document — the review cadence
Step 6 is the step most TIAs ignore until enforcement arrives. The EDPB expects TIAs to be re-examined when the local legal landscape changes (e.g., a new surveillance statute, a new CJEU ruling), when the architecture changes (a new sub-processor, a new region), and on a defined periodic cadence regardless.
/TIA_REVIEW_TRIGGERS
| Trigger | Window | Action |
|---|---|---|
| New CJEU ruling on transfers | 30 days | Re-run Step 3 + Step 4 |
| New sub-processor added | Before go-live | Full TIA delta + addendum |
| New importer jurisdiction | Before transfer | New TIA per importer |
| Periodic review (no trigger) | 12 months | Light refresh + re-sign |
| Local surveillance law change | 60 days | Re-run Step 3 |
A 60-day plan to bring your TIAs to enforcement-grade
- 01Days 0–14 — Inventory every cross-border transfer involving EEA personal data. Bucket by destination jurisdiction and importer category (intra-group, processor, sub-processor). Most controllers find 30–60% more transfers than they expected.
- 02Days 14–35 — For each high-volume / high-sensitivity transfer, build the TIA properly using the six-step structure. Cite specific statutes in Step 3. Document supplementary measures in engineering detail in Step 4.
- 03Days 35–50 — Implement the customer-held-key or pseudonymization-with-EEA-keymap measure for the top three risky transfers identified in the prior phase.
- 04Days 50–60 — Stand up the review cadence and trigger registry. Tie each TIA to an owner with a calendar reminder; tie the trigger registry to your legal team's case-law tracker.
Monday morning — the one-question test for your existing TIAs.
Open any current TIA. Find Step 3. If the local-law analysis cites at least three specific statute or section numbers from the importer's jurisdiction and explains why each is or is not disproportionate, the TIA is on track. If it cites 'US law' or 'India's data protection regime' generically, the TIA will not survive a regulator audit and needs rebuilding before the next enforcement window.
- ▸Pull a sample of three TIAs at random
- ▸Confirm Step 3 has specific statutory citations
- ▸Confirm Step 4 names the engineering measure, not the marketing label
- ▸If either fails for any TIA in the sample, all TIAs need a re-examination pass
Closing — the TIA is engineering AND law
The single biggest reason TIAs fail is that they are written by lawyers without an engineer in the room — or by engineers without a lawyer. A defensible TIA fuses both views: a precise local-law citation and a precise architectural description, joined by an explicit risk argument. Build the document together, refresh it on a cadence, and the next regulator inquiry becomes a straightforward exchange instead of a fining decision.