International data transfers sit at the awkward intersection of modern business reality and regulatory expectation. Organisations want cloud services, global support models, overseas vendors, and distributed teams. Regulators want assurance that, when personal data leaves the UK (or the EEA), people’s rights don’t leave with it.
The challenge is that “international transfer” rarely looks like a single, deliberate event. It can be a customer database replicated to a non-UK region, a support engineer accessing logs from abroad, a SaaS provider running analytics in another jurisdiction, or a supplier chain where data passes through multiple sub-processors. The compliance outcome you need is the same: a defensible mechanism for transfer, a clear understanding of the risks, and evidence that the protection remains “essentially equivalent” where that standard applies.
This guide explains what counts as a transfer, the main legal routes available (adequacy, SCCs/IDTA, BCRs and derogations), how Transfer Risk Assessments / Transfer Impact Assessments fit in, and how to operationalise it without turning every project into a legal fire drill.
What counts as an international transfer
A transfer is not only “sending a file to another country”. In practice, treat it as international when personal data is:
- stored in another jurisdiction (hosting, backups, DR, analytics)
- accessed from another jurisdiction (admin access, support, monitoring)
- processed by an entity outside the UK/EEA (processors, group companies, sub-processors)
- made available in a way that effectively enables international access (global services, distributed operations)
This matters because transfer compliance is triggered by exposure to a different legal environment, not by whether you pressed “export”.
A helpful rule of thumb: if the data becomes subject to another country’s laws, or could be compelled by a foreign authority, you should assume transfer controls are needed.
The legal “routes” for transfers (and how to choose)
In UK and EU regimes, the logic is broadly consistent:
- If the destination is recognised as adequate, transfers can proceed with normal GDPR controls (you still need security, contracts, transparency, etc.).
- If not adequate, you must use an approved transfer mechanism (such as SCCs/IDTA or BCRs) and assess whether extra safeguards are needed.
- If neither is workable, you may only rely on narrow derogations in specific, exceptional cases.
Rather than treating this as a legal taxonomy, it’s better to treat it as a decision path you can apply repeatedly.
| Decision point | What you’re asking | Typical outcome |
|---|---|---|
| Destination | Is this country covered by an adequacy decision? | If yes: proceed with standard GDPR controls |
| Relationship | Are we transferring to a processor, controller, or within a group? | Select SCC module / UK IDTA approach, or consider BCRs |
| Risk | Could the destination legal regime undermine protections? | Run a TRA/TIA and define supplementary measures |
| Practicality | Is the transfer occasional and truly necessary? | Derogation only if conditions are met and it’s not routine |
Adequacy: the simplest route, with important caveats
An adequacy decision is essentially a regulatory statement that a country’s legal and enforcement framework provides an acceptable level of protection. Where it applies, adequacy removes the need for SCCs/IDTA-style contractual mechanisms.
However, adequacy isn’t “set and forget”:
- some adequacy decisions are sector-limited or conditional
- decisions are reviewed and can change
- organisations still need to manage the underlying service reality: sub-processors, onward transfers, security, retention and incident response don’t disappear just because adequacy exists
Operationally, treat adequacy as a simplifier — not as a replacement for governance.
SCCs and the UK IDTA: the workhorse mechanisms
For most organisations, the day-to-day transfer mechanism is contractual: in the EU, the modern Standard Contractual Clauses (SCCs); in the UK, the International Data Transfer Agreement (IDTA) or the UK Addendum used with EU SCCs (depending on the structure of the deal and the parties involved).
The important thing is not the document itself — it’s the discipline around using it properly. When organisations get stuck, it’s usually because SCCs/IDTA are treated like a static template rather than a mechanism that needs accurate context.
In practice, implementation has five parts:
- Choose the correct scenario (controller-to-controller, controller-to-processor, processor-to-processor, etc.).
- Complete the schedules/annexes properly (data types, purposes, security measures, sub-processors, onward transfer conditions).
- Align the operational reality (how access works, where data is stored, what logs exist, what support teams can see).
- Assess the destination risk (TRA/TIA) and decide whether supplementary measures are needed.
- Maintain evidence (so you can show what you did, why you did it, and how it’s kept current).
If you want one practical improvement that makes a big difference: standardise the annex content. Most organisations lose time because every contract starts from scratch.
Binding Corporate Rules: powerful, but not lightweight
Binding Corporate Rules (BCRs) are designed for intra-group transfers. They can be a strong option for large organisations moving data across a corporate group with recurring transfers and a mature governance model.
The trade-off is that BCRs demand real operational maturity: policies, training, audit, enforcement, complaint handling, and a regulator approval process. They can be worth it when you have scale and repetition; they’re rarely the right first move for an organisation that’s still trying to map its transfers.
A simple way to think about it:
- SCCs/IDTA are the pragmatic “project-level” tool.
- BCRs are the “operating model” tool for groups that transfer constantly.
Derogations: the exception, not the strategy
Derogations (like explicit consent, contract necessity, or important public interest) exist for limited scenarios. They are often misunderstood and overused.
If you remember one principle: derogations are not for routine, systematic transfers. They are for genuinely specific situations where a formal mechanism isn’t feasible, and where the conditions are met.
When organisations get into trouble here, it’s usually because a derogation is used to justify an ongoing business-as-usual transfer that should have been covered by SCCs/IDTA or a redesigned service model.
Transfer risk assessments and TIAs: making the mechanism defensible
Since Schrems II, transfer compliance has increasingly focused on whether protections are effective in practice — especially in destinations where public authority access, surveillance, or weak redress mechanisms may undermine contractual commitments.
This is where Transfer Risk Assessments (UK) or Transfer Impact Assessments (EU) come in. They’re not meant to be academic essays; they are meant to be a structured judgement that you can defend.
A good assessment answers four questions in plain language:
- What is being transferred, by whom, to whom, and why?
- What could realistically go wrong for individuals if the data is accessed or misused?
- Do local laws/practices increase that risk in a way that undermines the mechanism?
- What measures reduce the risk to an acceptable level — and are they actually implemented?
To keep this practical, many organisations adopt a “pattern library” approach: repeatable assessments for common services (major SaaS platforms, standard support models, common hosting patterns), with a process for exceptions.
Supplementary measures: what “good” looks like in practice
Supplementary measures are often described as technical, organisational, and contractual. That’s true — but the key is choosing measures that actually change the risk profile, not just increase paperwork.
A simple way to structure the thinking is to tie measures to exposure:
| Exposure you’re trying to reduce | Measures that usually help |
|---|---|
| Data readable by third parties | strong encryption in transit and at rest, robust key management, separation of duties |
| Excessive access by support/admin | least privilege, just-in-time access, audited break-glass, strong logging and monitoring |
| Uncontrolled onward transfers | sub-processor controls, approval workflows, transfer inventory, contractual restrictions with enforcement |
| Unclear processing and retention | clear purpose limitation, retention schedules, deletion verification, evidence of lifecycle controls |
The best programmes focus on a small set of controls that are consistently implemented and evidenced. Consistency beats complexity.
Turning compliance into an operating model
International transfers become manageable when they’re treated as a capability, not an occasional legal hurdle. In practice, that means building a small but repeatable governance loop:
- Know your transfers: maintain a transfer inventory linked to RoPA, vendors, and systems.
- Standardise mechanisms: pre-approved SCC/IDTA packs and annex libraries for common scenarios.
- Embed reviews: procurement, architecture, security and privacy gates that trigger early.
- Assess and record risk: TRA/TIA templates that are proportionate and reusable.
- Monitor change: supplier changes, sub-processor updates, new regions, new access models.
- Train the right people: procurement and engineering teams need to recognise transfers and escalate early.
This is also where tooling can help, but tools don’t replace clarity. Even a simple register plus a disciplined contract pack will outperform a complex system that no one trusts.
Conclusion: aim for repeatable, defensible transfers — not perfect paperwork
International data transfers don’t need to paralyse delivery, but they do need to be handled deliberately. The goal is not to produce the longest possible contract schedule or the most detailed assessment document. The goal is to be able to show, with confidence, that you understand where data goes, you’ve chosen an appropriate transfer mechanism, you’ve assessed the real-world risks, and you’ve implemented measures that actually protect people.
If you can make transfer compliance repeatable — with clear patterns, light governance, and reliable evidence — you get the best of both worlds: global operations that work, and a privacy posture you can defend when the questions come.
External references
- UK ICO — International transfers guidance: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/
- UK ICO — International Data Transfer Agreement (IDTA) and Addendum: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/
- EDPB — Recommendations 01/2020 on supplementary measures (Schrems II): https://edpb.europa.eu/our-work-tools/our-documents/recommendations_en
- European Commission — Standard Contractual Clauses (SCCs): https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
- European Commission — Adequacy decisions: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en
- Court of Justice of the EU — Schrems II judgment (C-311/18): https://curia.europa.eu/juris/liste.jsf?num=C-311/18
- UK GDPR (UK): https://www.legislation.gov.uk/eur/2016/679/contents
- GDPR text (EU): https://eur-lex.europa.eu/eli/reg/2016/679/oj