International Data Transfers After Schrems II: Compliance Strategies for 2026

When the Court of Justice of the European Union struck down the EU-US Privacy Shield in July 2020, it did not just create a US-specific problem. The Schrems II judgment fundamentally changed how every organization must approach international data transfers. The court established that transfer mechanisms like Standard Contractual Clauses are not rubber stamps — they require active assessment of whether the destination country actually protects personal data at a level essentially equivalent to EU law.

Six years later, organizations are still getting this wrong. The EU-US Data Privacy Framework restored one pathway for US transfers, but transfers to dozens of other countries — India, China, Brazil, most of Africa and Southeast Asia — remain in the complex post-Schrems II landscape where SCCs alone are insufficient and supplementary measures are the norm.

This guide breaks down every transfer mechanism available in 2026, explains when each one applies, walks you through the Transfer Impact Assessment process, and provides the practical supplementary measures that actually satisfy supervisory authorities during investigations.

What Schrems II Actually Changed

Before Schrems II, most organizations treated international data transfers as a compliance checkbox. Sign the Standard Contractual Clauses, file them, move on. The CJEU's ruling in Data Protection Commissioner v Facebook Ireland (Case C-311/18) invalidated this approach by establishing three principles that now govern every transfer:

Principle 1: Essential equivalence. The destination country must provide a level of data protection "essentially equivalent" to that guaranteed within the EU by GDPR and the Charter of Fundamental Rights. This is not a vague aspiration — it requires concrete analysis of the destination country's legal framework.

Principle 2: Case-by-case assessment. The data exporter (you) bears the responsibility to assess whether the destination country meets the essential equivalence standard before transferring data. You cannot rely on the existence of SCCs alone — you must evaluate the actual legal environment where the data will land.

Principle 3: Supplementary measures obligation. If the assessment reveals that destination country law undermines the protections in the SCCs — for example, surveillance laws that compel processors to disclose data to intelligence agencies without adequate judicial oversight — you must implement supplementary measures that compensate for the protection gap, or stop the transfer entirely.

These principles apply to every transfer mechanism except adequacy decisions, which represent the European Commission's own assessment that a country meets the essential equivalence standard.

Transfer Mechanisms Available in 2026

GDPR Chapter V provides several mechanisms for lawfully transferring personal data outside the EEA. Each has different requirements, costs, and use cases.

Adequacy Decisions (Article 45)

The simplest transfer mechanism. When the European Commission determines that a country provides an adequate level of data protection, transfers to that country require no additional safeguards. You treat it the same as an intra-EEA transfer.

Countries with adequacy decisions as of 2026: Andorra, Argentina, Canada (commercial organizations under PIPEDA only), Faroe Islands, Guernsey, Isle of Man, Israel, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, the United Kingdom, Uruguay, and the United States (under the DPF for certified companies only).

