GDPR and Data Residency: What SaaS Companies Actually Have to Build

The most common misconception about GDPR is that it requires European customer data to physically stay within EU borders. It doesn't. Neither GDPR nor UK GDPR flatly requires data to remain in the EU or UK — both permit international transfers, but only through a valid legal mechanism, and since the Schrems II ruling, the burden of assessing and documenting that transfer sits with the exporting company (Legiscope). In practice: GDPR doesn't mandate that data stays in the EU. It mandates that data is protected to EU standards wherever it goes (Vucense).

Four transfer mechanisms, in order of preference

A GDPR cross-border data transfer requires one of four legal mechanisms, and the choice between them determines both your compliance overhead and your legal risk profile (Legiscope):

1. Adequacy decision — the European Commission has determined the destination country provides adequate protection. As of 2026, 15 countries hold adequacy status. Simplest mechanism, no additional paperwork per-transfer.
2. Appropriate safeguards — most commonly Standard Contractual Clauses (SCCs), a set of EU-approved contract terms between exporter and importer.
3. Binding Corporate Rules (BCRs) — internal, regulator-approved rules for transfers within a single corporate group, common for large multinationals rather than SaaS startups.
4. Narrow derogation — case-by-case exceptions (explicit consent, contractual necessity) meant for occasional transfers, not a scalable compliance strategy.

The EU-US Data Privacy Framework: current status

The EU-US Privacy Shield was invalidated by Schrems II in 2020, creating years of legal uncertainty for any SaaS company transferring data to US infrastructure. Its replacement, the EU-US Data Privacy Framework (DPF), adopted in July 2023, provides a valid adequacy basis for transfers to DPF-certified US organizations (Legiscope).

The DPF remains valid in 2026 and survived a legal challenge (the Latombe case) at the EU General Court in September 2025 — though that ruling has since been appealed to the Court of Justice of the EU, meaning its long-term durability isn't fully settled (Legiscope). Given that history, the practical recommendation hasn't changed since Schrems II: use the DPF as your primary transfer mechanism where the importer is certified, but execute SCCs alongside it as a fallback — the marginal administrative cost of maintaining both is trivial next to the disruption of a future invalidation (Legiscope).

Residency, localization, and sovereignty are three different problems

These terms get used interchangeably, but they map to entirely different engineering requirements:

A residency requirement can typically be satisfied by picking a cloud region. A localization mandate is a different order of problem — it's the one that most often forces teams to redesign where computation happens, not just where data rests (Alation). More than 140 countries now have some form of data protection law, and an increasing share include explicit localization or residency components — the strictest concentrated in Russia, China, and India, with dozens of others applying sector-specific rules (Duality Tech).

The architecture reality: it's not just storage anymore

Modern SaaS — especially AI products — processes customer content in ways that matter just as much as where it's stored at rest. OpenAI's approach is a useful reference pattern: keep customer content stored in-region, and additionally keep model inference itself in-region for Europe (EEA + Switzerland), while some control-plane functions like authentication may still route through the US (WorkOS). This "storage AND compute in-region, control-plane may route globally" split is becoming the practical template for AI-adjacent SaaS trying to satisfy EU residency expectations without rebuilding their entire infrastructure per region.

Common architecture trap:
  App server region:  EU (correct)
  Primary DB region:   EU (correct)
  Automated backup:    Default multi-region replication (WRONG)
                        -> silently mirrors data outside the EU
                        -> becomes an undocumented cross-border transfer

Fix: explicitly pin backup/replication targets to the same region,
     audit default cloud settings for cross-AZ or cross-region mirroring.

Engineering teams building "region-locked" environments have to actively hunt down default cloud settings that silently mirror storage across availability zones or regions — under strict residency/localization rules, an automated backup replicating outside the approved region becomes an unintentional, undocumented illegal transfer (Duality Tech). This is one of the most common gaps in "we're GDPR compliant" claims: the application layer is region-pinned, but the backup and disaster-recovery layer isn't.

Practical checklist for a SaaS company handling EU data

1. Identify every transfer path, not just primary storage — backups, log pipelines, analytics tools, support-ticket systems, and third-party subprocessors all count.
2. Pick a primary transfer mechanism — DPF certification for US-based infrastructure providers where available, SCCs as the universal fallback, with a documented TIA for each.
3. Audit default replication settings on every storage and backup system for silent cross-region mirroring.
4. Distinguish residency from localization requirements per-market — don't apply the strictest jurisdiction's rules globally by default; it's often unnecessary and expensive, but don't assume EU rules are the strictest either (Russia, China, India are stricter on localization specifically).
5. Document subprocessors and their regions in your DPA — regulators and enterprise customers increasingly expect this to be current and specific, not a static PDF from onboarding.

Actionable takeaway

Don't default to "just store everything in an EU region" as your GDPR strategy — it solves residency but not the transfer-mechanism paperwork (SCCs + TIA, or DPF certification) that governs any data that does leave, including backups, logs, and third-party tools you may not have audited. Start by mapping every place EU customer data actually flows to, then apply the right mechanism per path rather than assuming a single regional deployment satisfies the whole regulation.

Sources: Legiscope, Vucense, Alation, Duality Tech, WorkOS