A Transfer Impact Assessment (TIA) is the documented analysis a data exporter carries out before moving personal data from the European Economic Area (EEA) to a third country on the basis of Standard Contractual Clauses (SCCs) or another Article 46 safeguard under the General Data Protection Regulation (GDPR). It answers one question honestly: will the data receive essentially equivalent protection in the destination country once local law and practice are taken into account, and if not, which supplementary measures close the gap.
The obligation is not spelled out under that name anywhere in the GDPR. It comes from a judgment of the Court of Justice of the European Union (CJEU), was written into the European Commission's 2021 SCCs as a contractual warranty, and was turned into a working method by the European Data Protection Board (EDPB). This walkthrough covers where the duty comes from, when you need a TIA, how to run the six-step assessment in practice, how to document it proportionately as a small or mid-sized enterprise (SME), and how to keep it accurate once vendors and their subprocessors start changing.
Where the duty comes from
In case C-311/18, better known as Schrems II, decided on 16 July 2020, the CJEU invalidated the EU-US Privacy Shield and confirmed that SCCs remain a valid transfer tool, with a significant condition attached. An exporter relying on SCCs must verify, case by case, whether the law and practice of the destination country allow the importer to actually comply with the clauses. Where they do not, the exporter must adopt supplementary measures, and where no measures help, it must suspend or end the transfer.
The European Commission then embedded the assessment into the modernized SCCs, Implementing Decision (EU) 2021/914, adopted on 4 June 2021. In Clause 14, the parties warrant that they have no reason to believe that the laws and practices in the third country of destination prevent the importer from fulfilling its obligations, and they declare that this warranty rests on an assessment of the specific circumstances of the transfer. Clause 14(d) requires the parties to document that assessment and make it available to the competent supervisory authority on request. Signing the 2021 SCCs without a documented TIA therefore means giving a warranty you cannot evidence.
The EDPB's Recommendations 01/2020 on supplementary measures, adopted in their final version in June 2021, translate the judgment into a six-step method. They are the closest thing to an official TIA manual, and their structure is what most supervisory authorities will recognize when they ask to see your assessment.
When you need a TIA, and when you do not
The trigger is reliance on an Article 46 transfer tool. Three situations cover most vendor relationships.
- Transfers covered by an adequacy decision do not require a TIA, because the European Commission has already made the equivalence finding for that destination. You should still track whether the decision remains in force, since adequacy decisions can be reviewed, amended, or invalidated.
- Transfers based on SCCs or Binding Corporate Rules (BCRs) require an assessment. For SCCs, Clause 14 makes it a contractual warranty rather than a best practice.
- Transfers based on the derogations in Article 49 sit outside the TIA framework, but they are designed for occasional, specific situations and cannot carry a routine software-as-a-service (SaaS) relationship.
The duty also reaches transfers you do not make yourself. If your processor in the EEA passes personal data to a subprocessor in a third country, that leg needs a valid transfer tool and an assessment behind it, and as controller you remain accountable for the whole chain. What to do when a subprocessor moves data outside the EEA is covered in a separate article; for TIA purposes, the point is that your transfer map must include those onward legs from the start.
The six steps in practice
The EDPB method is sequential, and each step produces something you can write down. Worked through honestly, it is less effort than it looks, because most SaaS transfers share the same structure and the analysis compounds.
Step 1: know your transfers
Map every flow of personal data out of the EEA, including onward transfers by processors and their subprocessors. The practical sources are your Data Processing Agreements (DPAs) and their annexes, vendor subprocessor lists, and hosting or security documentation. This step sounds trivial and is where most programs actually fail: you cannot assess a transfer you have not identified, and subprocessor chains are where unnoticed transfers live.
Step 2: identify the transfer tool
For each transfer, record what it relies on: an adequacy decision, SCCs and the module that fits the relationship, BCRs, or, exceptionally, a derogation. Transfers already covered by adequacy exit the process here. Everything riding on Article 46 continues to step 3. Knowing what belongs in the underlying Article 28 contract helps at this point, because a well-drafted DPA and its annexes should already name the tool for each leg.
Step 3: assess the law and practice of the destination country
This is the core of the TIA. The question is whether anything in the destination country's law, or in the way that law is applied in practice, undermines the protections the transfer tool promises. The focus areas are public authority access to data, in particular surveillance powers, and whether people in the EU have enforceable rights and effective redress. The EDPB expects the analysis to rest on objective sources such as legislation, case law, and reports from credible institutions, and it accepts that documented practical experience of the importer with government access requests can play a role under conditions. The assessment must be specific to the transfer: the categories of data, the sector, whether data is stored in the destination or only accessed remotely from it, and the technical form the data takes all change the answer.
Step 4: identify and adopt supplementary measures
If step 3 identifies a problem, the transfer can only proceed with measures that close the gap. Technical measures do the heavy lifting: encryption where the keys stay with the exporter in the EEA, and pseudonymization where the additional information needed to re-identify people remains in Europe. Contractual and organizational measures, such as transparency commitments and strict internal access policies, can reinforce technical ones but rarely stand alone. The Recommendations are candid that some scenarios have no effective measures: if the importer needs access to data in the clear and the destination's law compels disclosure, contractual promises cannot fix that, and the honest outcome is not to transfer.
Step 5: take the procedural steps
Whatever measures you adopt must be put into effect formally. Supplementary measures can be added alongside the SCCs as long as they do not contradict the clauses. Update the DPA annexes and the technical documentation so the measures are contractually anchored rather than informal, and record who approved the conclusion and on what basis.
Step 6: re-evaluate at appropriate intervals
A TIA is a snapshot. The Recommendations require monitoring developments in the destination country and re-running the assessment at appropriate intervals. Clause 14 supports this from the contract side: the importer must notify the exporter if it has reason to believe it can no longer comply, and the exporter must then identify further measures or suspend the transfer. Build the re-evaluation trigger into your vendor-review cycle rather than leaving it as a standing good intention.
Documenting proportionately as an SME
Nothing in the judgment or the Recommendations prescribes a format, and the depth of a TIA can be proportionate to the transfer it covers. An SME does not need a lengthy country study for every routine SaaS vendor. A defensible short-form TIA states the parties and their roles, the categories of data and data subjects, the destination country, the transfer tool, the law-and-practice analysis relied on, the supplementary measures in place, the conclusion, the owner, the date, and the next review date. A short assessment done specifically is worth more than a long one pasted generically. How the wider framework lands for smaller organizations is covered in Schrems II in practice for SMEs.
Reuse is legitimate when it is honest. If ten transfers go to the same destination country under the same tool, the country-level analysis can be shared across them. What cannot be shared is the transfer-specific layer: data categories, access patterns, and measures differ by vendor, and Clause 14 ties the warranty to the specific circumstances of each transfer.
Keeping a TIA current when subprocessors change
TIAs age in two ways. The destination's law and practice can change, which step 6 addresses through periodic review. More often, the transfer itself changes: the vendor adds a subprocessor in a new country, relocates a workload, restructures its entities, or switches transfer mechanism, for instance by obtaining a certification under the EU-US Data Privacy Framework (DPF). Each of those events can move a transfer outside the scope of the assessment that approved it.
The operational fix is event-driven review on top of interval review. Watch vendor subprocessor lists and DPA pages for changes, treat every new destination country in the chain as a trigger, and check whether an existing TIA covers the new leg before the change settles in unexamined. Teams that only rediscover their TIAs at contract renewal are usually warranting circumstances that stopped being true months earlier.
Common mistakes to avoid
- One-off assessments. The TIA is treated as a signature-time formality and never reopened, even though Clause 14 is a continuing warranty and step 6 makes re-evaluation part of the method.
- Copy-paste country analyses. Identical text is filed for every vendor in the same country, with no reference to the actual data, access patterns, or measures. Clause 14 expressly ties the assessment to the specific circumstances of the transfer, and a reviewer can tell when it does not.
- Ignoring the subprocessor chain. The assessment covers the contracted vendor but not the onward legs, which is exactly where destination countries quietly multiply.
- Measures that do not answer the risk. Encryption is listed as the supplementary measure while the importer holds the keys and processes the data in the clear, which addresses nothing the analysis identified.
- No retrievable record. The analysis happened in an email thread, and nobody can produce it when a supervisory authority asks for it under Clause 14(d).
Frequently asked questions
Do we need a TIA for a vendor certified under the EU-US Data Privacy Framework?
Not for transfers actually covered by the adequacy decision for the DPF, because adequacy-based transfers do not rely on Article 46 and the Clause 14 assessment is not triggered. That answer holds only while the decision stands: as of July 2026 it remains in force, with an appeal against it pending before the Court of Justice. You do need to verify that the importing entity holds an active certification and that its scope covers the data you send. If the transfer instead proceeds under SCCs, for example because certification lapsed or does not cover the data, the assessment duty applies in full.
Who runs the TIA when our processor transfers to its own subprocessor?
The parties to the SCCs covering that leg carry the Clause 14 duties, so typically your processor acting as exporter. Your accountability for the chain does not disappear, though: ask the processor which tool covers the leg, request the conclusions of its assessment as part of vendor review, and reflect the leg in your own transfer map.
How often should a TIA be reviewed?
There is no fixed statutory interval. The Recommendations require re-evaluation at appropriate intervals, and Clause 14 obliges the importer to report relevant changes it becomes aware of. In practice, a scheduled review cycle combined with event triggers, such as a new subprocessor, a new destination country, or a relevant legal development, matches what the framework expects.
Can we rely on a TIA the vendor provides?
As input, yes; as a substitute, no. Vendor-provided assessments are usually written once for all customers, while Clause 14 requires taking due account of the specific circumstances of your transfer. Verify the sources, check that the described measures match your actual configuration, add the transfer-specific layer, and record your own conclusion.
Where DPAFlow fits in
DPAFlow does not make transfer decisions, and no tool should claim to. It supports the operational side of the work: the Transfer Impact Assessment module helps create, maintain, and export structured TIA records, so versions, owners, and review dates live in one place instead of scattered documents.
Because DPAFlow also monitors vendor subprocessor lists and DPA pages on a scheduled, recurring basis and flags detected changes with dated evidence, the events that should reopen an assessment, such as a new subprocessor or a new destination country, reach your team instead of aging silently. The legal judgment stays with humans; the record-keeping and the triggers stop depending on memory.