Data residency in 2026: what regulators now expect from your cloud, and how to prove it

Ask a compliance team where their EU customer data lives, and most will point confidently at a dashboard showing a Frankfurt or Dublin region. Ask their legal counsel whether that data is beyond the reach of a foreign government demand, and the confidence usually drops. 

Those are two different questions. Since 12 September 2025 there has been a dated EU obligation that turns on the second one rather than the first.

Why residency and sovereignty stopped being the same conversation

Key takeaway: Data residency means your data is stored in a defined geographic boundary. Data sovereignty means that data is subject to the laws of the place it sits, including who can legally compel access to it. An organization can satisfy the first completely while remaining exposed on the second.

The distinction matters because it's exactly where audits and regulatory reviews are increasingly focused. Because 18 U.S.C. 2713, added by the US CLOUD Act, removes the extraterritoriality defence to US legal process, so a provider of electronic communication or remote computing services subject to US jurisdiction must respond in respect of data in its possession, custody or control wherever the servers sit, hosting data in an EU region doesn't automatically shield it from US legal demands. 

Regulators across multiple EU data protection authorities have already found specific US cloud arrangements to be in tension with GDPR on exactly this basis: the Austrian data protection authority found, in a partial decision issued in December 2021 and published the following month, that continued use of a US-hosted analytics tool violated GDPR's data export requirements, and France's CNIL reached the same conclusion the following month, both stemming from the 101 complaints noyb filed across the EU and EEA in August 2020, weeks after Schrems II invalidated the previous EU-US transfer framework. 

Both decisions predate the EU-US Data Privacy Framework adequacy decision of July 2023, which is in force and changes the analysis materially where the importer is DPF-certified. The General Court dismissed the Latombe challenge in September 2025, and an appeal is pending, so the framework holds for now without being settled.

This is not a hypothetical concern that regulators might get around to eventually. It's the live distinction driving new product categories (sovereign cloud regions from major providers), new national programs (France's SecNumCloud qualification scheme under ANSSI, Germany's public sector cloud arrangements), and a measurable shift in enterprise spending. 

Read those carefully: several are European entities operating US vendor technology under national supervision, which improves operational control without removing the jurisdictional question. 

According to Gartner, worldwide sovereign cloud IaaS spending is forecast to reach $80 billion in 2026, a 35.6% increase from 2025, with regulated industries and critical infrastructure organizations among the primary buyers behind the government itself. In Europe specifically, sovereign cloud IaaS spending is projected to grow from $6.9 billion in 2025 to $12.6 billion in 2026, en route to $23.1 billion by 2027. 

That's not a niche compliance line item. It's a structural reallocation of enterprise infrastructure spend, driven by exactly the residency-versus-sovereignty gap most compliance programs haven't closed yet.

What's actually changed in the regulatory expectation

Key takeaway: Three separate regulatory tracks, data protection, operational resilience, and cybersecurity, have converged on the same underlying demand: prove your data governance holds up under scrutiny, not just describe it in a policy document.