Key limitations: adequacy decisions cover specific countries and sometimes specific sectors (Canada's covers only commercial data, the US covers only DPF-certified organizations). The UK adequacy decision originally included a sunset clause requiring review by June 2025 — the Commission extended it, but its long-term certainty depends on the UK's continued alignment with EU data protection standards following Brexit-era regulatory divergence.

EU-US Data Privacy Framework (Article 45 — US-specific)

The DPF replaced the invalidated Privacy Shield in July 2023 following Executive Order 14086, which established the Data Protection Review Court and imposed proportionality requirements on US intelligence activities. For transfers to DPF-certified organizations, no SCCs or TIAs are required.

Practical requirements for relying on the DPF:

• Verify certification — Check the official DPF list at dataprivacyframework.gov before every transfer. Certification is company-specific, not sector-wide. A company's parent being DPF-certified does not cover subsidiaries.
• Monitor certification scope — DPF certification specifies whether it covers HR data, non-HR data, or both. Transferring employee data to a company only certified for non-HR data is not covered.
• Document reliance — Record in your ROPA and data transfer documentation that you rely on the DPF for each specific transfer, including the date you verified the recipient's certification status.
• Watch for Schrems III — Max Schrems and noyb challenged the DPF before the CJEU in early 2024. While most legal analysts expect the DPF to survive initial challenges due to EO 14086's structural improvements, the risk of eventual invalidation is non-zero. Maintain SCC fallback positions for critical US transfers.

For US companies not on the DPF list — smaller SaaS providers, freelancers, non-certified subsidiaries — you must use SCCs with a full Transfer Impact Assessment.

Standard Contractual Clauses — the 2021 Version (Article 46(2)(c))

The European Commission adopted new SCCs in June 2021 (Commission Implementing Decision 2021/914), replacing the outdated 2001/2004/2010 versions. The transition deadline passed on December 27, 2022 — any organization still using legacy SCCs is in violation.

The 2021 SCCs use a modular structure with four modules:

• Module 1 — Controller to controller (C2C): You transfer data to another controller in a third country. Example: sharing customer data with a non-EU partner company for joint marketing.
• Module 2 — Controller to processor (C2P): You send data to a processor in a third country. Example: using an Indian cloud hosting provider to store EU customer data.
• Module 3 — Processor to processor (P2P): Your processor transfers data to a sub-processor in a third country. Example: your EU-based cloud provider uses AWS US-East for backup storage.
• Module 4 — Processor to controller (P2C): A processor in the EU returns data to or shares data with a controller in a third country. Example: an EU payroll processor sending salary data to the non-EU parent company.

Critical implementation requirements that organizations frequently miss:

• SCCs must be incorporated into or attached to your data processing agreement — they cannot exist as a standalone document disconnected from the commercial relationship
• The Annex I information (parties, data categories, purposes, frequency, retention) must be completed specifically for each transfer, not left generic
• Local law clauses — the SCCs allow you to select which EU member state law governs the clauses and which courts have jurisdiction for data subject claims
• The docking clause (Clause 7) allows additional parties to accede to already-executed SCCs without re-executing the entire agreement — useful when adding new group entities

Binding Corporate Rules (Article 47)

BCRs are the most comprehensive but also most resource-intensive transfer mechanism. They are organization-wide data protection policies that must be approved by an EU supervisory authority before they can be used to authorize intra-group transfers.

BCR advantages: once approved, they cover all intra-group transfers without needing individual SCCs for each data flow. They also demonstrate a high level of data protection maturity to supervisory authorities and business partners.

BCR realities: approval takes 12 to 18 months, requires dedicated legal resources, and involves coordination across all group entities worldwide. As of 2025, approximately 200 BCR sets have been approved across the EEA — virtually all by large multinational corporations. BCRs are not practical for SMEs.

Derogations (Article 49)

Article 49 provides exceptions that allow transfers without SCCs, BCRs, or adequacy decisions in specific circumstances. These are narrow and cannot serve as the basis for systematic, repeated transfers:

• Explicit consent — The data subject explicitly consents after being informed of the risks. Must be genuinely specific to the transfer, not buried in general terms and conditions.
• Contract performance — The transfer is necessary to perform a contract with the data subject. Example: booking a hotel in a non-adequate country requires transferring the guest's name and contact details to the hotel.
• Important public interest — Transfers necessary for important reasons of recognized public interest. Interpreted narrowly by the EDPB.
• Legal claims — The transfer is necessary for the establishment, exercise, or defense of legal claims.
• Vital interests — Necessary to protect the vital interests of the data subject when they are incapable of giving consent.

The EDPB emphasizes that derogations must be interpreted restrictively. Using explicit consent as a systematic basis for routine transfers to your India-based customer service team is not compliant — consent must be truly occasional, and the data subject must be informed specifically about the risks of the transfer to a country without adequate protection.

Conducting a Transfer Impact Assessment (TIA)

The TIA is the practical consequence of Schrems II's case-by-case assessment requirement. You must complete one for every SCC-based transfer (and arguably for every BCR-based transfer, though the BCR approval process covers similar ground).

A TIA evaluates five dimensions of the destination country's legal framework:

1. Government access to data — Can intelligence agencies or law enforcement compel data importers to disclose personal data transferred from the EU? Under what legal authority? With what independent oversight?
2. Judicial oversight and remedies — Are government data access requests subject to prior judicial authorization? Can data subjects challenge access in independent courts or tribunals?
3. Data protection legislation — Does the country have data protection laws that impose obligations on data importers? How do these laws compare to GDPR in scope and enforcement?
4. Supervisory authority independence — Is there an independent data protection authority with investigative and enforcement powers? Is it genuinely independent from political influence?
5. Practical application — How are the laws actually applied? A country may have strong data protection legislation on paper but weak enforcement in practice.

Sources for your assessment: the EDPB's recommendations on supplementary measures (Recommendations 01/2020), national security legal analysis from law firms like Hogan Lovells (which published comparative assessments for 16 countries post-Schrems II), the European Commission's adequacy assessment reports, reports from civil liberties organizations, and the OECD's Government Access to Personal Data reports.

For common destination countries, the assessment landscape in 2026:

Supplementary Measures That Actually Work

When your TIA identifies gaps between the destination country's legal framework and EU standards, you must implement supplementary measures before initiating the transfer. The EDPB categorizes these into three types:

Technical Measures

Technical measures are the most effective because they provide protection regardless of the destination country's legal framework. Even if local law allows government access to the data, technical measures can make that access meaningless.

• Encryption in transit and at rest where the data exporter retains sole control of encryption keys — This is the gold standard. If the data importer cannot decrypt the data without the exporter's key, government access to the data importer's systems yields only ciphertext. The EDPB specifically endorses this approach in its recommendations.
• Pseudonymization where the mapping table stays in the EEA — Transfer only pseudonymized data to the third country, keeping the re-identification keys under the exporter's exclusive control within the EEA. Government access to pseudonymized data in the third country does not expose identifiable personal data.
• Split processing — Distribute processing across multiple jurisdictions so that no single third-country processor holds enough data to identify individuals. Combine with encryption so that reassembly requires keys held exclusively in the EEA.
• Homomorphic encryption or secure multi-party computation — Emerging technologies that allow computation on encrypted data without decrypting it. Still limited in practical application but relevant for specific use cases like aggregate analytics on health data.

The critical caveat: encryption is only an effective supplementary measure if the data importer does not hold the decryption keys. If your US cloud provider encrypts data at rest but also holds the keys — as is the case with default AWS or Azure encryption — government access to the provider compels access to both the ciphertext and the keys. This provides no supplementary protection.

Contractual Measures

Contractual measures supplement the SCCs with additional obligations on the data importer:

• Enhanced transparency obligations — The importer must notify the exporter of any legally binding government data access request, to the maximum extent permitted by local law. If local law prohibits notification (gag orders), the importer must challenge the prohibition.
• Challenge obligations — The importer commits to challenging any government access request that it reasonably believes is unlawful or disproportionate under local law, and to exhaust available legal remedies before complying.
• Strengthened audit rights — Enhanced rights for the exporter to conduct on-site audits of the importer's data processing facilities, review security measures, and verify compliance with the SCCs and supplementary measures.
• Data minimization commitments — Contractual limitations on what data the importer can process and retain, beyond what the SCCs already require.
• Return and deletion obligations — Shortened data retention at the importer, with verified deletion and certification.

Organizational Measures

• Internal access controls — Limiting which employees of the data importer can access transferred EU personal data, with role-based access policies and access logging.
• Staff training — Requiring the importer to train staff on EU data protection standards and the specific obligations under the SCCs.
• Incident response procedures — Joint incident response plans for data breach scenarios, with clear escalation paths and notification timelines aligned with GDPR's 72-hour requirement.
• Transparency reporting — The importer publishes transparency reports documenting the number and type of government data access requests received, processed, and challenged.

Practical Implementation for Common Scenarios

Most organizations face the same handful of transfer scenarios. Here is how to handle each one:

Scenario 1: US SaaS Tools (Salesforce, HubSpot, AWS, Google Workspace)

Check if the provider is DPF-certified at dataprivacyframework.gov. If yes, document your reliance on the DPF and maintain an SCC fallback. If the provider is not DPF-certified, execute the 2021 SCCs (Module 2, controller-to-processor), complete a TIA addressing FISA Section 702 surveillance, and implement supplementary measures — at minimum, encryption in transit and at rest, with contractual audit rights and government access notification obligations.

Most major US SaaS providers (Salesforce, Google, Microsoft, AWS) are DPF-certified and also offer 2021 SCCs as a parallel mechanism. Use both: rely on the DPF as primary, with SCCs as fallback in case the DPF is invalidated.

Scenario 2: India-Based Development or Support Team

India's Digital Personal Data Protection Act (DPDPA) 2023 established a data protection framework, but the law's government access exemptions (Section 17(2)(a)) are broad, allowing the central government to exempt any government agency from the entire Act. Your TIA will identify this as a significant gap.

Supplementary measures: encrypt data in transit and at rest with EEA-held keys, implement strict access controls limiting which Indian team members can access personal data, pseudonymize data where possible (use reference IDs instead of names, remove email addresses from development databases), and add contractual government access notification and challenge obligations.

Scenario 3: Customer-Facing Transfers (Hotel Bookings, International Shipping)

For occasional, customer-initiated transfers — booking a hotel in Thailand, shipping a product to Brazil — Article 49(1)(b) derogation typically applies: the transfer is necessary to perform a contract with the data subject. This is legitimate for truly occasional transfers but cannot be scaled to systematic data flows. If you regularly transfer data for these purposes, implement SCCs with the receiving partners.

Scenario 4: Intra-Group Transfers in a Multinational Company

For large multinationals with entities in many third countries, BCRs provide the most efficient long-term solution. For companies that cannot justify the BCR investment, implement intra-group SCCs using the docking clause to allow new entities to accede without re-executing the entire agreement. Conduct a single TIA per destination country (not per entity), and implement supplementary measures at the group policy level.

Enforcement Trends and Notable Cases

Supervisory authorities have moved beyond guidance and warnings. Transfer-related enforcement is now a regular feature of the GDPR enforcement landscape:

Meta Platforms Ireland (May 2023) — 1.2 billion euros. The Irish DPC, following an EDPB binding decision, imposed the largest GDPR fine in history for transferring EU user data to Meta's US servers relying on SCCs without adequate supplementary measures. The DPC found that Meta's SCCs did not effectively address FISA 702 surveillance risks and ordered Meta to suspend transfers. This case demonstrated that even the most well-resourced companies cannot avoid transfer compliance obligations.

Google Analytics Austria and France (2022). The Austrian DSB and the French CNIL both ruled that websites using Google Analytics transferred personal data (including IP addresses, cookie identifiers, and browser metadata) to Google's US servers without adequate safeguards. These decisions forced thousands of European organizations to either implement server-side Google Analytics (keeping data in the EU), switch to EU-hosted alternatives like Matomo or Plausible, or obtain explicit consent for the transfer.

Clearview AI (Multiple DPAs, 2022-2024). The Italian Garante, the French CNIL, the Greek HDPA, and the UK ICO each fined Clearview AI for scraping facial images of EU residents and processing them in the US without any transfer mechanism. Fines exceeded 60 million euros combined. The cases highlighted that even companies with no EU establishment are subject to GDPR transfer rules if they process EU personal data.

TikTok (Multiple investigations, ongoing). The Irish DPC opened an investigation into TikTok's transfers of EEA user data to China, where the National Intelligence Law requires organizations to support, assist, and cooperate with national intelligence efforts. The case highlights the extreme end of the TIA spectrum — conducting a meaningful TIA for transfers to China is very difficult given the breadth of government access powers.

The Data Localization Alternative

For some organizations, the simplest compliance strategy is avoiding international transfers entirely. Data localization — processing and storing all personal data within the EEA — eliminates the need for SCCs, TIAs, and supplementary measures.

Data localization is increasingly feasible because most major cloud providers now offer EEA data residency:

• AWS — EU regions in Frankfurt, Ireland, Paris, Stockholm, Milan, Spain, and Zurich. AWS offers the European Sovereign Cloud launching in 2025 with operations exclusively controlled by EU-resident employees.
• Microsoft Azure — EU Data Boundary program ensures that all customer data for core services is stored and processed within the EU.
• Google Cloud — EU regions with data residency commitments for Google Workspace and Google Cloud Platform.
• Hetzner, OVHcloud, Scaleway — European cloud providers with infrastructure exclusively in EU member states. No US-jurisdiction complications.

For analytics, Matomo (self-hosted or EU cloud), Plausible (EU-hosted), and Fathom (EU isolation option) provide privacy-focused alternatives to Google Analytics that keep data entirely within the EEA.

The trade-off: some best-in-class SaaS tools have no EEA-only equivalent. You may sacrifice functionality or pay a premium for EU-specific solutions. But for organizations in sensitive sectors — healthcare, legal services, financial services — the compliance simplification often outweighs the operational compromises.

Preparing for a Potential Schrems III

The EU-US Data Privacy Framework faces the same structural vulnerability as its predecessors: it relies on executive action (Executive Order 14086) rather than legislation. A future US administration could modify or revoke the executive order, collapsing the DPF just as Privacy Shield collapsed when the CJEU found its predecessor protections inadequate.

Prudent organizations prepare for this possibility by maintaining parallel transfer mechanisms:

• Execute 2021 SCCs with all DPF-certified US providers as a fallback — most already offer them
• Conduct and document TIAs for US transfers assuming the DPF does not exist, so that if it falls, your SCC-based transfers are already assessed
• Identify EEA-based alternatives for the most critical data flows and test migration feasibility
• Monitor the noyb litigation and CJEU proceedings for early signals of the framework's trajectory
• Build data localization capabilities for the highest-sensitivity data categories, even while using the DPF for routine transfers

The goal is not to assume the DPF will fail — it may well survive, especially given the structural improvements over Privacy Shield. The goal is ensuring that your organization's data transfer compliance does not depend on a single mechanism that you do not control.

Documentation You Need to Maintain

Supervisory authorities expect organizations to demonstrate compliance with transfer requirements through documentation. At minimum, maintain:

• Transfer mapping — An inventory of all international data transfers including destination country, data categories, transfer mechanism used, and date of last review
• Executed SCCs — Signed copies of all 2021 SCCs with completed Annexes specific to each transfer relationship
• Transfer Impact Assessments — Documented TIAs for each destination country where you rely on SCCs, updated annually or when material changes occur in the destination country's legal framework
• Supplementary measures records — Documentation of the technical, contractual, and organizational measures implemented for each transfer, with evidence of implementation
• DPF verification logs — Records showing when you verified each recipient's DPF certification status
• ROPA entries — Your Records of Processing Activities must include information about international transfers for each processing activity

Organize these in a transfer compliance folder — physical or digital — that you can produce in response to a supervisory authority inquiry or data subject complaint. The difference between a warning and a fine often comes down to whether you can demonstrate that you assessed your transfers and made documented, defensible decisions about the appropriate safeguards.

For related guidance, see our articles on GDPR enforcement trends and major fines, conducting Data Protection Impact Assessments, and GDPR compliance for small businesses.