Transfer Impact Assessment (TIA): Step-by-Step GDPR Guide

The Transfer Impact Assessment (TIA) is the most under-implemented requirement of the GDPR international transfer regime. Following the Schrems II judgment (CJEU C-311/18, 16 July 2020), the EDPB issued Recommendations 01/2020 mandating a six-step assessment for any transfer to a non-adequate third country relying on Standard Contractual Clauses, Binding Corporate Rules, or other Article 46 safeguards. The CNIL has sanctioned multiple controllers in 2024-2025 for missing or perfunctory TIAs.

This guide walks through each of the six steps with concrete examples, country risk profiles, and a downloadable template structure. It covers the practical decisions: when the TIA is mandatory, how to assess US surveillance laws, what supplementary measures actually work, and how to operationalize annual reassessment.

For the SCC framework, see Standard Contractual Clauses GDPR guide. For mechanism comparison, BCR vs SCC vs DPF.

Key takeaways

• The TIA is mandatory under Article 46 GDPR + Schrems II for any transfer to a non-adequate third country.
• The EDPB six-step methodology is the de facto standard; deviating without justification creates regulatory risk.
• The most consequential step is Step 3 (assessing third country law) — most TIAs fail here because of generic country boilerplate.
• Supplementary measures are the only fallback when third country law is problematic. Technical measures (encryption with exporter-held keys) outperform contractual or organizational ones.
• TIAs must be reassessed annually and immediately when the third country’s legal landscape changes.

1. When is a TIA mandatory?

The TIA is required when all four conditions are met:

1. Data subject to GDPR (controller or processor in EU/EEA, or non-EU controller targeting EU residents)
2. Data transferred to a recipient in a third country
3. The third country has no adequacy decision
4. The transfer relies on Article 46 safeguards (SCCs, BCRs, codes of conduct, certification)

The TIA is not required for:

• Transfers to adequate countries (UK, Switzerland, Canada commercial, Japan, New Zealand, Argentina, Israel, Uruguay, Andorra, Faroe Islands, Guernsey, Isle of Man, Jersey)
• Transfers to US recipients self-certified under the EU-U.S. Data Privacy Framework
• Transfers based on Article 49 derogations (consent, contract performance, important public interest) — note these are narrowly interpreted

2. Step 1 — Know your transfers

The TIA presupposes a complete inventory. Information required per transfer:

• Data exporter (legal entity, country, role: controller/processor)
• Data importer (legal entity, country, role)
• Data categories (identifiers, contact data, financial, health, etc.)
• Special categories (Article 9) flagged separately
• Volume and frequency
• Purpose of the transfer
• Onward transfers (importer’s sub-processors)
• Retention period
• Existing safeguards (SCCs version, BCR, certification)

For most companies, this inventory does not exist. Building it is the gateway: 80% of TIA work is preliminary mapping. Tools that read DPAs and infer transfer flows accelerate this dramatically.

3. Step 2 — Identify the transfer tool

Determine which Article 46 safeguard applies:

Safeguard	Article	Use case
Standard Contractual Clauses	46(2)©	Most common, off-the-shelf
Binding Corporate Rules	46(2)(b)	Intra-group transfers within multinationals
Approved Code of Conduct	46(2)(e)	Sector-specific (rare)
Approved Certification	46(2)(f)	DPF for US (formal mechanism)
Ad hoc clauses approved by SA	46(3)(a)	Tailor-made (slow approval)

Each safeguard has its own TIA implications. For SCCs, the TIA examines whether the standardized clauses can be enforced. For BCRs, the TIA examines whether group-wide policies hold up against third country surveillance.

4. Step 3 — Assess the third country law

This is where most TIAs fail. The assessment must examine:

4.1 Public authority access laws

• Is there a legal basis for government access to data held by private entities?
• What is its scope (national security, criminal investigation, intelligence)?
• Are there proportionality and necessity safeguards?
• Is there independent oversight?
• Are there data subject redress mechanisms?

For the United States: FISA Section 702 (surveillance of non-US persons), Executive Order 12333 (signals intelligence), CLOUD Act (extraterritorial production orders). All are problematic under Schrems II benchmarks unless the recipient is DPF-certified.

For China: Cybersecurity Law, Data Security Law, Personal Information Protection Law (PIPL) — broad government access powers, weak judicial oversight, no data subject redress for foreigners.

For India: Telegraph Act, IT Act amendments — government interception with limited oversight.

For Russia: Federal Law 374-FZ (Yarovaya laws) — mass data retention obligations.

4.2 Practical assessment sources

• EDPB country guidance (when available)
• DLA Piper Data Protection Laws of the World
• Privacy International country profiles
• Schrems II benchmarks (proportionality, redress, independence of oversight)
• Recent court rulings and DPA findings

4.3 Output of Step 3

Document for each destination country:

• Which national laws are problematic
• Which Schrems II benchmarks they fail
• Specific risk for the data categories transferred

Generic statements like “the US has surveillance laws” are insufficient. The assessment must be specific to the data and the recipient.

5. Step 4 — Supplementary measures

If Step 3 finds problematic laws, supplementary measures must close the gap.

5.1 Technical measures (most effective)

Measure	Effectiveness	Scenario
End-to-end encryption with exporter-held keys	High	Cloud storage, content delivery
Pseudonymization with re-identification keys held only in EU	High	Analytics, AI model training
Split processing (data never reassembled outside EU)	High	Distributed processing
Encryption in transit (TLS) only	Low	Insufficient on its own
Encryption at rest with importer-held keys	Low	Importer can be compelled to decrypt

