European Sovereign Cloud in 2026: From Data Residency to Real Control

Europe's sovereign-cloud market has moved beyond political rhetoric. Sovereignty is now influencing procurement, infrastructure investment, cybersecurity policy and the architecture of cloud services across the continent.

The European Commission's Cloud Sovereignty Framework provides a structured method for assessing cloud services against eight sovereignty objectives. Its proposed Cloud and AI Development Act goes further, aiming to expand European capacity, reduce technological dependencies and create sovereign cloud and artificial-intelligence options for sensitive workloads.

The market's central problem, however, remains unresolved:

This article examines what cloud sovereignty means in practice, how the leading provider models compare and what organisations should verify before accepting any claim that a service is sovereign.

Sovereignty is more than data residency

Data residency answers a relatively narrow question: where is the information stored? Sovereignty asks a broader set of questions:

A workload can therefore remain inside an EU data centre while still being exposed to foreign corporate control, foreign legal demands or proprietary technology dependencies.

The opposite can also be true: a service operated by a European company may provide weak security, limited portability or an opaque supply chain. European ownership is important, but it does not by itself guarantee sovereignty.

The EU Cloud Sovereignty Framework

The European Commission's Cloud Sovereignty Framework transforms sovereignty from a vague aspiration into a procurement methodology. It evaluates cloud services across eight Sovereignty Objectives:

Each objective is assessed using a Sovereignty Effectiveness Assurance Level, or SEAL, ranging from SEAL-0 to SEAL-4. A procurement can establish a minimum level for each objective and then use a weighted sovereignty score to compare qualifying offers.

This contains an important nuance: a provider does not possess one universal SEAL level. Its performance can differ by objective, service, deployment model and procurement. A cloud service might demonstrate strong data and operational controls while remaining dependent on a foreign technology supply chain.

Organisations should consequently be sceptical of statements such as SEAL-3 provider unless the claim identifies the precise service and deployment being assessed, the version of the framework used, the score for each sovereignty objective, the evidence supporting each score, and whether the assessment was independent or self-declared.

EUCS and SEAL are not the same thing

The European Cybersecurity Certification Scheme for Cloud Services, known as EUCS, is intended to harmonise cybersecurity certification for cloud services across the EU. As of September 2026, EUCS remains a candidate scheme awaiting final adoption, and certificates are not currently being issued in the Netherlands.

Earlier EUCS drafts included stronger sovereignty requirements affecting providers subject to non-EU law. Those provisions were removed from the March 2024 draft after disagreement between member states and industry groups, and the revised approach concentrates more heavily on technical cybersecurity assurance and provider transparency.

The distinction matters. EUCS addresses cloud cybersecurity assurance. SEAL addresses control, autonomy and strategic dependency. A service could eventually obtain a high EUCS cybersecurity rating without achieving high sovereignty assurance across every SEAL objective.

The CLOUD Act and European data

The US CLOUD Act is frequently oversimplified in European cloud debates. It clarified that a service provider subject to United States jurisdiction may be required to produce data within its possession, custody or control, even when the information is stored outside the United States. This does not provide unrestricted access: authorities generally require valid legal process, and providers can challenge certain demands.

Nevertheless, the location of a server is not necessarily decisive when the organisation controlling the data is subject to US jurisdiction. The GDPR approaches foreign disclosure demands from a European legal perspective. Article 48 states that a judgment or administrative decision from a third country cannot, by itself, provide a lawful basis for transferring personal data. An international agreement or another valid GDPR mechanism is generally required.

This creates a potential conflict between the legal obligations imposed on an internationally controlled provider and the protections demanded by European law.

Schrems II and supplementary safeguards

In July 2020, the Court of Justice of the European Union invalidated the former EU-US Privacy Shield in the Schrems II judgment. Standard Contractual Clauses remained valid, but organisations could no longer treat them as sufficient paperwork in every situation.

Data exporters must examine whether the law and practices of the destination country undermine the agreed protections. Where necessary, they must introduce supplementary technical, contractual or organisational measures.

Encryption can be a powerful supplementary measure, but only when the potentially exposed provider or authority cannot obtain the keys or otherwise access intelligible data. Encryption controlled entirely by the same provider facing the disclosure demand offers a materially different protection level from keys controlled by the customer or an independent European entity.

A practical sovereignty hierarchy

Sovereignty should be treated as a collection of cumulative controls:

No single control provides complete sovereignty. The required combination depends on the workload, threat model and regulatory environment.

Comparing the leading provider models

The following comparison is directional and based on publicly described architectures. It is not an official SEAL assessment.

AWS European Sovereign Cloud

AWS launched its first European Sovereign Cloud region in Brandenburg, Germany, in January 2026, following a planned €7.8 billion investment. AWS describes separate governance, EU-resident leadership, EU-based operations and technical measures designed to allow the region to continue operating independently.

These controls materially improve operational and data sovereignty. They do not change the fact that AWS ultimately belongs to a US-headquartered corporate group and relies on AWS-developed technology. The fairest conclusion is not that the service lacks sovereignty, but that it offers bounded sovereignty within a non-European ownership and technology structure.

Microsoft Sovereign Cloud

Microsoft's EU Data Boundary enables customers of major Microsoft services to store and process customer data and personal data within EU and EFTA regions. Its sovereignty portfolio also includes Data Guardian, which adds European-controlled oversight to certain remote-access activities, and External Key Management, enabling customers to retain encryption keys in their own hardware security modules.

