Sovereign Cloud: What It Means and How to Evaluate One

For years there was no official definition of sovereign cloud, so providers on both sides of the Atlantic described their services as sovereign [S55]. The core concern behind the term is legal. US law requires providers to disclose data in their possession, custody or control regardless of whether it is stored inside or outside the United States [W5]. A legal analysis by the Cloud Legal Project at Queen Mary University of London therefore separates data residency, meaning where data is stored, from data sovereignty, meaning who can compel access to it [S55].

The same analysis adds an important nuance: a European company is not automatically immune either. Depending on its US customers, assets and staff, it may also fall under US jurisdiction, which requires a case-by-case review [S55]. Sovereignty is a property you assess, not one you buy by choosing a flag.

The German government's definition

In its answer to a parliamentary question in March 2025, the German federal government defined sovereign clouds as all clouds that allow the federal government to act independently, self-determined and securely. It tied the term to three strategic goals of the IT Planning Council: the ability to switch providers, the ability to shape and operate IT solutions independently, and influence over IT providers [W3][W4].

The same answer showed how this works in practice. In a cross-ministry survey of 15 possible procurement criteria, a clear majority wanted data processing exclusively within the European Economic Area, control over cryptographic keys and structural independence from third countries treated as mandatory. Full open-source use or operation in public data centres were far less often seen as mandatory [W4]. One public cloud tender in February 2024 made only two criteria binding: data location in the EEA and structural independence [W4].

The EU Cloud Sovereignty Framework

The European Commission used a Cloud Sovereignty Framework in a EUR 180 million tender for sovereign cloud for EU institutions, awarded to four providers in April 2026 [W1]. The framework combines two instruments:

• a Sovereignty Effectiveness Assurance Level (SEAL), which tests whether a provider meets defined thresholds, with the highest levels covering data sovereignty (SEAL-2), technological autonomy (SEAL-3) and full sovereignty (SEAL-4);
• an overall sovereignty score based on 48 criteria in eight categories: strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability [W1].

The Commission explicitly encourages public and private organisations to use the framework for their own assessments [W1].

The BSI's C3A criteria

In April 2026 Germany's Federal Office for Information Security (BSI) published the Criteria enabling Cloud Computing Autonomy (C3A). They are aligned with the EU framework in structure and goals, and they turn its contributing factors into auditable criteria. Providers can demonstrate compliance through an audit. Customers can select the criteria and additional criteria that matter for their use case, for example options on localisation such as data centre location or the origin of operating staff, and so define their own target level of sovereignty [W2].

The common thread across all three is that sovereignty has become a set of selectable, verifiable requirements rather than a yes-or-no label.

Buyers today mostly choose between three models. They differ in where control actually sits.

European-owned providers. The provider is headquartered and controlled in Europe. This reduces exposure to foreign law, but the case-by-case caveat above still applies, especially where a provider has US locations or customers [S55].

Separate sovereign infrastructures from global providers. AWS, for example, describes its European Sovereign Cloud as physically and logically separate infrastructure with all components in the EU, a first region in Brandenburg, Germany, operation by EU residents located in the EU, and management through dedicated European legal entities established under German law [W7]. These are the provider's own statements and should be tested against the criteria above, in particular the legal and jurisdictional ones.

Data-boundary commitments within global services. Microsoft describes its EU Data Boundary as a geographic boundary within which it commits to store and process customer data and personal data for services including Azure and Microsoft 365. Microsoft also states that these commitments are subject to limited circumstances in which data will continue to be transferred outside the boundary, and documents those transfers [W8]. A boundary commitment addresses residency. It does not by itself settle questions of jurisdiction.

None of these models is sovereign by default. Each meets some criteria and not others, which is exactly why the criteria-based approach is useful.

Two obligations in the EU Data Act give buyers leverage regardless of the model they choose. Since 12 September 2025, providers of data processing services must publish on their websites the jurisdiction to which the ICT infrastructure of each service is subject, and describe their technical, organisational and contractual measures against international governmental access to non-personal data held in the EU (Article 28) [W6]. Providers must also take adequate technical, organisational and legal measures to prevent such access where it would conflict with EU or national law (Article 32) [W6].

These disclosures are public. Reading them for every shortlisted service is one of the cheapest steps in a sovereignty assessment.

"If the data is in the EU, it is sovereign." Location is one criterion among many. US disclosure obligations attach to possession, custody or control, not to where the bytes sit [W5][S55].

"A European provider is always sovereign." Ownership helps, but a European company with significant US activity can still be exposed, and the answer depends on the facts [S55].

"Sovereignty is all or nothing." The EU framework grades providers by assurance level and score, and the C3A let customers pick the criteria relevant to each use case [W1][W2]. A payroll system and a public marketing website do not need the same level.

"Sovereignty means moving everything to one provider." Many organisations deliberately combine hyperscale services for less sensitive workloads with European or private environments for sensitive data. That adds complexity, which has to be managed rather than ignored [S55].

Use the categories of the EU framework as a structure and the C3A approach of selecting what matters for each workload:

1. Classify workloads. Not every system needs the highest level. Decide which workloads need data sovereignty, which need technological autonomy and which can run anywhere. 2. Legal and jurisdictional. Read the Article 28 disclosure, identify the controlling entity and any US nexus. 3. Data and keys. Confirm where data, backups and logs reside, and who holds the encryption keys. Key control was one of the criteria German ministries most often wanted as mandatory [W4]. 4. Operations. Establish who operates and supports the service, and from where. C3A treats the origin of operating staff as a selectable criterion [W2]. 5. Supply chain and technology. Check subcontractors and how far the service depends on proprietary components. 6. Exit. Test whether you could switch provider, the first of the German government's strategic goals [W3]. 7. Evidence. Ask for audit reports against the criteria you selected and record the decision for each workload.

For a deeper treatment of the individual dimensions, read Cloud Sovereignty: Beyond Data Residency. For how organisations shift workloads under geopolitical pressure, see Sovereign and Regional Cloud Strategies.

The EU framework and the C3A are recent, and practice in applying them is still forming. The German government's figures on procurement criteria come from a single survey and a single tender [W4]. The descriptions of sovereign offerings from global providers are the providers' own statements. The QMUL analysis was commissioned by Broadcom and is attributed as professional interpretation [S55].

This article provides technical and operational analysis, not legal advice. Applicability depends on the organisation, service, contract, jurisdiction and facts.

Sovereign cloud is no longer only a marketing term. Public frameworks now let you state which kind of sovereignty a workload needs and verify whether a service delivers it. The result is rarely one provider for everything, and more often a placement decision per workload.

That is where Atomity helps. We analyse workloads against compliance requirements, apply CLOUD Act-aware routing, and compare where each workload runs best on cost and sovereignty criteria across AWS, Azure, Google Cloud and European clouds such as IONOS, STACKIT, OVHcloud, Hetzner and Open Telekom Cloud. To see where your current workloads stand, start with a free cloud cost check.