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.
Residency vs. 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, though legal challenges are ongoing.
- 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. Some hyperscalers offer “sovereign cloud” configurations (Microsoft Cloud for Sovereignty, AWS European Sovereign Cloud launching 2025) with enhanced controls. These are steps in the right direction, but the underlying corporate entity remains US-based.
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.
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. Financial entities must manage ICT third-party concentration risk.
Relying entirely on a single US hyperscaler is a compliance concern. Multi-cloud and EU-sovereign alternatives are increasingly expected.
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 exists today but could face legal challenges. 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.