These represent meaningful improvements in data, operational and cryptographic control. Microsoft nevertheless remains a US company, and customers can become highly dependent on Microsoft's software, identity and management ecosystem.

Google Cloud and local operating partners

Google has developed several sovereignty models, including partner-operated services and Google Distributed Cloud. In France, S3NS operates as a standalone French entity backed by Thales and Google Cloud, and Google and Thales have also announced a German sovereign-cloud offering. The model combines isolated infrastructure and local operations with selected Google Cloud technologies and services.

This partner-operated structure can provide stronger separation than controls layered onto an ordinary public-cloud region. Buyers must still determine which components remain technically dependent on Google and which organisation can update, support or discontinue them.

Oracle EU Sovereign Cloud

Oracle's EU Sovereign Cloud uses regions located within the European Union that are physically, logically and cryptographically segregated from its commercial cloud regions, and uses EU-resident personnel for support and operations.

The offering is particularly relevant to organisations with substantial Oracle estates. As with the other US providers, operational separation mitigates risk but does not eliminate questions around ultimate ownership and proprietary technology dependency.

European-owned providers

Providers including OVHcloud, STACKIT and Scaleway offer a more direct European ownership and jurisdictional proposition. Their advantages can include European corporate control, European operations and infrastructure, lower exposure to US corporate jurisdiction, support for open-source technologies, and greater political and procurement alignment with European autonomy objectives.

Their principal disadvantage is breadth. No European provider currently matches the combined global reach, service catalogues, developer ecosystems and investment levels of AWS, Microsoft Azure and Google Cloud. The choice is therefore rarely a simple contest between a sovereign European provider and a non-sovereign hyperscaler. It is a decision about which dependencies are acceptable for a particular workload.

The rise of hybrid sovereignty

For many organisations, the most practical architecture will combine several control models. A highly sensitive dataset might remain inside customer-controlled or European-operated infrastructure, with encryption keys held independently. Less sensitive processing could use hyperscale cloud services. Confidential computing, tightly governed interfaces and controlled network routes can reduce the exposure created when the environments interact.

This approach recognises that workloads have different sovereignty requirements. Public information may require little more than ordinary cloud security. Personal data may require regional storage and controlled transfers. Financial or healthcare workloads may require local operations and customer-controlled keys. Defence, government or critical national infrastructure may require European ownership, isolated operations and extensive supply-chain control.

The goal is not to maximise sovereignty indiscriminately. It is to apply the appropriate level of control to the appropriate risk.

Questions every buyer should ask

Before accepting a provider's sovereignty claim, organisations should request written evidence addressing the following questions.

On ownership and jurisdiction: where is the contracting entity incorporated, which company ultimately owns or controls it, which foreign laws could apply to the provider or its parent, and can the local entity operate if instructions or services from the parent become unavailable?

On data and encryption: where are primary data, backups, metadata, logs and support records stored, who generates, stores and can recover the encryption keys, can provider administrators access plaintext data, and are data protected while stored, transmitted and actively processed?

On operations: where are administrators and support personnel located, can non-European personnel obtain privileged access, who approves emergency or remote access, and are operational activities independently logged and auditable?

On technology and supply chain: which critical components originate outside Europe, who controls software updates and security patches, could the service continue if access to the parent company's technology ended, and are open standards and interoperable formats supported?

On portability and exit: how quickly can workloads and data be migrated, are export tools, documentation and transition support contractually guaranteed, what happens to data and backups after termination, and can an alternative operator assume responsibility for the environment?

On physical infrastructure and connectivity: who owns and operates the data-centre facility, which jurisdictions do network routes traverse, how is physical access controlled, and are resilience, power supply and environmental dependencies documented?

Claims that deserve scrutiny

Buyers should be cautious when encountering phrases such as CLOUD Act-proof, complete sovereignty, GDPR compliant by design, European data means European control, SEAL-certified, a single blanket SEAL rating for an entire company, or your data never leaves Europe when telemetry, support data, backups or subprocessors are excluded.

More credible providers describe precisely which controls they deliver and which responsibilities remain with the customer. Look for language such as designed to reduce exposure to specified foreign jurisdictions, mapped against the Commission's sovereignty objectives, customer-controlled encryption and access policies, European-controlled operations for the defined service, and documented portability and exit procedures.

What happens next

The Commission's proposed Cloud and AI Development Act signals that cloud sovereignty is becoming part of European industrial strategy rather than remaining solely a privacy or cybersecurity issue.

Future competition will increasingly concern European cloud and AI computing capacity, public-sector procurement preferences, interoperability and switching, control of encryption and confidential computing, European technology supply chains, energy availability and sustainable data-centre development, and the ability to maintain critical services during geopolitical disruption.

The hyperscalers will continue to develop increasingly sophisticated sovereign variants. European providers will emphasise ownership, jurisdiction and openness. Partner-operated and hybrid architectures will attempt to combine the capabilities of the former with the control of the latter.

Conclusion

Sovereign cloud is not a product label. It is an architecture of legal, operational, technical and physical controls.

AWS, Microsoft, Google and Oracle have responded seriously to European concerns. Their sovereign offerings can substantially improve data location, operational oversight, encryption control and service resilience. But these measures operate inside non-European ownership and technology structures. European-owned providers offer a stronger jurisdictional position, although they generally cannot yet match the hyperscalers across every service category.

For buyers, the correct question is therefore not:

That distinction separates meaningful control from sovereignty washing, and gives organisations a far more reliable basis for choosing where Europe's most sensitive workloads should run.