A sovereign cloud contract benchmark for the EU private sector is a set of documented criteria, assurance levels and scoring principles against which regulated organisations can evaluate whether a cloud provider genuinely keeps sensitive workloads outside the reach of foreign jurisdiction. Until April 2026, no single operationalised benchmark existed that was both publicly documented and tested in a live procurement. The European Commission’s Cloud III Dynamic Purchasing System changed that.
The Cloud III DPS Tender and What It Establishes
The Cloud III Dynamic Purchasing System (Cloud III DPS), awarded by the European Commission in April 2026, is the first major EU institutional procurement to apply the Cloud Sovereignty Framework (v1.2.1) as a scored evaluation criterion rather than a background policy document. Four providers received awards: OVHcloud, Scaleway, STACKIT and CleverCloud. A fifth entity, Proximus/S3NS, a Belgian-French joint venture that operates Google Cloud technology under exclusive EU-entity control, was placed in a separate lot.
The tender applied Sovereignty Effectiveness Assurance Levels (SEAL), a tiered classification defined in the Cloud Sovereignty Framework. Providers were required to meet a minimum of SEAL-2 to qualify. The scoring methodology weighted sovereignty criteria alongside technical capability and price, meaning that providers could not offset weak sovereignty posture simply by undercutting on cost. This is the first time such weighting has been publicly disclosed in a tendered EU contract, and it gives private-sector procurement teams a concrete scoring reference.
SEAL-2 versus SEAL-3: What the Distinction Means for Buyers
The SEAL framework distinguishes meaningfully between providers at different assurance levels, and the Cloud III outcome makes that distinction concrete for the first time.
SEAL-2 (Data Sovereignty) requires that all data is stored and processed within EU territory, that the operating entity is incorporated under EU law, and that contractual controls prevent data transfer to third-country jurisdictions. Critically, SEAL-2 does not prohibit the use of underlying technology developed by non-EU vendors, provided the EU operator maintains exclusive operational control. The inclusion of Proximus/S3NS, which runs on Google-origin infrastructure, demonstrates that the Commission accepted a SEAL-2 classification for a Google-technology stack when the operating entity is entirely EU-controlled and contractually isolated from Google’s US parent.
SEAL-3 adds supply-chain independence requirements: the core infrastructure components themselves must not be subject to extraterritorial non-EU law, even at the technology layer. OVHcloud, Scaleway, STACKIT and CleverCloud all qualify at or toward SEAL-3 because their infrastructure is designed and owned by EU-headquartered entities without structural dependency on US hyperscaler technology.
| SEAL Level | Data residency in EU | EU-incorporated operator | Supply-chain independence from non-EU law | Example provider (Cloud III DPS) |
|---|---|---|---|---|
| SEAL-2 | Required | Required | Not required at technology layer | Proximus/S3NS |
| SEAL-3 | Required | Required | Required, including hardware and software stack | OVHcloud, Scaleway, STACKIT, CleverCloud |
For regulated private-sector buyers, the practical implication is this: workloads subject to GDPR special-category data (Article 9), trade secrets covered by Directive (EU) 2016/943, or financial data governed by DORA concentration-risk rules (Article 28 of Regulation (EU) 2022/2554) are more defensibly protected at SEAL-3. SEAL-2 may be sufficient for less sensitive workloads where the legal risk of a US government subpoena under the CLOUD Act or FISA 702 is assessed as low, but that assessment must be documented.
Applying the Eight Cloud Sovereignty Framework Objectives in Private-Sector Procurement
The Cloud Sovereignty Framework v1.2.1 identifies eight sovereignty objectives. Not all eight carry equal weight for private-sector regulated entities, and buyers should prioritise accordingly rather than treating the framework as a uniform checklist.
The legal objective is the most immediately actionable: it asks whether the provider is subject to non-EU law that could compel disclosure of customer data. This maps directly onto the CLOUD Act, the US PATRIOT Act, and FISA Section 702 risk analysis that any GDPR data protection officer should already be conducting when selecting a processor under Article 28. The operational objective covers audit rights, incident notification timelines and exit provisions, all of which appear verbatim in DORA Article 28 and NIS-2 Article 21 obligations.
The supply-chain objective is where the SEAL-2 versus SEAL-3 distinction plays out. The security objective requires alignment with ENISA’s baseline controls and is the closest to what ISO 27001 certification already addresses, making it the easiest to evidence in a vendor audit. The EU-law compliance objective confirms that the provider does not rely on Standard Contractual Clauses as the sole transfer mechanism, which remains fragile after Schrems II (Case C-311/18).
For regulated industries, the three objectives that require the most original due-diligence work, because they are not covered by existing certification schemes, are legal, supply-chain and operational. The remaining five can largely be evidenced through ISO 27001, SOC 2 Type II and existing contractual terms.
Using the Framework as a Due-Diligence Instrument Outside Public Procurement
The Cloud Sovereignty Framework was written for EU institutional procurement, but nothing prevents private-sector compliance teams from adopting its structure for their own vendor evaluations. A practical approach is to transpose the SEAL scoring criteria into a Request for Information or a due-diligence questionnaire sent to shortlisted cloud providers, with the understanding that providers who have already responded to the Cloud III DPS tender will have documented answers available.
“Cloud sovereignty is not a single technical property but a composite of legal, operational and supply-chain assurances that must be evaluated together.” (European Commission, DG DIGIT, Cloud Sovereignty Framework v1.2.1)
The framework also provides a vocabulary that regulators are increasingly adopting. The European Banking Authority’s ICT outsourcing guidelines, the DORA regulatory technical standards published in January 2024, and draft guidance from the European Data Protection Board all reference concepts that align with the eight objectives. Using the framework in a vendor evaluation creates a documented audit trail that demonstrates proportionate due diligence, which is precisely what a DPO needs in the event of a supervisory inquiry.
The IBM Cost of a Data Breach Report 2024 found that the average total cost of a breach reached USD 4.88 million, the highest figure in the report’s history. ENISA recorded 2,562 significant cyber incidents affecting EU sectors in 2023, with public administration and healthcare among the top three targets (ENISA Threat Landscape 2023). Against that background, the cost of rigorous sovereign cloud due diligence is modest.
The EUCS Gap and How to Manage the Interim Period
The EU Cybersecurity Certification Scheme for Cloud Services (EUCS) was expected to introduce a high-assurance tier that would formally certify cloud providers for sensitive public-sector and regulated-industry workloads. As of mid-2026, EUCS has not been formally adopted under the EU Cybersecurity Act (Regulation (EU) 2019/881). The controversy over whether the high-assurance tier should require EU-operational sovereignty, a debate that the Cloud III DPS effectively resolved in practice by requiring SEAL-2 as a minimum, delayed finalisation.
“The absence of a finalised EUCS high-assurance tier should not be used as an excuse to delay procurement of verifiably sovereign infrastructure; organisations should apply available frameworks now.” (ENISA, Cloud Security Guidance)
The Cloud III contract also references COM(2026) 502, the Commission’s proposal for a Cloud and AI Data Act (CADA), which would introduce binding data-localisation obligations for critical infrastructure operators. Buyers should monitor this proposal because it may make SEAL-2 compliance mandatory rather than voluntary for specific sectors.
In the interim, buyers should layer three instruments: the Cloud Sovereignty Framework SEAL criteria for legal and supply-chain assessment; ISO 27001 and SOC 2 Type II for security baseline; and contractual representations covering data location, audit rights and exit provisions as required by DORA Article 28. The European cloud market was valued at approximately EUR 53 billion in 2022 and is projected to exceed EUR 560 billion by 2030 (European Commission, European Cloud Strategy), which means the provider ecosystem is maturing fast enough that documented SEAL-aligned alternatives exist across IaaS, PaaS and SaaS categories.
Swiss-Hosted Infrastructure and SEAL Equivalence
Switzerland is not an EU member state and therefore cannot carry an official SEAL classification. However, the revised Federal Act on Data Protection (revFADP), which entered into force on 1 September 2023, aligns Swiss data protection law structurally with the GDPR. The European Commission has recognised Switzerland as providing adequate protection under Article 45 GDPR. More directly relevant to sovereign cloud procurement: Swiss-hosted infrastructure is not subject to the US CLOUD Act, FISA 702 or the PATRIOT Act, which removes the core legal exposure that SEAL-2 is designed to address.
For regulated private-sector buyers, a Swiss provider that can document EU-territory-equivalent data protection, no structural dependency on US-law-subject entities, and contractual audit rights aligned with NIS-2 and DORA requirements can satisfy the legal, operational and supply-chain objectives of the Cloud Sovereignty Framework in substance, even without a formal SEAL label. The buyer’s due-diligence file should make this equivalence argument explicit, citing the adequacy decision, the revFADP alignment and the absence of extraterritorial foreign-law exposure. This is especially relevant for healthcare organisations subject to cantonal data protection rules and for financial entities with Swiss-domiciled clients where data localisation is commercially important.
FAQ
Is the Cloud III DPS benchmark legally binding for private-sector organisations?
No. The Cloud III Dynamic Purchasing System is a public procurement instrument used by EU institutions. Private-sector organisations are not bound by it, but its SEAL criteria and scoring methodology are publicly documented and can be adopted voluntarily as a due-diligence standard in vendor evaluations under GDPR, DORA or NIS-2.
What is the practical difference between SEAL-2 and SEAL-3 for a CISO choosing a cloud provider?
SEAL-2 requires data storage and processing within the EU and an EU-incorporated operator, but permits underlying technology from non-EU vendors such as Google. SEAL-3 adds supply-chain independence: core infrastructure must not be subject to non-EU law. For workloads carrying special-category personal data or where CLOUD Act exposure is a documented risk, SEAL-3 provides materially stronger legal protection.
Can Swiss-hosted infrastructure satisfy the SEAL criteria used in Cloud III DPS?
Switzerland cannot carry an official SEAL label because it is not an EU member state. However, the revFADP aligns with GDPR, the EU adequacy decision for Switzerland remains in force, and Swiss hosting removes US extraterritorial legal exposure. Private-sector buyers can document SEAL-equivalent legal and operational protections through contractual terms and the revFADP alignment, making Swiss infrastructure a defensible choice for many regulated workloads.
Does the EUCS high-assurance tier need to be finalised before organisations can procure sovereign cloud services?
No. EUCS is not yet adopted as of mid-2026. Organisations can use the Cloud Sovereignty Framework SEAL criteria, ISO 27001, SOC 2 Type II and contractual representations to assess providers in the interim. ENISA has indicated that the absence of a finalised EUCS tier should not delay procurement of verifiably sovereign infrastructure.
Which DORA article most directly requires assessment of cloud provider sovereignty?
Article 28 of Regulation (EU) 2022/2554 (DORA) requires financial entities to assess concentration risk and ensure that ICT third-party service contracts include provisions on data location, audit rights and exit strategies. These requirements map directly onto the legal, operational and supply-chain objectives of the Cloud Sovereignty Framework.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.