Jun. 25, 2026
17 minutes read
Share this article
Most European enterprises believe they have solved their data sovereignty problem. They store data in Frankfurt or Dublin. They chose an AWS or Azure availability zone in the EU. They run a GDPR compliance program. What they have actually solved is data residency — a different and narrower problem.
Data sovereignty is not about where data sits. It is about who has the legal authority to compel access to it, which laws govern the systems that process it, and whether the organization retains meaningful operational control when political or legal conditions change. By that measure, a Frankfurt AWS zone does not satisfy data sovereignty if US authorities can issue a CLOUD Act request that forces disclosure regardless of where the servers are physically located.
That gap — between residency and sovereignty — is now the central concern for technology leaders across regulated industries. The global sovereign cloud market was valued at $154.69 billion in 2025 and is projected to reach $195.35 billion in 2026, growing at a 27% CAGR through 2034. Seventy-two percent of European organizations now cite data sovereignty as a key criterion in vendor selection. The conversation has moved well past compliance into procurement strategy, architecture design, and geopolitical risk management.
Data sovereignty means that data is subject to the laws and governance structures of the jurisdiction in which it is collected, stored, and processed — and that the organization controlling that data retains enforceable rights over it. It is a legal, contractual, and operational concept simultaneously.
Data residency asks: where is this data physically located?
Data sovereignty asks: which legal system governs this data, who can compel access to it, and does the organization retain real operational control over the systems that handle it?
An organization can satisfy residency requirements and still lack sovereignty if:
This distinction matters because the “residency illusion” — the belief that a local data center footprint satisfies sovereignty — has become the dominant misconception the 2025–2026 regulatory environment is actively correcting.
Five regulatory developments have fundamentally changed what data sovereignty means in operational terms.
The EU Data Act became fully applicable on September 12, 2025. It mandates that cloud service providers implement data portability and interoperability requirements, actively eliminating vendor lock-in barriers. Providers must facilitate seamless switching between services, and egress fees are scheduled for elimination by January 2027. The Digital Markets Act is simultaneously investigating AWS and Microsoft Azure as potential gatekeepers, which would impose further interoperability obligations.
DORA became fully applicable in early 2025, directly affecting banking, insurance, and financial services cloud procurement. It requires financial entities to manage third-party ICT risks with rigorous documentation and concentration risk controls. Relying on a single US-based hyperscaler is now treated as a concentration risk that regulators view as capable of creating systemic failure. DORA has fundamentally changed the cloud conversation for banks in ways that other sectors will follow.
NIS2 extends cybersecurity obligations across critical infrastructure and digital service providers. It mandates robust risk management, incident reporting within 24 hours, and supply-chain security. Cloud workloads handling critical infrastructure data now carry explicit audit and protection requirements.
The EU released its Cloud Sovereignty Framework in October 2025, introducing eight specific requirements for sovereign cloud services and a sovereignty score that assesses exposure to foreign legislation including the CLOUD Act. This is the first formal scoring mechanism for cloud sovereignty compliance in the EU market.
The fundamental legal conflict at the center of data sovereignty decisions in 2026 remains unresolved. The US CLOUD Act allows US authorities to demand that US-based cloud providers hand over data stored anywhere in the world — including in EU data centers. No provision of GDPR or EU law prevents that demand from being issued. No technical location choice — Frankfurt, Dublin, Amsterdam — changes the legal exposure if the provider is US-incorporated.
As of early 2026, cumulative GDPR fines have reached €7.1 billion, with data transfer violations remaining a high-risk enforcement area. The EU-US Data Privacy Framework provides a partial framework, but Microsoft’s own 2026 guidance acknowledges that it cannot provide an absolute guarantee that EU data will never be requested by US authorities. Organizations in regulated sectors that rely on US-headquartered providers carry a sovereignty gap that regional availability zones do not close.
| Dimension | Data residency | Data sovereignty |
|---|---|---|
| Core question | Where is data stored? | Who governs and can compel access to data? |
| Satisfied by | Local data center or availability zone | Jurisdiction-bound legal structure + operational controls |
| CLOUD Act risk | Not addressed | Addressed when provider is EU-incorporated |
| Encryption key control | Not required | Customer-managed keys strengthen sovereignty posture |
| Vendor exit | Not relevant | Low exit cost and portability are sovereignty requirements |
| Administrative access | Not addressed | Local administrative pathways required for full sovereignty |
| Compliance instruments | GDPR Article 5 (storage limitation) | GDPR + DORA + Data Act + Cloud Sovereignty Framework |
The practical implication: organizations that have addressed residency but not sovereignty carry meaningful regulatory and operational risk that their compliance programs may not have surfaced.
Data sovereignty weakens as mission-critical systems migrate toward managed services that are technically convenient but architecturally entrenching. The problem is not cloud scale — it is asymmetric dependence. When one party controls the infrastructure, the product roadmap, the billing logic, the managed services, and the integration patterns, the customer’s room to maneuver contracts over time.
This dependence develops in four recognizable stages:
Stage 1 — Convenience becomes architecture. Teams adopt managed databases, identity platforms, analytics pipelines, AI services, and event infrastructure because they compress delivery timelines. Over time, those services stop being optional accelerators and become structural dependencies. At that stage, switching carries genuine architectural risk, not just migration effort.
Stage 2 — Contracts diverge from operational reality. Procurement agreements may describe the relationship as flexible or multi-vendor. Production systems tell a different story. The gap between contractual flexibility and the actual cost of replacement is where vendor lock-in becomes a sovereignty concern.
Stage 3 — Security is externalized. When identity management, secrets handling, logging, monitoring, and policy enforcement reside primarily within a single external vendor ecosystem, operational authority has effectively migrated outside the organization. Data sovereignty depends on where control resides, not only where records are stored.
Stage 4 — Exit costs become strategic costs. Once migration difficulty rises above a threshold, negotiating leverage falls proportionally. The organization then faces a sovereignty constraint not from legal exposure alone but from operational inability to move when risk conditions change.
These stages explain why cloud governance frameworks increasingly connect data governance practices directly to sovereignty planning — the organizations with well-structured data classification, retention, and access control models are significantly better positioned to act on sovereignty decisions than those managing data informally.
The 2025–2026 period has introduced an AI-specific layer to data sovereignty that most cloud strategies have not yet fully addressed. AI model training data, inference pipelines, retrieval-augmented generation systems, and fine-tuned models all carry jurisdiction implications that differ from conventional data workloads.
When training data contains personal, proprietary, or regulated information, the question of which legal system governs its use during training — not just storage — becomes a sovereignty concern. When inference workloads process sensitive requests through third-party model APIs, data moves outside organizational control in ways that storage governance alone cannot address.
The EU AI Act, which reached full applicability in August 2026, imposes transparency, documentation, and human oversight requirements on high-risk AI systems. These requirements interact directly with data sovereignty: AI systems processing regulated data must be able to demonstrate jurisdictional compliance in the data pipeline, not only in the storage layer. US National AI Safety Standards (2025) similarly impose governance rules on AI training data stored or processed overseas.
For teams building AI-powered systems, sovereignty has become an architecture constraint as much as a legal one — jurisdiction-aware policies for where model training, fine-tuning, and inference workloads run are now part of production system design.
Regional and sovereign cloud options have expanded significantly in 2025–2026, giving organizations more concrete alternatives than the binary choice between US hyperscalers and on-premises repatriation. The right choice depends on how much residual CLOUD Act exposure is acceptable, which in turn depends on the workload’s regulatory classification — a strict EU provider eliminates the exposure entirely, while hyperscaler sovereign programs reduce but do not fully close it.
Gaia-X — Europe’s sovereign cloud initiative — reached 400+ certified service providers in 2025, creating the largest sovereign cloud ecosystem globally. It provides a framework for interoperable, GDPR-compliant cloud services governed entirely under EU law.
National sovereign cloud programs — France’s “Cloud de Confiance” and Germany’s Delos Cloud (operated in partnership with Microsoft but under EU administrative governance) provide government-grade sovereignty controls for regulated sectors. In these models, US technology is used but operational governance is explicitly constrained to EU-jurisdiction personnel and legal structures.
Hyperscaler sovereign programs — AWS European Sovereign Cloud, Microsoft 365 EU Data Boundary, and Google Sovereign Controls represent the major US providers’ attempt to address sovereignty concerns within their existing infrastructure. These programs offer meaningful improvements over standard regional deployments, but they cannot fully resolve the CLOUD Act exposure because the parent companies remain US-incorporated.
The practical implication for procurement decisions: a strict EU provider eliminates the CLOUD Act conflict entirely; hyperscaler sovereign programs reduce but do not eliminate it. For most organizations, the right answer is workload segmentation — applying strict sovereignty controls to the highest-risk data and workflows while retaining global platform access where sovereignty risk is low.
A serious data sovereignty strategy begins with workload classification, not with provider selection. Different workloads carry different sovereignty requirements, and applying uniform treatment to all of them is both unnecessarily expensive and strategically ineffective.
| Workload category | Typical sovereignty requirement | Appropriate cloud model |
|---|---|---|
| Customer PII, regulated financial data | High — jurisdiction control essential | EU-incorporated sovereign cloud or on-premises |
| Healthcare records, government data | High — sector-specific controls (C5, DORA) | Certified sovereign cloud (Gaia-X member, Cloud de Confiance) |
| AI training data on sensitive datasets | High — EU AI Act compliance required | Sovereignty-controlled compute environment |
| Core identity and access management | High — control plane must be local | Customer-managed, not delegated to hyperscaler |
| Internal collaboration, low-risk SaaS | Low — standard cloud acceptable | Global platform with standard controls |
| Public web content, CDN, low-risk compute | Minimal | Hyperscaler or multi-region global platform |
Data sovereignty improves materially when systems are built on open standards, containerized workloads, interoperable storage patterns, and well-defined APIs. This does not eliminate migration effort, but it lowers exit costs — which directly affects sovereignty posture. The cloud-native application development approach that embeds portability as a design constraint rather than a migration afterthought produces architectures that preserve sovereignty options over time.
Encryption key management, identity governance, logging retention, and policy enforcement should be designed to preserve local authority. Customer-managed encryption keys are one of the most operationally straightforward sovereignty controls available — they mean that even a provider with legal obligations to disclose data cannot hand over readable content without the customer’s key.
Data sovereignty is often framed in legal terms, but it is equally a security architecture decision. An organization that stores sensitive workloads in a sovereign region while maintaining weak privileged access models has not achieved meaningful sovereignty. Zero trust security architecture — segmented identity and access management, just-in-time administrative access, explicit privilege boundaries for operators and vendors, and auditable data movement policies — reinforces sovereignty at the operational layer, not only the legal one.
Retrofitting sovereignty controls onto deployed systems is expensive and slow. For teams building or modernizing cloud systems, embedding compliance testing and validation from the start — including region-specific access controls, audit trails, and recovery requirements — is significantly more cost-effective than addressing them after deployment.
Data sovereignty requirements vary substantially across regulated industries, and a generic cloud strategy rarely satisfies sector-specific obligations.
Financial services — DORA has created the most explicit sovereign cloud obligation in any sector. Banks and insurers must document concentration risk, maintain exit plans for critical ICT dependencies, and demonstrate that sovereignty controls are operational, not theoretical. A single US hyperscaler dependency is now a regulatory finding in many EU financial sector audits.
Healthcare — GDPR Article 9 governs special category health data. German healthcare providers must additionally meet the BSI’s C5 (Cloud Computing Compliance Criteria Catalogue) requirements. Sovereign cloud certification is a prerequisite for running digital health applications under German DiGA regulations.
Government and public sector — Public procurement increasingly includes explicit data sovereignty clauses. France and Germany have both published national cloud frameworks that restrict government workloads to certified sovereign providers. This trend is extending into public sector supplier requirements.
Technology companies and software vendors — The EU AI Act’s applicability from August 2026 creates sovereignty obligations for AI-driven product companies processing regulated data. Software vendors building for EU enterprise customers face growing contractual pressure to demonstrate data sovereignty compliance at the product architecture level, not just in their hosting agreements.
Structural dependence on dominant platforms is a liability, but rapid exits are typically more disruptive than the problem they solve. A phased approach produces better outcomes.
| Step | Action | Why it matters |
|---|---|---|
| 1. Map dependency | List managed services by switching cost — databases, identity, AI services, observability | Most sovereignty risk is hidden in services, not raw compute |
| 2. Classify workloads | Score datasets and systems by sovereignty requirement, sensitivity, and operational criticality | Turns sovereignty into a portfolio decision, not a blanket policy |
| 3. Address the control plane first | Customer-managed encryption keys, independent identity governance, local administrative access paths | Highest sovereignty leverage with lowest migration disruption |
| 4. Build exit paths before they are urgent | Use cloud migration planning to create options, not just to move workloads | Exit barriers are most expensive to discover during a regulatory event |
| 5. Embed portability in new builds | Open standards, containerization, well-defined APIs for all new workloads | Prevents future lock-in without requiring current migration |
| 6. Govern data continuously | Classification rules, retention policies, access audit trails that persist across vendors | Sovereignty requires ownership models that survive provider changes |
| 7. Validate controls operationally | Test sovereignty controls under realistic incident and audit scenarios | Declared controls and working controls are often different things |
For organizations working through this process, cloud computing services structured around workload portability and custom software development that builds sovereign-by-design applications significantly reduce the accumulation of future sovereignty debt.
Data sovereignty creates real strategic value, but it introduces trade-offs that should be acknowledged rather than minimized.
Regional and sovereign cloud providers typically offer narrower service catalogs than major hyperscalers. Advanced managed services — particularly in AI and data analytics — may not be available in every jurisdiction or at the same maturity level. Internal platform engineering demands may increase. Pricing models often differ from global platforms.
Those constraints do not undermine the case for data sovereignty. They simply require that the business case be framed correctly: not as infrastructure cost optimization, but as resilience, negotiating leverage, legal clarity, and continuity assurance. Organizations that have built AI-native engineering teams capable of working across multiple cloud environments — rather than specializing deeply in a single vendor ecosystem — carry this transition more effectively than those with single-vendor-dependent skill sets.
The most important leadership question is not whether regional sovereign clouds match every feature of global hyperscaler ecosystems. It is whether dependence on a concentrated set of external providers — subject to foreign legal jurisdiction, subject to CLOUD Act exposure, with exit costs that limit negotiating leverage — has become a strategic risk the organization can no longer price as acceptable.
Data sovereignty means that data is subject to the laws and governance structures of the jurisdiction in which it is collected, stored, and processed, and that the organization controlling it retains enforceable rights over access, use, and movement. It is distinct from data residency, which addresses only where data is physically stored.
Data residency is a location requirement — data must be stored in a specific country or region. Data sovereignty is a broader legal and operational concept: it covers which jurisdiction’s laws govern the data, who has the legal authority to compel access, and whether the controlling organization retains real operational autonomy. You can satisfy residency requirements and still lack sovereignty if the cloud provider is subject to foreign legal jurisdiction.
The US CLOUD Act allows US authorities to compel US-incorporated cloud providers to hand over data stored anywhere in the world, including in EU data centers. No provision of GDPR or EU law prevents such a demand. This means that EU enterprises storing data with US-headquartered providers — even in EU availability zones — may still face CLOUD Act exposure. The EU Cloud Sovereignty Framework (October 2025) specifically addresses this with a sovereignty score that measures exposure to foreign legislation.
The primary regulatory instruments are: GDPR (ongoing), the EU Data Act (fully applicable September 2025, mandating portability and switching), DORA (January 2025, reshaping financial services cloud procurement), NIS2 Directive (2024, strengthening cybersecurity obligations for critical infrastructure), and the EU Cloud Sovereignty Framework (October 2025, introducing formal sovereign cloud scoring). The EU AI Act (full applicability August 2026) adds AI-specific sovereignty requirements.
A sovereign cloud is a cloud environment specifically designed to keep data and operations under the legal, administrative, and technical control of a defined jurisdiction. Full sovereign clouds are operated by EU-incorporated entities under EU law, eliminating CLOUD Act exposure. Partial sovereign options — like Microsoft’s EU Data Boundary or AWS European Sovereign Cloud — reduce but do not fully eliminate US legal jurisdiction exposure.
AI workloads raise sovereign cloud requirements beyond conventional data storage. Training data containing regulated information must be processed in a jurisdiction-compliant environment. Inference pipelines that send sensitive data to third-party model APIs may violate sovereignty controls. The EU AI Act requires high-risk AI systems to demonstrate jurisdictional compliance at the pipeline level. Organizations building AI on regulated data should treat sovereignty as an architecture constraint, not only a hosting decision.
Start with workload classification — mapping which datasets and systems require the highest degree of sovereignty control, and which can remain on global platforms. Address the control plane first: customer-managed encryption keys, independent identity governance, and local administrative access paths provide significant sovereignty leverage with minimal migration disruption. Build portability into new workloads from the start to avoid compounding future lock-in. Treat data governance and sovereignty planning as connected programs rather than separate compliance exercises.
Data sovereignty has become a question of strategic control, not legal geography. The organizations navigating it most effectively in 2026 are not the ones that have repatriated the most workloads — they are the ones that understand the difference between residency and sovereignty, have classified their workloads by actual risk, and have built the governance infrastructure to act on that classification.
The CLOUD Act conflict remains unresolved. EU regulatory requirements continue to tighten. The sovereign cloud market is growing at 27% annually because the problem is real and the cost of inaction is rising. A cloud model designed around selective autonomy, portable architecture, and operational control is not a reaction to political friction. It is the architecture that keeps critical digital capabilities governable as the legal and geopolitical environment continues to shift.
For teams building or modernizing cloud infrastructure, the practical entry point is data governance and workload classification — the foundational work that makes every subsequent sovereignty decision faster and cheaper. When sovereignty becomes a design principle rather than a retroactive compliance fix, regional and sovereign clouds become instruments of resilience, not just alternative hosting options.
If your organization is working through cloud dependency, sovereignty posture, or regulatory compliance, Coderio’s engineering teams build production-grade cloud systems with the portability, governance, and architectural discipline that makes them maintainable as legal and operational requirements evolve.
Charles is a Solutions Architect at Coderio, where he specializes in designing scalable software architectures and modern data platforms. He contributes thought leadership on domain-driven design, distributed systems, and software modernization, helping organizations build resilient, enterprise-grade technology solutions.
Charles is a Solutions Architect at Coderio, where he specializes in designing scalable software architectures and modern data platforms. He contributes thought leadership on domain-driven design, distributed systems, and software modernization, helping organizations build resilient, enterprise-grade technology solutions.
Accelerate your software development with our on-demand nearshore engineering teams.
