GDPR International Data Transfers: SCCs, DPF, BCRs and the TIA Explained
If your SaaS uses AWS us-east-1, OpenAI's API, Stripe, Sentry, or any other vendor headquartered outside the EU/EEA, you are making international data transfers under GDPR. Every one of those transfers needs a legal basis under GDPR Chapter V — it's not enough that you have SCCs buried in a DPA; you also need to have assessed whether those SCCs actually provide protection equivalent to what data subjects would receive within the EU.
That's what the Schrems II ruling changed, and why Transfer Impact Assessments (TIAs) matter. This guide explains every mechanism and when to use each.
The Legal Framework: GDPR Chapter V (Art. 44–49)
GDPR Article 44 establishes the general principle: personal data may only be transferred to a third country if the conditions in Chapter V are met. The transfer mechanisms in order of preference are:
- Adequacy Decision (Art. 45) — simplest; no additional steps needed
- Appropriate Safeguards (Art. 46) — SCCs, BCRs, approved codes of conduct, approved certification mechanisms
- Derogations (Art. 49) — consent, contract performance, public interest, legal claims; last resort only
Mechanism 1: Adequacy Decisions (Art. 45)
An adequacy decision is the European Commission's determination that a third country provides an essentially equivalent level of data protection to the EU. If you transfer data to an adequate country, no further safeguards are needed.
Current adequacy decisions (as of 2026):
| Country | Decision Date | Status |
|---|---|---|
| Andorra | 2010 | Active |
| Argentina | 2003 | Active (under review) |
| Canada (commercial) | 2002 | Active (under review) |
| Faroe Islands | 2010 | Active |
| Guernsey / Isle of Man / Jersey | 2003-2008 | Active |
| Israel | 2011 | Active |
| Japan | 2019 | Active (mutual) |
| New Zealand | 2013 | Active (under review) |
| Republic of Korea | 2021 | Active |
| Switzerland | 2000 | Active (partial) |
| United Kingdom | 2021 | Active (expires 2025, renewal pending) |
| United States (DPF participants only) | 2023 | Active — see below |
| Uruguay | 2012 | Active |
Important: The US adequacy decision (EU-US Data Privacy Framework) only applies to US organisations that self-certify under the DPF. For US vendors not on the DPF list (check dataprivacyframework.gov), you need SCCs plus a TIA.
Mechanism 2: EU-US Data Privacy Framework (DPF)
The DPF replaced Privacy Shield after Schrems II invalidated Privacy Shield in July 2020. The new framework was adopted in July 2023 following Executive Order 14086 and the establishment of the Data Protection Review Court (DPRC) as a judicial redress mechanism.
For transfers to DPF-certified US companies:
- No TIA required (adequacy decision applies)
- Verify DPF certification at dataprivacyframework.gov before each assessment
- Document the DPF certification date in your sub-processor list and TIA
- Be aware: DPF could face a Schrems III challenge. Have SCC fallback ready.
Major DPF participants include: Google, Meta (some services), Salesforce, Workday, HubSpot, Stripe, Zendesk, Twilio, Slack, Dropbox.
Not on DPF (as of 2025): OpenAI, some AWS services (AWS has separate mechanisms), Anthropic. For these, SCCs + TIA are required.
Mechanism 3: Standard Contractual Clauses (2021 SCCs)
SCCs are pre-approved contract terms adopted by the European Commission. The 2021 SCCs (Decision 2021/914) replaced the 2010 SCCs and must be used for all new contracts. Key modules:
| Module | Transfer Type | Common Use Case |
|---|---|---|
| Module 1 | Controller → Controller | Sharing customer data with a marketing analytics platform |
| Module 2 | Controller → Processor | Your SaaS (controller) → AWS/Sentry/OpenAI (processor) |
| Module 3 | Processor → Processor | Your SaaS (processor for clients) → sub-processors |
| Module 4 | Processor → Controller | Rare; processor returns data to controller in third country |
When SCCs are in your DPA, are you done? No. Schrems II (C-311/18) requires that you assess whether SCCs actually provide effective protection in the specific third country. This is the TIA.
Mechanism 4: UK International Data Transfer Agreement (IDTA)
After Brexit, the UK is a separate jurisdiction. The UK GDPR governs UK transfers. The Information Commissioner's Office (ICO) approved the IDTA in March 2022 as the UK equivalent of EU SCCs.
- Use the IDTA for transfers from UK-established entities to third countries
- There's also a UK Addendum to EU SCCs that allows you to extend EU SCCs to cover UK transfers
- UK-EU transfers: covered by the UK adequacy decision (currently active, due renewal)
Mechanism 5: Binding Corporate Rules (BCRs)
BCRs are internal data protection policies approved by an EU DPA. They enable intra-group transfers across multinational companies. Two types:
- BCR-Controller: For groups where all entities act as controllers for the transferred data
- BCR-Processor: For processors offering services to group companies
BCRs take 1.5–3 years and significant legal investment to obtain. For most SaaS startups, SCCs are more practical. BCRs become relevant when you have 3+ international entities handling significant data volumes.
The Transfer Impact Assessment (TIA): What It Is and When You Need It
A TIA is a documented assessment of whether a transfer mechanism (typically SCCs) actually provides effective protection in the destination country, given that country's laws and practices. It's required by the Schrems II ruling and EDPB Recommendations 01/2020 whenever you use SCCs or other Art. 46 safeguards to a non-adequate country.
The EDPB 6-step TIA methodology:
- Map your transfers (who sends what data to whom, where)
- Identify the transfer mechanism relied upon
- Assess the law and practice of the third country
- Identify and adopt supplementary measures if needed
- Implement the formal procedural steps (execute SCCs, update DPA)
- Re-evaluate at appropriate intervals and on material change
Country Risk Assessment: Key Considerations
| Country | Key Surveillance Laws | TIA Risk Level | Typical Conclusion |
|---|---|---|---|
| United States (DPF participant) | FISA §702, EO 12333, CLOUD Act | Low (with DPF) | Adequacy applies — no TIA needed |
| United States (non-DPF) | FISA §702, EO 12333, CLOUD Act | Medium-High | SCCs + supplementary measures needed; technical measures (encryption) may not cure legal access risk |
| China | Art. 47 Cybersecurity Law, DSL, PIPL, MPS/MSS powers | High | SCCs insufficient alone; data localisation or redirect to EU infrastructure required |
| India | DPDPA 2023 (no adequacy yet), broad surveillance | Medium | SCCs + TIA required; supplementary measures recommended |
| Russia | FAPSI, SORM, data localisation law | Very High | Transfers generally not recommended; consider EU-hosted alternatives |
| Brazil | LGPD (no adequacy yet), but reasonable framework | Medium-Low | SCCs sufficient for most commercial processors |
| UK | IPA 2016 (surveillance), but adequacy decision active | Low | Adequacy applies — IDTA/UK Addendum needed only for onward transfers |
Supplementary Measures When SCCs Aren't Enough
When your TIA identifies residual risk (particularly for US non-DPF transfers), you need supplementary measures. EDPB categories:
Technical measures (most effective):
- End-to-end encryption where the data importer does not have the decryption keys
- Pseudonymisation before transfer, with key remaining in EU
- Split processing across jurisdictions
- Multi-party computation
- EU-only data residency (where the provider offers it)
Important limitation: If the recipient needs to process data in plaintext (e.g. OpenAI processing text, Sentry processing error logs), encryption in transit/at rest doesn't cure the legal access risk. The importer still holds the data in accessible form and could be compelled by national authorities.
Contractual measures:
- Prohibition on government disclosure without notice to the data exporter
- Obligation to challenge government access requests
- Enhanced audit rights
- Transparency reporting obligations
Organisational measures:
- Data minimisation (transfer only what's needed)
- Pseudonymisation before transfer
- Documented access controls at the recipient
The Practical TIA for Common SaaS Vendors
AWS, Google Cloud, Microsoft Azure (US): All three are on the DPF list. For EU region infrastructure, data stays in the EU. If you use US regions, DPF + SCCs (they're in the standard DPA). TIA conclusion: low risk with adequate safeguards.
OpenAI (US, not on DPF): SCCs required (Module 2 in OpenAI's DPA). Government access risk under FISA §702 — OpenAI can receive national security requests. Supplementary measures: data minimisation (don't send unnecessary PII), use pseudonymised IDs rather than real names in prompts where possible. TIA conclusion: medium risk, proceed with SCCs + minimisation.
Sentry (US, not on DPF): SCCs in Sentry's DPA. Sentry processes error logs that may contain personal data. Supplementary: configure Sentry to scrub PII from error events. TIA conclusion: medium risk with mitigation.
Stripe (US, on DPF): DPF applies. TIA conclusion: low risk.
Generate Your TIA Now
ComplyKit's free GDPR Transfer Impact Assessment Generator walks you through each transfer, assesses country risk, identifies applicable mechanisms, and produces a Schrems II-compliant TIA document. Covers all vendors in your sub-processor stack.
Related tools:
- GDPR Data Processing Agreement (DPA) Generator
- Sub-Processor List Generator
- DPIA Template Generator — often required alongside TIA for high-risk transfers
- Privacy Policy Generator — must disclose international transfers
⚠️ This guide is for informational purposes and does not constitute legal advice. International data transfer compliance is jurisdiction-specific and fast-moving — verify current adequacy decisions and DPF status before finalising your TIA.