A transfer impact assessment example is the quickest way to see what a finished TIA should say, because neither the Standard Contractual Clauses nor the UK transfer rules tell you what one looks like. They only say what it must weigh. This guide walks through a complete transfer impact assessment example for a fictional retailer sending employee data to a US HR platform with a support team in India, step by step, from the screening to the sign-off.
Each section follows the six steps in the European Data Protection Board’s Recommendations 01/2020 on supplementary measures, and notes where the UK transfer risk assessment asks the same question in different words, so you can hold your own TIA up against it.
What a Transfer Impact Assessment Must Show
Clause 14 of the EU SCCs requires both parties to warrant that they have no reason to believe the laws and practices of the destination stop the importer from meeting its obligations. To give that warranty, the exporter must take into account:
- the specific circumstances of the transfer: the parties, the purpose, the data, its format, the route, where it is stored and any onward transfers;
- the laws and practices of the destination, including any that require disclosure to public authorities or allow them access;
- any contractual, technical or organisational safeguards added to the SCCs.
The assessment must be documented and made available to the supervisory authority on request (Clause 14(d)). In the UK, the ICO expects a transfer risk assessment before any transfer relying on the IDTA, the UK Addendum or another Article 46 safeguard, and the test since the Data (Use and Access) Act is whether protection is not materially lower than under UK law. Our guide to international data transfers explains where the TIA sits in the wider rules.
The Organization in This Transfer Impact Assessment Example
Meridian Retail Group (a fictional company) employs 6,800 people in the UK, Ireland and the Netherlands. It is moving HR administration and payroll preparation to a cloud HR platform run by a US provider. The provider’s support subsidiary in India can open employee records to resolve tickets. Records of about 9,000 former employees move too.
Step 0: Screening
The first question in any transfer impact assessment example is whether a TIA is needed at all. Meridian’s screening:
| Question | Answer | Why |
|---|---|---|
| Does the EU GDPR or UK GDPR apply? | Yes, both | Stores in Ireland and the Netherlands; head office in the UK |
| Is the data sent to, or accessed from, outside the EEA or UK? | Yes | Hosting in the US; remote access from India |
| Is the recipient a separate organization? | Yes | The provider and its Indian subsidiary |
| Does adequacy cover it? | No | The provider is not certified to the Data Privacy Framework for HR data; India has no adequacy decision |
| Is an Article 49 exception relied on? | No | The transfers are regular, so an exception would not fit |
Verdict: a restricted transfer under both regimes, relying on the EU SCCs and the UK Addendum, so a TIA is required.
Steps 1 and 2: Know the Transfer and the Tool
| Part | What Meridian recorded |
|---|---|
| Parties and roles | Meridian is the controller; the US provider is a processor (SCC module 2); the Indian subsidiary is a sub-processor (module 3 flow-down) |
| Data and people | Identity and contact details, job and pay history, bank details, absence records including sickness absence, performance reviews |
| Format | Encrypted in transit and at rest, but the provider holds the keys; support staff see records in clear |
| Route | Nightly payroll upload; HR staff in the browser; around 40 support tickets a month from India |
| Onward transfers | Email service and cloud hosting in the US, both listed sub-processors |
| Transfer tool | EU SCCs module 2 with module 3 flow-down; the UK Addendum had not been signed |
The last line was the first finding: UK employee data had no valid safeguard at all. Mapping the transfer properly is often where a TIA pays for itself.
Step 3: Laws and Practice in This Transfer Impact Assessment Example
Meridian answered ten questions for each destination, using the provider’s due diligence questionnaire, its transparency report and published legal analyses as sources:
| Question | Answer | Note |
|---|---|---|
| Access laws are clear, precise and public | Partly | US laws are public; the use of Indian access powers is not published |
| Access is limited to what is necessary and proportionate | Partly | The US added limits for signals intelligence in Executive Order 14086; no equivalent found for India |
| Independent oversight of access | Partly | Oversight bodies exist in the US; none found for India |
| Effective redress for the people concerned | No | No route found in India for EU or UK residents |
| The importer is outside what those laws target | No | The US provider falls within the scope of FISA Section 702 |
| No access requests for data like this | Yes | None for customer HR data in three years of transparency reports |
| The importer can comply with the SCCs | Yes | Questionnaire answered in full; commits to notify and challenge |
Two “no” answers do not end the transfer. They are the reasons the SCCs need supplementing, and each has to be matched by a measure in the next step.
Step 4: Risks and Supplementary Measures
Risks are rated for the employees, not for Meridian, on 1 to 5 scales:
| Risk to employees | Level before | Supplementary measures | Level after |
|---|---|---|---|
| Support staff in India view records in clear | 12 High | Just-in-time access approved per ticket, logged, with bank and health fields masked | 6 Medium |
| Encryption keys held by the provider | 12 High | Move to customer-held keys when released; re-evaluate until then | 8 Medium |
| Sickness reasons sent abroad as free text | 12 High | Coded absence types; medical detail stays in the UK occupational health system | 6 Medium |
| Provider compelled to disclose data | 8 Medium | Contractual duty to notify and challenge; twice-yearly review of the transparency report | 6 Medium |
| UK Addendum never signed | 9 Medium | Sign the Addendum and complete Annex I | 3 Low |
Notice which measures carry the weight. The EDPB is clear that contractual and organisational measures alone rarely stop access by public authorities to data held in clear. Masking, minimisation and customer-held keys are the technical measures that change what could actually be reached.
Steps 5 and 6: Sign-off and Re-evaluation
With the measures in place, no risk in this transfer impact assessment example remains High, so the transfer tool can be relied on. The sign-off records:
- the DPO’s advice (just-in-time, logged, masked support access; customer-held keys as soon as available) and that it was followed in part, with the reason: the keys depend on the provider’s roadmap;
- the importer’s input under Clause 14(c): its 32-question questionnaire, transparency report and commitment to notify;
- the outcome: proceed once the supplementary measures are in place, approved by the Chief People Officer;
- a re-evaluation date twelve months on, or sooner if the transfer or the destination’s law changes.
Common Mistakes This Example Avoids
- Treating remote access as “no transfer”. Access from India counts, even though nothing is stored there.
- Assessing the country, not the transfer. The same destination can be fine for encrypted backups and a problem for support staff reading records in clear.
- Relying on contract clauses alone. Promises to challenge requests help, but they do not stop compelled access to data in clear.
- Forgetting the UK. EU SCCs do not cover UK data without the UK Addendum or the IDTA.
- No sources. Each answer about the destination should say where it came from.
Frequently Asked Questions
Can I reuse this transfer impact assessment example as a template?
Reuse the structure of this transfer impact assessment example, not the answers. The destination questions and the measures depend on your importer, your data and how it is accessed.
Do I need a TIA for every supplier?
Only for restricted transfers that rely on an Article 46 safeguard such as the SCCs, the IDTA or the UK Addendum. Transfers to a country or recipient covered by adequacy do not need one.
How is a TIA different from a DPIA?
A TIA asks whether protection survives the journey to a particular country. A DPIA asks whether the processing itself is high risk. A high-risk processing operation that also involves a restricted transfer may need both; our DPIA example shows the other half.
Who should sign off a TIA?
The exporter, usually a senior owner of the processing, with the DPO’s advice where one is designated.
To build your own in the same order, use our free transfer impact assessment tool, which screens the transfer, asks the destination questions, rates the risks and tells you whether the transfer tool is effective with your supplementary measures. For the transfer procedure and the rest of your GDPR documentation, see the GDPR Toolkit.