Frankfurt Doesn’t Mean Sovereign
Here’s a misconception that costs companies millions in compliance headaches: storing data in a Frankfurt data center owned by a US hyperscaler satisfies EU data sovereignty requirements. It doesn’t.
The US CLOUD Act grants US law enforcement the power to compel US-based technology companies to hand over data, regardless of where that data is physically stored. Your production database sits in AWS eu-central-1? Legally, it’s still within reach of US warrants.
For many workloads, that’s fine. GDPR doesn’t strictly require all EU resident data to remain within EU borders. But for regulated industries (healthcare, banking, government, critical infrastructure), the distinction between data residency and data sovereignty has become the difference between passing and failing an audit.
What EU Data Residency Actually Means
EU data residency is straightforward as a technical concept: your data is stored on servers physically located within the European Union. Frankfurt, Dublin, Amsterdam, Stockholm. Pick a region, your bytes live there.
The legal definition is where companies get tripped up. Storing data in the EU doesn’t automatically mean that data is governed by EU law.
A US-headquartered company storing data in Frankfurt remains subject to the US CLOUD Act. US authorities can compel disclosure regardless of where the bits sit.
So “EU data residency” answers where. It doesn’t answer under whose law. That’s data sovereignty, and the gap matters for regulated industries.
Data Residency vs. Data Sovereignty: The Distinction That Matters
Data residency means your data is stored on servers within a specific geographic boundary. Frankfurt, Dublin, Amsterdam. Simple physical location.
Data sovereignty means that data is subject only to the laws of that jurisdiction. No foreign government access. No cross-border legal exposure. The data lives and dies by EU law alone.
Most companies think they have sovereignty when they only have residency. That gap is widening as enforcement tightens across GDPR, NIS2, DORA, and the EU Data Act.
A banking client we spoke with ran their entire customer data platform on a major US cloud provider’s EU region. Their compliance audit flagged it as a concentration risk under DORA. Not because the technology was inadequate, but because the corporate jurisdiction of the provider exposed data to non-EU legal frameworks.
What GDPR Actually Requires
GDPR doesn’t mandate EU data residency. What it does mandate is that personal data transferred outside the EU/EEA receives “essentially equivalent” protection.
Three mechanisms for lawful international transfers:
- Adequacy decisions. The European Commission declares a country provides adequate data protection. The US currently has adequacy under the EU-US Data Privacy Framework, which survived its first court challenge in September 2025 (the Latombe case before the EU General Court). An appeal is pending and a Schrems-style civil challenge remains plausible.
- Standard Contractual Clauses (SCCs). Pre-approved contract templates that bind the receiving party to EU data protection standards.
- Binding Corporate Rules (BCRs). For multinational organizations transferring data between their own entities.
In practice, keeping data in the EU is the path of least resistance. No adequacy decisions to monitor. No SCCs to maintain. No risk of a Schrems III ruling invalidating your transfer mechanism overnight.
The Cloud Provider Landscape
US hyperscalers with EU regions
AWS, Azure, and Google Cloud all offer EU data center regions. They’re feature-rich, well-documented, and your engineering team already knows them.
The trade-off: US jurisdiction. The CLOUD Act applies.
Hyperscalers have responded with sovereign cloud configurations. Microsoft Cloud for Sovereignty offers Sovereign Public and Private Cloud variants. AWS European Sovereign Cloud went live in January 2026 with its first region in Brandenburg, Germany, operated by EU-resident staff under a separate AWS legal entity.
These are real steps forward. The underlying corporate parent is still US-based, but the operational and legal boundaries are tighter than standard EU regions.
For most non-regulated workloads, US hyperscalers with EU regions are perfectly acceptable under GDPR. Use SCCs, enable encryption with customer-managed keys, and document your transfer impact assessment.
European cloud providers
OVHCloud (France), Hetzner (Germany), IONOS (Germany), Scaleway (France), UpCloud (Finland). EU-headquartered. EU-jurisdictioned. No CLOUD Act exposure.
The trade-off: fewer managed services, smaller ecosystems, and potentially less mature tooling. You won’t find the equivalent of every AWS service. But for compute, storage, databases, and Kubernetes hosting, they’re battle-tested.
Hetzner is particularly popular in the German market. Competitive pricing. Data centers in Nuremberg, Falkenstein, and Helsinki. GDPR-compliant by default because there’s no jurisdictional complexity.
The hybrid approach
This is what we recommend for most clients. Put sensitive data (PII, financial records, health data) on EU-sovereign infrastructure. Run everything else wherever it makes engineering sense.
Your user authentication database and customer records on Hetzner. Your content delivery, analytics processing, and non-sensitive workloads on AWS or Azure. Connected via encrypted VPN or private network links.
You get sovereignty where it matters and hyperscaler features where you need them. The complexity is manageable.
How Major SaaS and AI Vendors Handle EU Data Residency
Cloud infrastructure is one layer. The SaaS and AI tools your team uses every day are another.
Most major vendors now offer some form of EU data residency, but the implementation varies. EU residency rarely equals EU sovereignty.
This is the state of play as of mid-2026 for the vendors people ask us about most. Verify against each provider’s current documentation before signing contracts.
| Vendor | EU residency offering | Corporate jurisdiction | Notes |
|---|---|---|---|
| AWS | EU regions in Ireland, Frankfurt, Paris, Stockholm, Milan, Spain, Zurich. European Sovereign Cloud (Brandenburg) live since January 2026 with EU-resident staff and a separate AWS legal entity. | US (Sovereign Cloud: EU-operated subsidiary) | Sovereign Cloud is a genuine step toward EU sovereignty. Standard EU regions remain subject to CLOUD Act. |
| Microsoft 365 / Azure | EU Data Boundary completed February 2025 (Phase 3 added professional services / support data). M365 Copilot in-country processing rolling out to 15 countries through 2026, starting with Australia, India, Japan and the UK by end of 2025. | US | Cloud for Sovereignty offers Sovereign Public and Sovereign Private Cloud variants. CLOUD Act still legally applies. |
| Google Cloud | EU regions with Data Region controls. Sovereign Controls partnerships with T-Systems (Germany) and Thales (France). | US (sovereign variants via EU partners) | Google Workspace data region selection available for Enterprise tiers. |
| Anthropic (Claude) | EU routing for direct API customers via console.anthropic.com. EU inference profiles via AWS Bedrock and Google Vertex AI. Microsoft Foundry EU support listed as “coming 2026”. | US | Default API tier stores in US. Explicit EU configuration and a DPA are required. |
| OpenAI | Data residency in Europe for ChatGPT Enterprise, Edu, and the API Platform (selectable per workspace or project). | US | Customer content stored at rest in the selected region. Model requests are not stored at rest. |
| GitHub Enterprise | EU data residency GA since October 2024 on ghe.com. Expanded to EFTA (Norway, Switzerland) in 2026. Copilot residency aligned with Microsoft EU Data Boundary. | US (Microsoft subsidiary) | Aligns with Microsoft EU Data Boundary; same legal posture. |
| Supabase | Frankfurt region (eu-central-1) for primary data and native backups. | US (Delaware C-corp) | Residency yes, sovereignty no. CLOUD Act applies. |
| Stripe | EU payment processing via Stripe Payments Europe Ltd (Ireland), licensed under EU regulatory framework. | EU subsidiary under US parent | Payment data processed in EU regions for European businesses. |
| Slack (Salesforce) | EU Data Residency for Enterprise Grid since 2021 (Frankfurt, Paris). | US | Customer content stored in the selected EU region. |
| Notion | EU data residency on AWS Frankfurt (eu-central-1) for Enterprise plan customers, launched 2025. | US | Migration of existing workspaces available via account team. |
| Cloudflare | EU jurisdiction controls via Data Localization Suite. | US | Regional services keep traffic, keys, and metadata in-region. |
| Atlassian | Cloud data residency for Confluence, Jira, and Jira Service Management in Germany and Ireland. | US-listed (Australian HQ) | Available on Enterprise plan and above. |
| HubSpot | EU data hosting (Frankfurt) for customers in EU regions. | US | Available for new EU customers. Existing customers can request migration. |
A pattern emerges. Almost every major SaaS vendor now offers EU residency. Almost none offer true sovereignty.
The CLOUD Act still applies to anything with a US corporate parent. If your compliance framework distinguishes the two (DORA, BSI, sector-specific regimes), vendor selection matters as much as cloud region selection.
For workloads that need EU-only AI inference, our guide to AI on-premise in Europe covers the alternatives.
Regulatory Requirements Beyond GDPR
NIS2 doesn’t directly mandate data residency, but it requires supply chain risk management. If your cloud provider’s jurisdiction introduces legal risks, that’s a supply chain risk you need to assess and document. See our NIS2 compliance guide for the full picture.
DORA (Digital Operational Resilience Act) is the strictest on this topic. In force since January 17, 2025, it requires financial entities to manage ICT third-party concentration risk.
Relying entirely on a single US hyperscaler is a documented compliance concern. Multi-cloud and EU-sovereign alternatives are increasingly expected by national supervisors.
The EU Data Act adds data portability requirements for cloud services. Providers must offer tools for data export and switching. Lock-in strategies that prevent migration are now regulated.
Sector-specific rules can be even stricter. German healthcare data (Gesundheitsdaten) faces additional requirements under national law. Financial data under BaFin regulations. Public sector data under BSI guidelines.
Architecture Decision Framework
Ask these four questions:
1. What data classification levels do you have? Not all data needs the same protection. Public marketing content and confidential customer health records are not equivalent. Define tiers. Apply different residency requirements to each.
2. What’s your regulatory exposure? NIS2-regulated? DORA-applicable? Processing children’s data? Healthcare data? Each regulation shifts the calculus. Map your obligations before choosing infrastructure.
3. What’s your transfer risk tolerance? The EU-US Data Privacy Framework survived its first court challenge in September 2025, but an appeal is pending and a Schrems-style civil challenge remains plausible. If your business depends on continuous access to EU personal data, betting on a transfer mechanism that could get invalidated is a strategic risk.
4. What’s the engineering cost of sovereignty? Full EU-sovereign infrastructure means fewer managed services. More ops burden. Higher per-unit costs for certain workloads. Weigh this against the compliance cost of the alternative.
For most EU-focused SMBs, the sweet spot is European hosting for production data and customer-facing systems, with hyperscaler services for non-sensitive compute and global CDN delivery.
Practical Implementation Steps
Step 1: Data inventory. Classify every data type you process. Personal, sensitive personal, financial, health, business-confidential, public. Map where each currently lives.
Step 2: Regulatory mapping. For each data type, identify which regulations apply and what residency requirements they create.
Step 3: Provider assessment. Evaluate your current and potential cloud providers against: corporate jurisdiction, CLOUD Act exposure, contractual protections, encryption key management, certification (ISO 27001, C5, SOC 2), and sub-processor chains.
Step 4: Architecture design. Design your infrastructure topology. Which services run where? How does data flow between environments? Where are the encryption boundaries?
Step 5: Document everything. Transfer Impact Assessments for any cross-border data flows. Supplier risk assessments for each cloud provider.
Architecture decision records for your residency choices. Regulators ask for this documentation. Have it ready.
For the broader EU compliance picture, see our pillar guide on EU compliance for software teams. If you’re building on GDPR-compliant architecture, our architecture guide covers the privacy layer in detail.
Sorting out data residency for your EU software? Let’s map out your architecture together. We help teams make pragmatic sovereignty decisions without over-engineering.