• GDPR enforcement has sharpened around transparency and cross-border transfer, not just storage location. The regulation remains the baseline for EU data protection, but post-Schrems II, the practical compliance question shifted from simple geographic location to assessing what legal authority governs the provider and whether technical safeguards prevent foreign government access throughout the data lifecycle. Standard Contractual Clauses alone are no longer treated as sufficient if the underlying legal framework of the provider's home country allows access that overrides those contractual promises.
• The EU Data Act adds a specific, actionable requirement, for a defined category of data. Since September 2025, Chapter VII of the EU Data Act requires providers of data processing services, irrespective of their place of establishment, where they serve customers in the Union, to take all adequate technical, organisational and legal measures, including contracts, to prevent third-country governmental access to and transfer of non-personal data held in the Union where that access would conflict with EU or member state law, a protection that sits alongside, and is constructed differently from, the personal data protections GDPR's Article 48 already provides. This converts a previously abstract sovereignty concern into a concrete provider obligation, though organizations need to correctly classify their data as personal or non-personal to know which protection actually applies.
• NIS2 extends the expectation beyond data protection into operational cybersecurity. The transposition deadline was 17 October 2024, but transposition is not finished: in July 2026, the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify national measures. Where it has been transposed, NIS2 requires cybersecurity risk management measures, gives competent authorities the power to require independent security audits of essential entities, and imposes staged incident reporting: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month of that notification. This is a different regulatory lever than GDPR, but it's pulling in the same direction: demonstrable, auditable control over your infrastructure and how it responds to incidents.
• DORA (the EU's Digital Operational Resilience Act) adds a resilience and audit layer specifically for financial entities. In effect since January 2025, it requires financial entities to hold contractual audit and access rights over their ICT providers and gives the European Supervisory Authorities direct inspection powers over the providers they designate as critical, of which there were 19 as of November 2025. Article 30 also flows mandatory contractual terms down to ICT providers in any sector once a financial entity becomes a customer.
• The UK is following the same direction independently, and moving quickly. The Cyber Security and Resilience Bill cleared the House of Commons in June 2026 and is currently progressing through the House of Lords, with Royal Assent expected later this year and phased enforcement rolling out through 2028. It extends NIS-style obligations to managed service providers, data centers, and critical suppliers, meaning the UK's regulatory bar is rising even outside the EU's specific frameworks.

Individually, these are separate regulatory tracks with separate scopes. Collectively, they point to the same organizational requirement: the ability to demonstrate, not just assert, where data lives, who can access it, and under what legal authority.

Why this makes region choice a governance decision

Key takeaway: Choosing where a workload runs used to be a latency and cost decision. It's now a compliance decision with a defensible reasoning trail attached to it.

For most of the last decade, region selection was an operational choice: pick the region closest to your users, or the one with the best pricing for your workload. That calculus hasn't disappeared, but it's no longer sufficient on its own. 

A regulator or auditor asking about a specific customer's data now expects a specific, defensible answer: which region, under which provider's legal jurisdiction, with what transfer safeguards in place if any data crosses a border during processing, backup, or support access.

This is harder than it sounds for most multicloud and multi-provider organizations, because region selection often happens at the infrastructure layer, decided once by whoever set up a given service, and rarely revisited unless something breaks. 

The compliance question, by contrast, needs an answer that holds up per workload, per customer segment, and per applicable regulation, which is a fundamentally different level of granularity than most infrastructure decisions were designed to produce.

What proving it actually requires

Key takeaway: Demonstrating compliance with residency and sovereignty expectations means being able to show, on demand, where a given workload's data resides, which regulatory framework applies, and what governance controls enforce that placement, not just describe the policy that's supposed to.

The organizations that can answer a residency or sovereignty question quickly share a specific property: their region choice is retrievable and verifiable as deployed state, with a retention period that covers the audit window, not maintained as a separate policy document that has to be checked against reality when someone asks. 

When a workload's region is retrievable from the deployed state through an API rather than asserted in a policy document, the answer to "where does this data live" is a query against the actual deployed state, not a document someone has to go verify is still accurate.

This matters increasingly for multi-region and multicloud organizations specifically. Deploying across AWS, Azure, Google Cloud, IBM, or OVHcloud regions to meet a specific customer's residency requirement only works as a governance answer if the region assignment is consistent, auditable, and doesn't silently drift when infrastructure changes. 

An organization that can demonstrate this, region by region, workload by workload, is answering a fundamentally different (and much stronger) question than one that can point to a general data residency policy and hope the underlying infrastructure still matches it.

A useful first pass: take the workload holding your most regulated data and try to produce four things for it. Where it is deployed, retrieved from the deployed state rather than from a document, and retained for a period that covers your audit window. Who changed it and when. Which subprocessors touch its data, including backups, logs, support tooling, and any inference endpoint. And whether that data is personal or non-personal. Whatever you cannot produce is the finding.

Run the compliant cloud readiness assessment 

Frequently asked questions (FAQ)

What's the practical difference between data residency and data sovereignty? 
Data residency means your data is physically stored within a defined geographic boundary, such as the EU. Data sovereignty means that data is subject to the legal authority of that jurisdiction throughout its lifecycle, including who can compel access to it. An organization can achieve full residency (data stored in Frankfurt) while remaining exposed on sovereignty if the operating provider is subject to US jurisdiction and to the US CLOUD Act's possession, custody, or control standard. Closing the sovereignty gap typically requires an operationally independent, non-US-controlled provider or architectural controls such as customer-managed encryption keys. Note the limit on that second option: key custody helps for data at rest and in transit, and does not help where the platform needs the data in the clear to run your application, which is the case for most application platforms.

Does choosing an EU region automatically satisfy GDPR? 
It satisfies the residency component, but GDPR compliance is broader than storage location. It requires a legal transfer mechanism for any data that does cross borders (such as Standard Contractual Clauses or an adequacy decision), appropriate technical safeguards, and accurate records of processing activity, including support and telemetry data flows that often get overlooked in a residency-only assessment.

Is DORA relevant outside the financial sector? 
Yes, if you supply them. DORA applies to financial entities operating in the EU and their critical ICT providers, and Article 30 flows mandatory contractual terms down to ICT providers in any sector the moment a financial entity becomes a customer, covering audit rights, exit plans, subcontracting and incident reporting. Direct supervisory inspection applies only to the providers the European Supervisory Authorities designate as critical. However, its core requirement, demonstrable operational resilience and regulator access to relevant systems, is a pattern spreading into other frameworks like NIS2 and the UK's Cyber Security and Resilience Bill. Organizations outside financial services should treat DORA's requirements as an indicator of where broader regulatory expectations are heading.

How does multicloud or multi-region deployment affect residency compliance? 
It can help or hurt depending on whether region assignment is consistently enforced. Multi-region deployment lets an organization meet different residency requirements for different customer segments or jurisdictions, which is a genuine advantage. But this only functions as a compliance answer if the region assignment for each workload is documented, auditable, and doesn't drift between what's declared and what's actually deployed. Without that consistency, multi-region deployment adds complexity without closing the compliance gap.

Does the EU Data Act protect personal data from foreign government access too? 
The Data Act's Chapter VII specifically addresses non-personal data. Personal data is addressed by a differently constructed provision in GDPR's Article 48, which restricts recognition of foreign court or authority decisions requiring transfer of personal data absent a valid international agreement. The EDPB has been explicit in Guidelines 02/2024 that Article 48 is not itself a ground for transfer, and the article ends with the words without prejudice to other grounds for transfer under Chapter V, so it does not operate as a blocking statute. It also addresses process served on the EU entity, and offers little where the compulsion runs to a parent company outside the EU. In practice, this means organizations need to correctly classify a given dataset as personal or non-personal to know which regulation's anti-compulsion protection actually applies to it, a determination that matters because the two regimes overlap rather than exclude each other. Where personal and non-personal data are inextricably linked, GDPR governs the whole dataset, while Article 32 still places its obligation on your provider for the non-personal component.

What should an IT leader actually check first? 
Start with whether region assignment for each workload is declared in a way that can be queried and verified, rather than set once and assumed to remain accurate. From there, map which regulatory frameworks actually apply to which workloads and customer segments, since GDPR, DORA, and NIS2 have different scopes and different specific requirements. The gap between assumed compliance and demonstrable compliance is usually found in that mapping exercise, not in the underlying infrastructure itself.