What Is a TIA (Transfer Impact Assessment)?
A TIA (Transfer Impact Assessment) is a documented evaluation of whether the recipient country's laws undermine the protection in an SCC-based transfer of personal data. It's required when the transfer rests on standard contractual clauses, such as a direct route to an AI vendor, and it must answer what your defensible mechanism is the day a foreign request lands.
As soon as an AI service means personal data gets sent to the US under standard contractual clauses, the requirement for a TIA shows up. Transfer Impact Assessment sounds bureaucratic, but it’s a concrete document that answers a single sharp question: does the protection hold up when the recipient country’s authorities can access the data?
What a TIA Is
A Transfer Impact Assessment is a documented evaluation of whether the recipient country’s legislation undermines the protection the standard contractual clauses (SCC) are supposed to provide. It became necessary after the EU Court of Justice’s Schrems II ruling, which established that SCCs are valid but not automatically sufficient.
The logic is simple: a contract binds the parties, but it doesn’t bind the recipient country’s authorities. If that country’s laws give authorities access beyond what EU law allows, the exporter has to assess whether the protection still holds up in practice. That assessment is the TIA.
TIA or DPIA – Two Different Documents
A common mix-up is TIA and DPIA. They’re connected but answer different questions. A DPIA – impact assessment – assesses the risks of a processing activity as a whole: purpose, legal basis, volume of data, rights of the data subjects. A TIA is narrower and focuses specifically on the third-country transfer: does the protection hold up when the data leaves the EU for a country whose authorities can demand it?
In practice, the TIA’s conclusion often becomes a building block in the DPIA. If you’ve determined that an AI service requires a DPIA, and the service involves a transfer to the US on an SCC basis, the TIA’s assessment of the country risk and the residual risk belongs in the impact assessment too. Knowing which document answers what makes it easier to avoid duplicate work – and to avoid missing either one.
When It’s Required in an AI Context
The need for a TIA is governed by the transfer mechanism, and vendor routes differ there.
- A direct SCC-based route to a vendor – for example a direct route to Anthropic – requires its own TIA. The basis is the contractual clauses, and that means you have to assess the country risk yourself.
- A DPF route at vendors like Microsoft and OpenAI instead shifts the question to the mechanism’s validity. If the transfer rests on an adequacy decision, you normally don’t need a separate TIA for that particular route.
That means two AI vendors in the same project can have different analysis needs depending on how the transfer is grounded. If you run both in parallel, you have to keep them separate.
What the TIA Should Include
A useful TIA rests on three parts:
- The legal situation in the recipient country. Which laws give authorities access? For the US, that means the CLOUD Act and related legislation.
- The practical exposure. How likely is it that your specific data actually gets accessed? What type of data is involved, and in what volume?
- The supplementary measures. Which technical and organizational safeguards reduce the risk – customer-controlled keys (KMS/CMEK), data minimization, EU inference?
The conclusion is a reasoned assessment of whether the protection holds up despite the recipient country’s laws, with the residual risk clearly stated.
Responsibility for getting the TIA done rests with you as the data controller – you’re the exporter. The vendor can and should assist with information about its operations, its safeguards, and its subprocessor chain, but the assessment itself can’t be delegated away. It’s your defensible basis that has to be in the document. A good way to get started is to request the vendor’s transparency documentation and map out where the data actually goes, then weigh that map against what you know about the recipient country’s legislation. Anyone who waits to do the TIA until a regulator asks has started at the wrong end.
The Check Question the TIA Should Answer
The simplest way to know if your TIA holds up is to ask the decision guide’s check question: what is your defensible transfer mechanism on the day a US request lands on the vendor’s desk? The answer has to be in the TIA, concrete and substantiated.
A scenario makes it clear: a company uses an SCC-based AI service and assumes signed clauses are enough. When the regulator asks how they assessed the CLOUD Act risk, no answer is documented. With a TIA in place, they could have pointed to the analysis, the supplementary measures chosen, and the residual risk stated – instead of standing there with no answer.
Want to see how the TIA connects to SCC, DPF, and government access across a full AI project? There’s more on our AI page. Need help producing or reviewing a TIA ahead of an AI contract? Get in touch and we’ll take a look together.
Frequently asked questions
When do I need to do a TIA?
When a transfer to a third country rests on standard contractual clauses (SCC). After Schrems II, SCC alone isn't enough – you have to assess whether the recipient country's laws undermine the protection in practice. If the transfer instead goes through an adequacy decision like the DPF, the question shifts to the mechanism's validity, and a separate TIA usually isn't required for that route.
What's the difference between a TIA and a DPIA?
A DPIA (impact assessment) assesses the risks of a processing activity as a whole. A TIA is narrower: it focuses specifically on the third-country transfer and the risk of government access in the recipient country. They're connected – the TIA's conclusion on residual risk often belongs in the DPIA too – but they answer different questions.
What should a TIA include?
The core is three parts: the recipient country's legislation on government access (such as the CLOUD Act), the practical likelihood that your data is actually exposed, and which supplementary measures reduce the risk – for example customer-controlled keys and EU inference. The conclusion is an assessment of whether the protection holds up despite the recipient country's laws.
Who's responsible for making sure the TIA gets done?
The data controller – meaning you, as the one exporting the data. The vendor can assist with information about its operations and safeguards, but the assessment and the documentation are your responsibility. It can't be fully delegated to the vendor; it's your defensible basis that has to be in the document.
Do different AI vendors need different TIAs?
Yes, if they use different transfer mechanisms. A direct SCC-based route requires its own TIA, while a DPF route shifts the analysis to the mechanism's validity. If you run several vendors or routes in parallel, you may need to handle them separately, since the basis – and therefore the analysis needed – differs.