A Field Guide to Data Residency in 2026
What the regulations actually require, what vendors actually provide, and where the gap is
Every organisation I work with has a data residency policy. Almost none of them have a data residency implementation that matches the policy.
The gap between the two is where the liability lives.
This essay is a practitioner’s guide to closing that gap. It covers what the regulations actually require (not what the vendor sales decks say they require), what the major cloud providers actually offer (not what their compliance pages claim), and what a genuine implementation looks like.
What data residency actually means
Data residency is the requirement that data be stored and processed within a specific geographic or legal jurisdiction. It is distinct from — but related to — data sovereignty, which is the broader requirement that data be subject to the laws of a specific jurisdiction.
The confusion between the two is a source of significant compliance risk. A cloud provider can offer data residency (your data is stored in Frankfurt) while not offering data sovereignty (your data is still subject to US law because the provider is a US company).
What the regulations require
The regulatory landscape for data residency in 2026 is a patchwork. There is no single “data residency regulation.” Instead, there are:
GDPR Chapter V — governs transfers of personal data to third countries. Requires either an adequacy decision, standard contractual clauses, or binding corporate rules. Does not, by itself, require data to stay in the EU — but the practical effect of Schrems II is that transfers to the US are legally precarious.
NIS2 Directive — applies to operators of essential services and digital service providers. Requires “appropriate and proportionate technical and organisational measures” to manage security risks. Increasingly interpreted by national supervisory authorities to include data residency requirements for critical infrastructure.
DORA (Digital Operational Resilience Act) — applies to financial entities and their ICT service providers. Requires contractual provisions that give financial entities the right to audit their ICT providers and ensure data is accessible and recoverable. Has specific implications for cloud contracts.
Sector-specific requirements — healthcare (MDR, IVDR), financial services (EBA guidelines), public sector (various national requirements). These often have explicit data residency requirements that go beyond GDPR.
The key insight is that compliance is not binary. The question is not “are we compliant?” but “under which legal bases, for which categories of data, processed by which systems, are we compliant?” The answer is almost always different for different parts of the organisation.
What cloud providers actually offer
Here is a table of what the major providers offer for EU data residency, as of early 2026:
| Provider | EU data residency | EU data sovereignty | US Cloud Act exposure | Contractual audit rights |
|---|---|---|---|---|
| AWS (EU Sovereign Cloud) | Yes (preview) | Partial | Yes (US HQ) | Limited |
| Azure (EU Data Boundary) | Yes | Partial | Yes (US HQ) | Limited |
| Google Cloud (EU) | Yes | Partial | Yes (US HQ) | Limited |
| OVHcloud | Yes | Yes (FR law) | No | Yes |
| Hetzner | Yes | Yes (DE law) | No | Yes |
| Deutsche Telekom (OTC) | Yes | Yes (DE law) | No | Yes |
The “partial” in the sovereignty column for US providers reflects the reality that while these providers have made contractual commitments to store and process data in the EU, they remain subject to US law for purposes of government access. The EU-US Data Privacy Framework provides some protection, but its legal durability is uncertain following the pattern of Safe Harbor and Privacy Shield.
The implementation gap
The most common implementation gap I encounter is what I call the residency illusion: the organisation has selected an EU region for their primary workloads, but data is leaking out of that region through:
- Logging and monitoring pipelines — CloudWatch, Datadog, Splunk. Where are the logs stored? Where is the SIEM?
- Backup and disaster recovery — Cross-region replication is often enabled by default. Is the replica in the EU?
- AI/ML services — Training data sent to managed AI services may be processed in regions outside the EU, even if the primary workload is EU-based.
- Support access — When you raise a support ticket, which engineers can access your environment? From which countries?
- Third-party integrations — SaaS tools, analytics platforms, marketing automation. Each integration is a potential data transfer.
A practical implementation approach
Here is the approach I use when implementing data residency for clients.
Step 1: Data classification. Not all data has the same residency requirements. Personal data under GDPR has different requirements than financial transaction data under DORA, which has different requirements than internal operational data. Build a classification scheme and apply it.
Step 2: Data flow mapping. For each data class, map every system that stores or processes it. Include the physical location of storage, the legal jurisdiction of the provider, and the access controls in place.
Step 3: Gap analysis. Compare the data flow map against the residency requirements for each data class. The gaps are your compliance risks.
Step 4: Remediation prioritisation. Not all gaps are equal. A gap involving special category data (health, biometric, political opinion) under GDPR Article 9 is higher priority than a gap involving operational metadata. Prioritise by risk.
Step 5: Technical controls. For each gap, implement the appropriate control:
- Data localisation: ensure data is stored and processed only in approved jurisdictions
- Encryption with customer-managed keys: ensures that even if data is physically accessible to a provider, it is not readable without your keys
- Access logging and alerting: know when data is accessed and by whom
- Contractual controls: ensure your contracts with providers include the right to audit, the right to erasure, and explicit commitments on data location
Step 6: Ongoing monitoring. Data residency is not a one-time project. New systems are added. Integrations change. Providers update their architectures. Build monitoring that alerts when data flows outside approved jurisdictions.
The AI complication
AI workloads have made data residency significantly more complex. The specific complications:
Inference endpoints — When you send a prompt to an AI model, where is the inference happening? For managed AI services, this is often not in the EU, even if you have selected an EU region.
Retrieval-Augmented Generation (RAG) — RAG systems retrieve documents from a knowledge base to augment model responses. If the knowledge base contains personal data, every retrieval is a data processing operation. Where does that processing happen?
Agent memory — Agentic AI systems accumulate context over time. Where is that context stored? How long is it retained? Who can access it?
These are not hypothetical questions. They are questions that EU supervisory authorities are beginning to ask. The organisations that have answers will be in a much better position than those that don’t.
The honest conclusion
Data residency compliance in 2026 is achievable. It is not easy, and it is not cheap, but it is achievable. The organisations that are genuinely compliant — not just defensible in a meeting — have done the unglamorous work: the data flow mapping, the classification, the gap analysis, the contractual review.
The organisations that are not compliant have usually done one of two things: they have assumed that selecting an EU region is sufficient (it is not), or they have outsourced the compliance question to their cloud provider’s compliance page (which answers a different question than the one you need answered).
The gap between policy and implementation is where the liability lives. Closing it is not a technical problem. It is a discipline problem. And discipline, unlike technology, does not have a vendor.