A Transfer Impact Assessment (TIA) is the documented analysis an exporter carries out before sending personal data outside the European Economic Area (EEA) on the basis of an Article 46 safeguard, to check whether the law and practice of the destination country undermine the protection that safeguard promises. The question that comes first, and gets asked far more often, is simpler: do we need one at all?
The answer depends on one thing, and it is not the sensitivity of the data or the size of the vendor. It depends on which transfer tool the transfer relies on. This article works through that decision, then covers the part that catches most teams out, which is that the duty follows the processing chain rather than the contract you signed.
The short answer
Three situations cover almost every vendor relationship:
- The transfer is covered by an adequacy decision under Article 45. No assessment of the destination country's law is required from you, because the European Commission has already made that finding.
- The transfer relies on Article 46 safeguards, most commonly Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs). An assessment is required. Under the 2021 SCCs it is also a contractual warranty.
- The transfer relies on an Article 49 derogation. The TIA framework does not apply, but derogations are narrow and cannot carry a routine software relationship.
Everything below is the detail behind those three lines, plus the situations where a transfer exists and nobody noticed.
First, is it even a transfer?
Before choosing a tool you have to know a transfer is happening. The EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V, adopted in their final version in February 2023, set out three cumulative criteria. A transfer under Chapter V occurs when:
- the exporter, a controller or processor, is subject to the GDPR for the processing in question;
- the exporter discloses by transmission, or otherwise makes personal data available, to another controller, joint controller or processor, the importer; and
- the importer is in a third country, or is an international organisation, whether or not that importer is itself subject to the GDPR for the processing.
Two consequences follow that surprise people.
Remote access counts. If your data sits on servers in Frankfurt but a support engineer in a third country can open a record, the data has been made available to an importer outside the EEA. Hosting location is not the test. This is the single most common reason a transfer sits outside a company's transfer register: nobody exported anything, so nobody logged it.
An importer being subject to the GDPR does not remove the need for a tool. The third criterion is explicit that it applies irrespective of whether the importer is caught by Article 3(2). Chapter V and Article 3 answer different questions.
By contrast, a data subject sending their own data directly to an organisation in a third country is not a transfer in this sense, because there is no exporter making a disclosure. Nor is an employee of an EEA entity accessing that entity's data while travelling, since the access is by the exporter itself rather than a disclosure to an importer.
The rule: your transfer tool decides
Adequacy decisions: no assessment of the destination
Where the Commission has decided under Article 45 that a third country ensures an adequate level of protection, transfers to that country need no additional safeguard and no country-level assessment from you. The finding has already been made at Union level.
Two caveats keep this from being a filing-and-forgetting exercise. Adequacy decisions can be limited in scope, so the finding may cover only a sector, a certification mechanism, or a particular type of recipient, and you should confirm that the specific importer and data fall inside it. And adequacy decisions are reviewed periodically and can be amended, suspended, or annulled, as the history of transatlantic transfers shows. Record which decision you rely on, and treat a change to it as a trigger to revisit the transfer rather than an item of news.
Article 46 safeguards: an assessment is required
This is where the TIA lives. In Case C-311/18, Schrems II, the Court of Justice confirmed that SCCs remain valid but placed a condition on their use: the exporter must verify, on a case-by-case basis, whether the law and practice of the destination country prevent the importer from complying with the clauses, and must adopt supplementary measures where they do.
The Commission then wrote that verification into the modernised SCCs, Implementing Decision (EU) 2021/914. Clause 14 has the parties warrant that they have no reason to believe the destination country's laws and practices prevent the importer from meeting its obligations, and states that the warranty rests on an assessment of the specific circumstances of the transfer. Clause 14(d) requires that assessment to be documented and made available to the competent supervisory authority on request.
That combination is what makes the answer unambiguous for SCC-based transfers. The assessment is not best practice you can defer. It is the evidential basis for a warranty you have already signed, and Clause 14(d) means somebody can ask to see it.
The EDPB Recommendations 01/2020 on supplementary measures turn the requirement into a six-step method. Step 3, assessing the law and practice of the destination, is the assessment itself; the remaining steps map the transfers, identify the tool, select measures, formalise them, and re-evaluate. Our practical walkthrough of the six-step method covers how to run one. This article stays on the prior question of whether you have to.
BCRs sit in the same category. They are an Article 46 tool, so the same Schrems II logic applies to transfers made under them.
Article 49 derogations: rarely the answer you want
Article 49 permits transfers in specific situations without an Article 46 tool, including explicit consent after being informed of the risks, necessity for the performance of a contract with the data subject, and important reasons of public interest. Because these sit outside Chapter V's safeguard framework, the Clause 14 assessment duty does not attach.
The catch is scope. The EDPB reads Article 49 as exceptional, and the second subparagraph derogation is expressly limited to transfers that are not repetitive, concern only a limited number of data subjects, and are necessary for compelling legitimate interests, with additional notification and documentation duties. A recurring flow of customer data into a hosted platform is repetitive by definition. Using a derogation to avoid an assessment is usually a sign that the wrong tool was chosen.
The duty follows the chain, not the contract
The most consequential gap is not choosing the wrong tool. It is assessing only the leg you signed.
Your processor is contractually required under Article 28(2) and 28(4) to engage subprocessors under equivalent obligations. If one of those subprocessors is in a third country, that leg is itself a transfer needing its own tool, and behind that tool sits its own assessment. How the clauses layer down that chain is covered in SCCs and subprocessors. As controller you remain accountable for the chain under Article 5(2), even where the exporter for that leg is your processor rather than you.
In practice this means the trigger question is not "does our contract mention a third country" but "does any party in this chain sit outside the EEA, or have access from outside it". The destinations that end up in your transfer register frequently arrive through a vendor's subprocessor list rather than through anything you negotiated. Those same destinations are what Article 30(1)(e) requires you to identify in your record of processing activities, which is why the two documents go stale together.
When an existing assessment stops covering the transfer
A TIA describes a transfer at a moment. It stops being an accurate description in two ways.
The destination changes underneath it. Law and practice in the third country evolve, an adequacy decision is amended or annulled, or a judgment shifts the analysis. Step 6 of the EDPB method addresses this through re-evaluation at appropriate intervals.
More often, the transfer itself changes. A vendor adds a subprocessor in a country that was not in the assessment. A workload moves region. An entity restructures, so the importer is no longer the entity you assessed. The transfer mechanism changes, for example from SCCs to a certification under an adequacy framework. Each of these can put the current transfer outside the scope of the assessment that approved it, without anything in your own systems changing.
The practical response is to pair interval review with event-driven review. Interval review catches drift in the destination. Event-driven review catches drift in the transfer, and it is the half that most programmes are missing, because the events originate with vendors rather than internally.
How much assessment is proportionate
Nothing in the judgment or the Recommendations prescribes a length. The depth should match the transfer. A defensible short-form assessment states the parties and their roles, the categories of data and data subjects, the destination, the tool relied on, the law-and-practice analysis and its sources, the supplementary measures in place, the conclusion, its owner, the date, and the next review date.
Reuse is legitimate where it is honest. If several transfers go to the same destination under the same tool, the country-level analysis can be shared. What cannot be shared is the transfer-specific layer, because Clause 14 ties the warranty to the specific circumstances of each transfer, and a reviewer can tell when a document has been pasted rather than written.
Common mistakes
- Treating hosting location as the test. Data stored in the EEA and accessed from a third country is still a transfer under the EDPB's three criteria.
- Stopping at the contracted vendor. The subprocessor legs are where unassessed destinations accumulate.
- Reaching for Article 49 to avoid an assessment. Derogations are exceptional and generally cannot carry repetitive processing.
- Assessing once at signature. Clause 14 is a continuing warranty, and the importer's own notification duty under it presumes the exporter will act on what it hears.
- Filing the analysis where it cannot be retrieved. Clause 14(d) requires the documented assessment to be available to the supervisory authority on request.
Frequently asked questions
Do we need a TIA for a vendor covered by an adequacy decision?
Not for transfers actually covered by that decision, because they rely on Article 45 rather than Article 46, so Clause 14 is not engaged. You should still confirm that the importing entity and the data fall within the decision's scope, and treat any change to the decision as a reason to revisit the transfer. If the transfer instead proceeds under SCCs, the assessment duty applies in full.
Who carries out the assessment when our processor transfers to its own subprocessor?
The parties to the clauses covering that leg, which is typically your processor acting as exporter. Your accountability for the chain remains, so the workable approach is to ask which tool covers the leg, request the conclusions as part of vendor review, and reflect the destination in your own transfer register.
Can we rely on the assessment a vendor publishes?
As an input, yes. As a substitute, no. Vendor documents are written once for every customer, while Clause 14 requires taking account of the circumstances of your transfer. Verify the sources, check the described measures match your actual configuration, add the transfer-specific layer, and record your own conclusion.
Does a TIA make a transfer lawful?
No. The assessment documents the analysis behind a decision. If the analysis shows the importer cannot comply with the clauses and no measure closes the gap, the Recommendations are candid that the correct outcome is not to transfer. A completed document is a record of reasoning, not a verdict.
Where DPAFlow fits in
DPAFlow does not decide transfer legality and does not provide legal advice. It handles the record-keeping and the triggers.
The Transfer Impact Assessment module holds each assessment as a structured record: the destinations and their classification, the mechanism relied on and where it was documented, supplementary measures across technical, organisational, and contractual categories, the reviewer and approver, the dates, and an append-only version history so you can see what the assessment said when it was approved. The conclusion field is customer-authored by design, and no automated path writes or suggests it.
The second half is the trigger. Because DPAFlow monitors vendor subprocessor and legal pages on a recurring schedule and captures dated evidence of what changed, a detected change on a vendor an assessment relates to flags that assessment for re-review and records which monitored event caused it. That closes the gap described above, where the transfer moves and the document does not. The reassessment itself stays with your team.