Glossary · Data protection concept Data Residency (Data Residency)
A contractual and technical commitment that data is physically stored within a specific jurisdiction (typically the EU/EEA). Distinct from data sovereignty: residency addresses where data sits, not who has legal reach over it. A US-parent vendor offering EU data residency remains subject to the CLOUD Act.
## The concept
**Data residency** is a vendor commitment — usually contractual — that customer data is physically stored within a defined jurisdiction, most commonly the EU or EEA. It is often part of a Data Processing Agreement under GDPR Article 28 and is the answer most vendors give when a European customer asks "where is our data?"
## Why residency is not sovereignty
Data residency and **data sovereignty** are related but distinct concepts, and treating them as interchangeable is a common and expensive mistake.
- **Data residency** answers: *Where is the data physically stored?*
- **Data sovereignty** answers: *Who has legal reach to compel disclosure or access to the data, regardless of where it sits?*
A US-headquartered vendor can genuinely commit to storing European customer data only in a Frankfurt data centre. That commitment is technically real. It does not, however, prevent US authorities from compelling the vendor to disclose that Frankfurt-hosted data under the **CLOUD Act** or **FISA Section 702**.
The European Court of Justice made this explicit in Schrems II (2020): contractual clauses, encryption, and residency commitments do not remove the risk of extraterritorial legal reach when the vendor's parent legal entity sits under a foreign jurisdiction with mandatory disclosure powers.
## What residency does achieve
Data residency is not worthless — it addresses several genuine risks:
1. **Latency and performance** — data physically closer to users performs better.
2. **Regional regulatory frameworks** — some EU member states have national data-localisation rules (public sector, health, defence) that require in-country storage.
3. **Some GDPR obligations** — Chapter V transfer rules become easier when data doesn't leave the EEA.
4. **Contract enforceability** — a vendor promising EU residency can be held to that contractually, and breaches are actionable.
It just does not address the CLOUD Act / FISA 702 exposure problem — that requires *sovereignty*, not residency.
## The "EU region" pattern in cloud vendors
Every major US cloud provider now markets EU regions:
- AWS EU (Frankfurt, Paris, Stockholm, Milan, Zurich, Ireland, Spain)
- Microsoft Azure Europe (Amsterdam, Dublin, Paris, Zurich, Milan, Berlin, Frankfurt)
- Google Cloud Europe (Belgium, Netherlands, Finland, Frankfurt, Paris, Madrid, Milan, Warsaw, Zurich)
Each of these is a data-residency commitment, not a data-sovereignty guarantee. The parent corporation — Amazon.com Inc., Microsoft Corporation, Alphabet Inc. — is US-incorporated. The CLOUD Act obligation follows the corporate parent, not the physical server location.
Even Microsoft's "EU Data Boundary" (rolled out 2023-2024, further extended in 2026) — a genuine engineering achievement that constrains a wider set of processing to EU regions — remains a residency commitment. It reduces the day-to-day operational exposure but does not remove the structural CLOUD Act reach.
## Sovereign cloud vs residency-only
Two categories of European cloud offering address the sovereignty question, not just residency:
1. **French Cloud de Confiance certification** — SecNumCloud + Qualification-SecNumCloud, requiring the operator to be under exclusive EU ownership and control. Bleu (Orange + Capgemini fronted joint venture around Microsoft) and S3NS (Google + Thales) aim at this but their US-technology-partner structure remains a subject of debate.
2. **Genuinely EU-headquartered vendors** — Hetzner (Germany), Scaleway (France), OVHcloud (France), Infomaniak (Switzerland), Bunny.net (Slovenia), UpCloud (Finland). These are structurally EU at the corporate-parent layer.
## How to evaluate the difference in practice
When a vendor markets "GDPR-compliant EU data residency," the useful follow-up questions are:
1. Where is the parent legal entity incorporated? (Delaware or in the EU?)
2. Is the parent listed on a US stock exchange, and does it therefore file SEC disclosures?
3. Are there US subsidiaries in the corporate chain that could be compelled to hand over EU data under CLOUD Act?
4. What is the response if a US National Security Letter arrives — and what is the response if the vendor is not permitted to disclose that a NSL arrived?
For genuinely sensitive workloads — regulated health data, financial transaction data, defence-adjacent information, public-sector citizen data — only affirmative answers to #1 and negative answers to #3 constitute meaningful protection. Data residency alone is insufficient.
## Bottom line
Data residency is a useful and often necessary control, but treating it as equivalent to data sovereignty is the most common category error in European vendor procurement. If your compliance officer accepts "the data is in Frankfurt" as an answer to CLOUD Act exposure, you have residency, not sovereignty — and under 2026 regulatory conditions (NIS2, DORA, sector-specific rules) that may no longer be enough.
Was this helpful?
Thanks for your feedback!