Sovereign cloud procurement evaluation criteria are the structured set of legal, technical and organisational tests that a public-sector or regulated buyer applies to determine whether a cloud provider can genuinely protect sensitive data from foreign jurisdiction, compelled access and supply-chain compromise. Without a systematic framework, procurement teams risk selecting providers whose data-residency marketing masks deep jurisdictional exposure under the US CLOUD Act, FISA Section 702 or the EU’s own e-Evidence Regulation.
Why Generic Cloud Certifications Are Not Enough
ISO 27001 and SOC 2 attestations confirm security process maturity but say nothing about which government can legally compel a provider to hand over your data. Procurement teams in the public sector, finance, healthcare and legal sectors need a sovereignty-specific evaluation layer on top of standard security certifications.
The European Commission’s Cloud Sovereignty Framework addresses this gap by defining four assurance levels, known collectively as SEAL, that measure a progressively stricter set of sovereignty properties. ENISA’s European Cybersecurity Certification Scheme for Cloud Services (EUCS) operationalises comparable requirements at the technical level, assigning a ‘High’ assurance level exclusively to providers that store and process data within the EU and have no controlling legal relationship with non-EU entities.
The SEAL Framework: Four Levels, Not One Label
The Commission’s 48-criterion framework assigns providers to one of four SEAL levels based on cumulative evidence across legal, operational and technical domains.
| SEAL Level | Core Requirement | Appropriate Data Classification |
|---|---|---|
| SEAL-1 (Basic) | Standard contractual protections, GDPR DPA in place | Non-sensitive, publicly accessible data |
| SEAL-2 (Data Sovereignty) | Data stored and processed exclusively in the EU; contractual prohibition on third-country transfer | Personal data, internal operational data |
| SEAL-3 (Technological Autonomy) | SEAL-2 plus: software stack free of components subject to non-EU jurisdiction; audit rights over the supply chain | Special-category personal data, financial records, regulated professional secrets |
| SEAL-4 (Full Sovereignty) | SEAL-3 plus: legal entity fully independent of non-EU parent companies; no channel through which a foreign court can compel access | Classified government data, critical infrastructure control data, national security-adjacent information |
Procurement teams should map each data category in scope to a minimum SEAL level before issuing a tender. Mixing SEAL-2 and SEAL-4 requirements in a single contract without clear data segregation is a common structural error that undermines the entire procurement.
Operationalising the 48-Criterion Scoring Process
The Commission’s framework groups its 48 criteria into five domains: legal and jurisdictional, data location and portability, operational security, supply-chain integrity and transparency, and contractual enforceability. A procurement team can convert these into a weighted scorecard, but the weighting must reflect the data classification at stake rather than being applied uniformly.
Legal and Jurisdictional Risk Scoring
The most consequential domain is legal jurisdiction. Evaluators should establish, for each candidate provider, the full corporate ownership chain, the jurisdiction of incorporation of every entity in that chain, and whether any of those entities fall under the CLOUD Act (US), the Investigatory Powers Act (UK) or equivalent non-EU surveillance statutes. A provider incorporated in France but majority-owned by a US holding company scores identically to a US-headquartered provider for jurisdictional risk, because the US parent can be compelled to instruct its subsidiary.
NOYB chairman Max Schrems has stated plainly: “Organisations that rely solely on contractual commitments from US-headquartered hyperscalers for data protection do not understand the extraterritorial reach of US surveillance law.” This is not a theoretical concern. The CLOUD Act explicitly allows US authorities to demand data held anywhere in the world by any entity under US jurisdiction.
Evaluators should request from each provider a signed legal opinion, not merely a data processing agreement, attesting that no mechanism exists through which a non-EU authority could compel data access without routing through EU Mutual Legal Assistance Treaty channels. Providers unable or unwilling to provide this opinion should be disqualified at SEAL-3 and above.
Supply-Chain Transparency From Chips to Software
SEAL-3 and SEAL-4 require that the entire software stack be auditable and free of components controlled by non-EU entities. In practice, this means evaluators must look beyond the primary service layer to hypervisors, firmware, hardware security modules, DNS resolvers and identity providers.
ENISA’s position is clear: “Cloud sovereignty is not just about where data is stored. It is about who controls the software, the keys and the legal entity that can be compelled by a foreign court.” Contractually, providers should be required to maintain a Software Bill of Materials (SBOM) and a Hardware Bill of Materials (HBOM), both auditable by the contracting authority or an accredited third party on request. The contract should specify that any change to a material component in either BOM triggers a 30-day notification and re-evaluation window.
National Programmes: Cloud de Confiance and Souveräner Cloud
France’s Cloud de Confiance programme, administered by ANSSI under the SecNumCloud qualification framework, is the most mature national sovereignty certification in the EU. It requires that the legal entity operating the cloud be majority-owned by EU nationals, that no foreign law can compel data access, and that technical operations are staffed exclusively by EU-cleared personnel. This maps closely to SEAL-3 and, in its strictest tier, to SEAL-4.
Germany’s Souveräner Cloud ecosystem, partly expressed through the Gaia-X trust framework, takes a more federated approach. Gaia-X defines data space governance rules and self-description catalogues but does not itself certify providers at the level of granularity that ANSSI does for Cloud de Confiance. A provider claiming Gaia-X compliance should be scored against the Commission’s 48 criteria independently; Gaia-X membership is not equivalent to SEAL-3 certification.
These national programmes are not interchangeable. A French administration procuring under Cloud de Confiance can rely on ANSSI’s audit trail. A German federal authority procuring under Souveräner Cloud principles must verify which specific Gaia-X trust level the provider has achieved and whether that level satisfies the ministry’s SEAL target. Cross-border procurement between member states requires mapping both national programmes explicitly to the SEAL framework before treating them as equivalent.
The Digital Markets Act Dimension
The Digital Markets Act (DMA) introduces cloud-specific provisions targeting gatekeeper hyperscalers, including requirements for interoperability, data portability and prohibition of technical lock-in mechanisms. For procurement purposes, the DMA’s gatekeeper designation of providers such as Amazon Web Services, Microsoft Azure and Google Cloud creates a due-diligence obligation: organisations procuring these services must document how they will exercise portability rights and avoid contractual terms that restrict switching. DMA portability rights do not, however, resolve the jurisdictional exposure problem. A CLOUD Act-exposed provider remains exposed regardless of DMA compliance.
The Cost of Getting It Wrong
The IBM Cost of a Data Breach Report 2024 found that the average cost of a data breach globally reached USD 4.88 million, the highest figure in the report’s history. For regulated-sector organisations, regulatory fines, mandatory notification costs and reputational damage compound that figure significantly. ENISA’s 2023 Threat Landscape report identified ransomware and data theft as the top two threats targeting public administrations and health sectors across the EU, precisely the sectors most exposed by inadequate sovereignty controls.
Ongoing Monitoring and Contract Re-Evaluation Obligations
Sovereignty is not a one-time audit result. A provider that satisfies SEAL-3 criteria at contract signature may lose that status if it is acquired by a non-EU entity, if a key software dependency is taken over by a US foundation, or if a legislative change in a relevant jurisdiction creates a new compelled-access channel. Contracts must therefore include structured re-evaluation obligations.
Minimum contractual provisions for multi-year sovereign cloud agreements should include: an annual third-party sovereignty audit with results delivered to the contracting authority; a triggered review clause activated by any change of ownership, jurisdiction of incorporation, or material software dependency; a right to terminate without penalty if the provider’s SEAL level falls below the contracted minimum; and explicit NIS-2 Article 21 supply-chain risk assessment documentation updated at least annually. DORA-regulated entities in financial services should additionally require that these audit rights extend to critical third-party ICT providers in the provider’s own supply chain, reflecting DORA’s Article 30 concentration risk requirements.
Procurement teams should resist the temptation to treat sovereignty certification as a static deliverable. The regulatory and geopolitical landscape is shifting continuously, and the contracts that protect sensitive data most effectively are those written with re-evaluation as a standing obligation, not an optional clause.
FAQ
Is SEAL-2 sufficient for healthcare data under GDPR?
SEAL-2 guarantees data residency and basic contractual sovereignty, but healthcare data classified as special-category under GDPR Article 9 typically warrants SEAL-3 or SEAL-4. At SEAL-2, the underlying software stack may still contain components from non-EU vendors subject to foreign jurisdiction, which creates residual risk for highly sensitive clinical or patient-identifiable records.
Does Cloud III DPS automatically certify a provider as sovereign?
No. The UK Crown Commercial Service’s Cloud III Dynamic Purchasing System qualifies providers for public-sector procurement frameworks but does not apply the European Commission’s SEAL criteria or ENISA EUCS assurance levels. EU organisations must apply their own SEAL-based scoring on top of any national purchasing framework.
Can a US-owned provider with EU-only data centres achieve SEAL-4?
No. SEAL-4 requires full legal independence from non-EU jurisdictions. A provider whose ultimate parent is incorporated in the United States remains subject to the CLOUD Act and FISA 702, which allow US authorities to compel data access regardless of where servers are located. Full sovereignty demands that the legal entity holding the data cannot be compelled by any non-EU court.
How often should a sovereign cloud contract be re-evaluated for continued SEAL compliance?
Contracts should include an annual sovereignty audit right, with a triggered review whenever the provider undergoes a change of ownership, jurisdiction, or key software dependency. NIS-2 Article 21 also requires organisations in scope to assess supply-chain risk on an ongoing basis, making periodic re-evaluation a regulatory obligation, not merely good practice.
Are France’s Cloud de Confiance and Germany’s Souveräner Cloud interchangeable?
They are aligned in intent but not interchangeable in certification scope. Cloud de Confiance is grounded in ANSSI’s SecNumCloud qualification and maps closely to SEAL-3 and SEAL-4. Germany’s Souveräner Cloud initiatives operate partly under the Gaia-X trust framework, which is broader and more federated. A provider certified under one programme should be assessed independently against the Commission’s 48 criteria before being accepted as equivalent.