Library / Guides

Transfer Impact Assessment — A Working Guide

How to actually conduct and document a TIA without it becoming a multi-week consultancy engagement, plus what to do when the answer is "the residual risk is not acceptable."

8 min read

The Transfer Impact Assessment was created by the Court of Justice in 2020, formalised by the European Data Protection Board in Recommendations 01/2020, and has been a quiet source of friction for every privacy team since. The guidance is rigorous; the practice has had to compress that rigour into something that fits inside a vendor onboarding cycle.

This guide describes a working process — pragmatic, defensible, and reusable across vendors. It does not replace legal advice for high-risk transfers, but it covers the typical SaaS vendor flow.

The six EDPB steps, condensed

The EDPB's six-step methodology is comprehensive and worth reading once. In practice, it collapses into four operational steps:

  1. Map the transfer. What data, where, who, why.
  2. Identify the transfer mechanism. Adequacy, SCCs, BCRs, or derogation.
  3. Assess the destination. Law and practice in the importing country.
  4. Apply supplementary measures. Where the assessment found gaps.

If the residual risk after step 4 is acceptable, the transfer can proceed. If not, it cannot.

Step 1 — Map the transfer

The map answers four questions:

  • What data is being transferred? Categories of personal data, volume estimate, sensitivity, identifiability.
  • Who is the importer? The legal entity, where they are established, what their role is.
  • Where is the data going? Storage location, processing location, access location. Often three different places.
  • Why is it being transferred? Specific business purpose; not "operating the service."

A common failure here is undercounting. A vendor that hosts data in Frankfurt but has US-based engineering staff with production access is making two transfers — one storage transfer (none, the data stays in the EU) and one access transfer (continuous, every time an engineer connects).

Step 2 — Identify the transfer mechanism

Three viable options for systematic processing:

  • Adequacy decision. The destination has one. (See Adequacy Decision.)
  • SCCs. The 2021 modular set, with the correct module and annexes filled in.
  • BCRs. Approved by a supervisory authority. Not common in vendor relationships; more common in intra-group transfers.

The Article 49 derogations (consent, contract necessity, public interest, legal claims, vital interests) are not designed for systematic processing and shouldn't be the primary mechanism for an ongoing vendor relationship.

If the destination has an adequacy decision in force, you can stop here. The TIA is technically not required, though many controllers document a brief note for the file in case the decision is challenged.

Step 3 — Assess the destination

This is the difficult step. The question is whether the destination's law and practice provide protection essentially equivalent to GDPR for the data being transferred. The areas to evaluate:

  • Government access to data. What lawful intercept regimes exist? Does the importer face requests from law enforcement or intelligence services? Can the importer notify the data subject (or you) of such requests, or is there a gag order regime?
  • Data protection law. Does the country have one? How robust is enforcement?
  • Data subject rights. Can EU data subjects exercise rights against the importer?
  • Effective remedies. Can data subjects seek redress before independent authorities?

For the United States, the recurring concern is FISA section 702 and Executive Order 12333 — the surveillance regimes that Schrems II identified as inconsistent with EU equivalence absent supplementary measures. The EU-US Data Privacy Framework is the current bridge for participating organisations; non-participating US transfers still need full TIA + supplementary measures.

For most other non-adequate jurisdictions, the EDPB has not published a country-by-country assessment. Several private organisations publish jurisdictional analyses; these can be cited in the TIA as supporting material.

Step 4 — Apply supplementary measures

Where the assessment found gaps, the EDPB recommends technical, contractual, or organisational measures to close them:

Technical measures:

  • Encryption at rest with keys held only in the EEA. The strongest measure for storage transfers — even if the importer is compelled to disclose data, they cannot decrypt it.
  • Encryption in transit with strong endpoint authentication.
  • Pseudonymisation with the re-identification key held only by the exporter.
  • Split processing, where the importer never sees enough data to identify any individual.

Contractual measures:

  • Strict purpose limitation beyond what GDPR requires.
  • Audit rights with realistic scope.
  • Transparency about lawful access requests as far as the importer's law allows.
  • Notification of any change in the importer's ability to comply.

Organisational measures:

  • Internal access controls and need-to-know enforcement.
  • Clearance requirements for personnel handling the data.
  • Regular review of the importer's compliance posture.

The EDPB has been clear that contractual and organisational measures alone are usually insufficient where the importing country's surveillance regime is the concern — the importer can promise to resist a lawful intercept order, but cannot actually do so. The technical measures (specifically, encryption with EEA-held keys) carry most of the weight in those cases.

When the residual risk is not acceptable

The realistic answer when residual risk fails the test is to:

  1. Choose a different vendor with operations in an adequate jurisdiction.
  2. Choose a different deployment of the same vendor (some vendors offer EU-hosted, EU-staffed deployment options at premium tiers).
  3. Reduce the data being transferred — pseudonymise, anonymise, or simply send less.
  4. Stop the transfer.

It is rare to reach this point with a major SaaS vendor; the supplementary measures and the DPF (for US vendors) usually move the residual risk inside the acceptable range. But the option has to be on the table for the assessment to be honest.

The TIA is a living document

A TIA done at vendor onboarding is valid until something changes. Triggers for revisiting:

  • The vendor adds a subprocessor in a non-adequate jurisdiction.
  • The vendor moves operations to a new region.
  • The destination country's surveillance regime changes.
  • An adequacy decision is annulled or amended.
  • The data being transferred materially changes.

Most of these surface through subprocessor and policy monitoring. The TIA itself doesn't change automatically; it has to be reviewed and updated when one of these triggers fires.

How to write it down

A working TIA template:

1. Description of the transfer
   - Exporter (entity)
   - Importer (entity, location)
   - Data categories, volume, sensitivity
   - Purposes
   - Storage / processing / access locations

2. Transfer mechanism
   - Adequacy / SCCs (version, module) / BCRs / derogation
   - Date executed

3. Destination assessment
   - Law and practice
   - Government access regime
   - Sources consulted

4. Gaps identified

5. Supplementary measures applied
   - Technical
   - Contractual
   - Organisational

6. Residual risk assessment
   - Acceptable / not acceptable
   - Rationale

7. Review schedule and triggers

8. Sign-off
   - Reviewer, role, date

Two pages of substance, plus references. A TIA longer than that, for a typical SaaS vendor, is usually padding.

Related guides