# Cross-border data transfers and the rules that keep breaking
On October 6, 2015, the Court of Justice of the European Union (CJEU) struck down Safe Harbor, the fifteen-year-old framework that let thousands of companies move European personal data to US servers. Overnight, every SaaS company relying on it, from small analytics startups to Facebook, was operating on legally shaky ground. Five years later, the CJEU killed its replacement too. If you build a data residency mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → for your SaaS product and file it away, it will be obsolete before your next board meeting.
This lesson traces why that keeps happening, and what it means for how you architect and contract around data flows today.
The EU's General Data Protection Regulation (GDPR), in force since 2018, restricts moving personal data of EU residents outside the European Economic Area (EEA) unless the destination country offers "adequate" protection or specific safeguards are in place.
The US has no comparable federal privacy law and, more importantly, has broad government surveillance powers (under laws like
Safe Harbor was a self-certification scheme: US companies pledged to follow EU-equivalent privacy principles, registered with the US Department of Commerce, and could then freely import EU personal data.
Austrian law student Max Schrems filed a complaint against Facebook, arguing that US surveillance programs (revealed by Edward Snowden in 2013) made EU data unsafe once it hit US soil, regardless of Facebook's contractual promises. The CJEU agreed in *Schrems I* and invalidated Safe Harbor entirely.
Practical effect for SaaS: any company using US cloud infrastructure for EU customer data lost its legal basis overnight. Companies scrambled to add interim contractual fixes.
The EU-US Privacy Shield replaced Safe Harbor with stronger commitments: an ombudsperson for EU complaints, more oversight by the US Federal Trade Commission (FTC), and annual reviews.
Schrems sued again. In July 2020, the CJEU issued *Schrems II* and struck down Privacy Shield too, for the same underlying reason: US surveillance law still let agencies access EU data without EU-style redress, and no amount of contractual promising fixed that.
Practical effect for SaaS: Privacy Shield had over 5,000 certified companies at the time (a widely cited figure from the US Department of Commerce list, as of 2020). All of them needed a new legal basis, immediately, for transfers already in motion.
While frameworks rose and fell, most SaaS companies actually relied on Standard Contractual Clauses (SCCs), pre-approved contract templates issued by the European Commission that bind data importer and exporter to GDPR-level protections regardless of destination country.
*Schrems II* didn't kill SCCs, but it added a requirement: companies must conduct a Transfer Impact Assessment (TIA), evaluating whether the destination country's laws actually let the importer honor those contractual promises in practice. For transfers to the US, that meant confronting the surveillance problem directly, no contract clause can override a government's legal authority to compel data access.
This is where most SaaS compliance teams still spend real time: documenting TIAs, adding encryption and access controls as "supplementary measures," and maintaining SCCs as the fallback mechanism even after newer frameworks exist.
In July 2023, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework (DPF). It tries to fix the actual legal problem this time: a 2022 US Executive Order (14086) created binding limits on signals intelligence collection and a new Data Protection Review Court (DPRC) where EU individuals can seek redress against US surveillance overreach.
Companies self-certify with the US Department of Commerce, similar to the old mechanisms, but now backed by these structural changes to US law rather than just corporate pledges.
Status as of early 2026 (subject to change): the DPF is active and widely adopted, but it faces ongoing legal challenges in EU courts from privacy advocates who argue the DPRC isn't independent enough to satisfy EU standards. Most compliance professionals treat a "Schrems III" challenge as a matter of when, not if. You can track the current list of certified companies at the official Data Privacy Framework registry.
A "data residency mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →" documents where a SaaS company's customer data physically lives and travels, across regions, cloud providers, and subprocessors. Three practical constraints follow directly from this history:
1. No single mechanism is permanent. Legal teams now build compliance programs assuming any US transfer mechanism could be invalidated within a product's lifetime, not just at launch.
2. Regional hosting is now a real product feature. Major cloud providers (AWS, Microsoft Azure, Google Cloud) all offer EU-region data centers specifically so SaaS companies can offer EU customers "data stays in the EU" as a contractual commitment, sidestepping the transfer question for the core dataset even if metadata or support tickets still cross borders.
3. Subprocessor chains multiply the risk. If your SaaS product uses a US-based analytics tool, a US-based customer support platform, and a US-based payment processor, each one is a separate transfer path needing its own legal basis. Mapping this is not optional under GDPR's accountability principle.
EU personal data needs to leave the EEA?
├─ Is destination covered by an EU adequacy decision? (e.g., UK, Japan, South Korea, US via DPF)
│ └─ Yes → transfer permitted under that decision
├─ No adequacy decision →
│ └─ Use SCCs + complete a Transfer Impact Assessment
│ └─ Add supplementary measures if TIA flags risk (encryption, access limits)
└─ Still unresolved → consider EU-only data residency architectureThis isn't legal advice, but it reflects the general logic compliance teams apply, and it's why "just pick a transfer mechanism once" is not how this actually works in SaaS.
Knowledge check
1. What is the fundamental legal conflict that keeps causing EU-US data transfer mechanisms to be struck down?
2. Why was Facebook's compliance with Safe Harbor's self-certification principles not enough to protect it in Schrems I?
3. A SaaS company builds a data residency map showing exactly which countries it's legally permitted to transfer EU personal data to, based on today's approved transfer mechanisms. What is the key risk this lesson highlights about relying on that map long-term?
4. Select ALL correct answers about why the US lacks an easy path to GDPR 'adequacy' status.
Select all the correct answers.
5. Select ALL correct answers describing what made Safe Harbor legally vulnerable to challenge.
Select all the correct answers.
Understanding this list matters because a SaaS company's exposure isn't just "GDPR compliance," it's exposure to whichever of these bodies has jurisdiction over a specific data flowdata flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.View full definition →.
🎬 [VIDEO: "GDPR and International Data Transfers Explained" - https://www.youtube.com/results?search_query=gdpr+international+data+transfers+explained - a plain-language walkthrough of why cross-border transfer rules exist and how SCCs and adequacy decisions function in practice]