5.2 Contractual measures (limited effectiveness)

• Notification of government access requests (where legally permitted)
• Transparency reports
• Audit rights
• Indemnification clauses

These help but cannot override third country law. A contractual obligation to notify the exporter of a FISA 702 order is void under US law (which prohibits disclosure).

5.3 Organizational measures

• Data minimization (transfer only what’s strictly necessary)
• Access controls and segregation
• Privacy-enhancing technologies (PETs)
• Internal policies on government request response

The combination test: a transfer is defensible only if the technical measures would protect data even if compelled disclosure occurred. Contractual and organizational measures alone are not sufficient for high-risk countries.

6. Step 5 — Procedural steps

Implement the supplementary measures. Document:

• Decision rationale
• Implementation date
• Responsible function
• Verification method

Sign the SCCs, BCRs, or other safeguard. Update Annex II of the SCCs to reflect supplementary technical measures.

7. Step 6 — Re-evaluate at intervals

Triggers for reassessment:

• New laws in the destination country
• New transparency reports (especially if access volumes increased)
• New court rulings (e.g., national security cases)
• Change in processing scope
• Change in vendor or sub-processor

Minimum cadence: annual. Some teams build a quarterly review for high-risk transfers.

8. TIA template structure

A defensible TIA document contains:

1. Executive summary — recipient, country, transfer purpose, decision
2. Transfer inventory — Step 1 output
3. Safeguard mechanism — Step 2 output (which SCC module, etc.)
4. Third country assessment — Step 3 output, with citations
5. Risk analysis — likelihood × impact for each data category
6. Supplementary measures — Step 4 output, technical/contractual/organizational
7. Decision and approval — go/no-go decision, signatory, date
8. Monitoring plan — Step 6 output, review cadence
9. Annexes — country law extracts, technical specifications, contracts

Length: 8 to 25 pages depending on complexity. A two-page boilerplate is not a TIA.

9. Practical case: SaaS analytics with US sub-processor

EU controller (e-commerce, 50,000 customers) uses an EU-based analytics vendor that sub-processes anonymized aggregates with a US AI vendor (not DPF-certified).

Step 1: data = pseudonymized event logs (no direct identifiers), purpose = traffic analysis, frequency = continuous, retention = 90 days at vendor, 24h at sub-processor.

Step 2: SCCs Module 3 (processor-to-processor) between EU vendor and US sub-processor.

Step 3: US recipient subject to FISA 702. Risk depends on data identifiability. With only pseudonymized aggregates, no direct identifiers, content of FISA orders unlikely to reveal individuals.

Step 4: technical measures = pseudonymization with keys held only by EU vendor; aggregation before transfer (statistical level only).

Step 5: SCCs signed. Annex II documents pseudonymization protocol.

Step 6: annual reassessment. Triggers: any change in data sent to sub-processor.

Decision: defensible.

10. Practical case: HR system with India support

EU controller (200 employees) uses an HR SaaS with support team in India accessing employee records (identifiers, salary, evaluations).

Step 3: India has broad government access powers and weak data subject redress. Direct identifiers transferred = high risk.

Step 4: technical measures? End-to-end encryption is impractical (support team needs to read records). Pseudonymization possible but undermines support function.

Decision: transfer indefensible without changing the architecture. Options:

• Move support to an adequate country (EU, Canada commercial)
• Restructure access (Indian team only sees masked data, EU team sees full data)
• Find a vendor with EU-only support

This is the typical outcome of a rigorous TIA: it doesn’t always validate the transfer. Sometimes it forces architectural change.

11. Automating the TIA

The TIA process is repetitive across vendors. Legiscope generates TIA templates per destination country, ingests vendor responses, scores risks against EDPB criteria, and triggers reassessment alerts. For a company with 30+ international vendors, this turns the TIA from a project into a routine.

For the supporting framework, see Standard Contractual Clauses GDPR, BCR vs SCC vs DPF, and the cross-border transfers guide.

Conclusion

The TIA is not a checkbox. It is the only mechanism that operationalizes Schrems II at the controller level. Done rigorously, it forces architectural decisions about where data lives and who can access it. Done perfunctorily, it leaves the same exposure as no assessment at all — with the added burden of having documented the failure. The investment in a real TIA process pays back the first time a regulator asks for documentation, or the first time a vendor’s certification lapses.

FAQ

Is a TIA required for transfers under the EU-U.S. Data Privacy Framework?

No. Self-certification under the DPF replaces SCCs and the TIA for those specific transfers. However, best practice is to maintain SCCs and TIA documentation as fallback in case the DPF is challenged.

Can a TIA be a one-page document?

Almost never. A defensible TIA covers transfer mapping, third country assessment with citations, risk analysis, supplementary measures, and monitoring plan. This typically requires 8 to 25 pages depending on complexity.

What countries fail Schrems II benchmarks most clearly?

Beyond the US (without DPF), the most clearly problematic countries are China, Russia, India, and any country with broad national security access laws and weak data subject redress. The EDPB has not published a definitive list — assessment is per country, per transfer.

Who is responsible for the TIA — exporter or importer?

The exporter (data controller or processor in the EU). The importer can provide information, but the legal accountability rests with the exporter under Article 5(2) GDPR (accountability principle).

How long must I keep TIA documentation?

For the duration of the transfer plus a reasonable evidence retention period. Best practice: keep TIAs for at least 5 years after the transfer ends, since regulatory inquiries can occur retrospectively.