EU Sovereign Cloud Award 2026: Why Google S3NS Got SEAL-2 Not SEAL-3, and What It Means for Your GDPR Stack

Post #739 in the sota.io EU Compliance Series

In April 2026, the European Union selected four cloud providers/consortia for a €180 million sovereign cloud contract. One of those providers was S3NS — the Thales/Google Cloud joint venture built to address European sovereignty concerns, whose PREMI3NS platform holds ANSSI's SecNumCloud 3.2 qualification. But in the EU Commission's own Cloud Sovereignty Framework — a separate scoring instrument used to evaluate this specific tender, not part of SecNumCloud — S3NS's consortium received SEAL-2, not SEAL-3. The difference between those two levels is not a bureaucratic footnote. It is the answer to a question that every developer processing EU personal data should be asking: does "sovereign" actually mean sovereign if the ultimate parent company is incorporated in Delaware?

The short answer is no. And the EU's own procurement decision — rating the Post Telecom consortium, which includes Clever Cloud, OVHcloud, STACKIT and Scaleway (all EU-owned, no US parent), at SEAL-3 while S3NS's consortium capped at SEAL-2 — makes that answer official at the policy level.

This post explains what the EU Commission's SEAL-2 and SEAL-3 sovereignty levels actually mean (and why they are not the same thing as SecNumCloud), why S3NS's consortium is structurally capped below SEAL-3 under current US law, and what this landmark EU procurement decision means for developers building GDPR-compliant applications in 2026.

What Happened: The €180 Million EU Sovereign Cloud Award

In April 2026, European institutions concluded a major cloud procurement process aimed at selecting infrastructure providers that meet the EU's increasingly strict sovereignty requirements. The contract, valued at approximately €180 million, was designed to provide EU institutions with cloud services that cannot be accessed by non-EU legal orders — specifically the United States CLOUD Act.

Four providers were selected. They span different segments of the cloud market: infrastructure, platform services, and managed workloads. What the selection criteria had in common was an emphasis on legal sovereignty — the ability of the provider to resist compelled data production by foreign governments — rather than merely technical data localisation. EU data sovereignty policy has been evolving since 2018 in exactly this direction: the insight that storing data in Frankfurt does not prevent a US cloud company from being required to produce that data under US federal law.

S3NS was selected. Clever Cloud was selected. Several established European providers were also selected. But the SEAL ratings assigned to each consortium revealed a clear hierarchy: consortia with a US-parent-linked provider in the chain received lower sovereignty ratings regardless of their technical commitments to data localisation.

The EU Commission's SEAL Framework — Not SecNumCloud

Correction (2026-09-11): An earlier version of this post incorrectly attributed the SEAL-1/2/3 levels below to ANSSI's SecNumCloud certification. They are not part of SecNumCloud. SEAL and SecNumCloud are two separate instruments, run by two separate authorities, that both happen to concern French/EU cloud sovereignty.

The SEAL-2/SEAL-3 distinction comes from the European Commission's own Cloud Sovereignty Framework, whose full Implementation Guidance the Commission published on June 1, 2026 — using the same methodology it had applied a few weeks earlier to score bidders in this April 2026 tender. The Commission's own press release on the award states that the Proximus/S3NS consortium reached SEAL-2 while the Post Telecom consortium (CleverCloud, OVHcloud, plus STACKIT and Scaleway) reached SEAL-3 — and does not mention ANSSI or SecNumCloud anywhere.

SecNumCloud, separately, is ANSSI's (France's national cybersecurity agency) cloud security qualification. It is a single pass/fail qualification against one fixed standard (currently version 3.2) — not a three-tier ladder, and not the source of the "SEAL" numbering. S3NS's PREMI3NS platform does hold a genuine SecNumCloud 3.2 qualification (achieved late 2025) — that fact is correct — but SecNumCloud status and SEAL rating are different axes, and one does not determine the other.

The actual SEAL scale (Sovereignty Effective Assurance Level) has five levels, quoted directly from the Commission's Implementation Guidance:

• SEAL-0 — No Sovereignty: service, technology or operations under exclusive control of non-EU third parties.
• SEAL-1 — Jurisdictional Sovereignty: EU law formally applies with limited practical enforceability; still under exclusive control of non-EU third parties.
• SEAL-2 — Data Sovereignty: EU jurisdictions apply, but material dependencies remain; operations under indirect control of non-EU third parties. S3NS's consortium was rated here.
• SEAL-3 — Technological Sovereignty: EU jurisdictions apply, EU actors exercise meaningful but not full influence; operations under marginal control of non-EU third parties. Clever Cloud's consortium reached this level.
• SEAL-4 — Full Digital Sovereignty: technology and operations under complete EU control, no critical non-EU dependencies. The Commission's own "lessons learnt" section calls SEAL-4 "not today relevant" given remaining EU dependence on non-EU chip and hardware supply chains — no bidder in this tender cleared it.

The overall SEAL rating is a weakest-link score across eight weighted sovereignty objectives (strategic, legal/jurisdictional, data & AI, operational, supply chain, technology, security & compliance, environmental) — a consortium's rating is capped by whichever single objective scores lowest, not averaged across all eight. For the full scoring methodology (including a primary-source-verified breakdown of the 43-question assessment), see our companion post: how the SEAL framework actually computes a score.

Why S3NS Cannot Achieve SEAL-3

S3NS was established in 2021 as a French subsidiary of Google Cloud. The structure was explicitly designed to address European concerns about US cloud sovereignty: S3NS would operate independently from Google's global infrastructure, with French staff, French-operated systems, and French-controlled encryption keys. Google cannot access S3NS customer data without French management approval, according to the operational commitments S3NS has made.

This operational isolation is genuine and technically significant. But it does not sever the legal relationship between S3NS and Google LLC, a Delaware corporation. The CLOUD Act (18 U.S.C. § 2713) requires "providers of electronic communication service or remote computing service" to produce customer data when served with a US federal legal process. The relevant question is whether S3NS — as a Google subsidiary — constitutes a "provider" under the Act.

The answer, under current US law, is almost certainly yes. The CLOUD Act does not include an exemption for subsidiaries that have entered into operational isolation agreements. It does not include an exemption for providers who have contractually committed to not producing EU customer data for non-EU governments. What it does include is a mutual legal assistance treaty (MLAT) framework that allows providers to challenge data demands where they conflict with foreign law — but the burden of proof sits with the provider, the process is slow, and the outcome is not guaranteed.

The Commission's own sovereignty assessment treats this legal uncertainty as irreconcilable with SEAL-3, since the Legal & Jurisdictional Sovereignty objective is exactly the axis that gates the overall weakest-link rating. SEAL-3 requires that "EU actors exercise meaningful but not full influence" over operations — a bar a consortium cannot clear while its ultimate parent remains legally obligated to respond to US federal data demands. Even if Google LLC agreed not to exercise that legal pathway, the agreement cannot override US federal law — and SEAL-3 as defined requires that the provider structurally cannot be compelled, not merely that it has agreed not to comply.

S3NS's SEAL-2 rating reflects exactly this distinction. The framework scored what S3NS's consortium can actually guarantee: technical isolation, operational independence, and contractual sovereignty commitments (several of which contributed to the genuine SecNumCloud 3.2 qualification PREMI3NS holds). It did not — because it structurally cannot — score S3NS's consortium as immune from US federal legal process directed at Google LLC.

Clever Cloud: What SEAL-3 Eligibility Actually Looks Like

Clever Cloud was founded in 2010 in Nantes, France. It is a 100% French company with no US parent, no US investors with controlling stakes, and no exposure to the CLOUD Act. Clever Cloud operates its own infrastructure across EU data centres and provides a managed PaaS that competes directly with Heroku, Render, Railway, and — relevant to sota.io readers — with the broader "deploy your containerised application with a git push" market.

Clever Cloud's structural position means it is eligible for SEAL-3 consideration. A data demand from a US federal agency would have no legal basis against Clever Cloud. A National Security Letter cannot compel a French company with no US presence. FISA Section 702 cannot reach a provider that does not operate US infrastructure. The EU General Data Protection Regulation, not US federal law, governs Clever Cloud's data handling obligations.

The EU government's decision to award Clever Cloud a position in the €180 million sovereign cloud contract is an implicit endorsement of exactly this structural distinction. When EU institutions need to store sensitive data that cannot be subject to foreign government access, they chose providers whose legal structure prevents that access — not providers who have made operational commitments to resist it.

This is an important signal for developers. The EU government is not confused about what sovereignty means. It understands that data localisation commitments and operational isolation measures, while valuable, are insufficient if the underlying provider remains subject to non-EU legal authority. The procurement decision encodes this understanding at the policy level.

The S3NS "Sovereignty Washing" Problem

The gap between S3NS's marketing and its SEAL-2 reality illustrates a broader problem in the cloud sovereignty market: what some observers have called "sovereignty washing."

Sovereignty washing occurs when a cloud provider — typically a US hyperscaler's European subsidiary — markets its services using the language of sovereignty (EU-controlled encryption keys, EU-only data residency, EU-operated infrastructure) while remaining structurally subject to the legal framework of its US parent. The marketing is not necessarily dishonest about what the provider does. But it can create a misleading impression about what the provider can be compelled to do under US federal law.

Developers and compliance teams who rely on sovereignty-washing messaging may believe they have achieved GDPR-compliant data sovereignty when they have actually achieved only data localisation with a contractual commitment that cannot override US federal law. If a US court issues a production order against the US parent, the subsidiary's commitments to EU-only operations become a matter of negotiation and litigation rather than a structural guarantee.

The EU Commission's SEAL-2/SEAL-3 distinction exists precisely to surface this gap. SEAL-2 says, in effect: "material dependencies on a non-EU parent remain, even if this provider has implemented technical and operational controls that are significantly better than SEAL-0/1." SEAL-3 says: "EU actors exercise meaningful control, and this provider cannot be routinely compelled by a non-EU government to produce your data." These are different guarantees, and developers processing sensitive EU personal data under GDPR should understand which one they are actually purchasing.

For Article 9 special category data — health records, biometric data, political opinions, religious beliefs — the distinction is particularly critical. The GDPR permits processing of Article 9 data only under specific conditions, and the transfer of that data to a non-EU legal jurisdiction through a legal production order — even if unintended and resisted by the provider — constitutes a transfer that requires its own legal basis under Articles 44-49.

Six GDPR Implications of the SEAL-2 Gap

1. Your DPA transfer documentation may describe a fiction

Many data processing agreements with EU-based cloud subsidiaries describe the data processing relationship as occurring exclusively within the EU. If the parent company can be legally compelled to produce data under the CLOUD Act, the actual transfer risk is not captured by documentation that describes only the operational relationship. Your Data Protection Impact Assessment should include a legal sovereignty analysis, not just a technical data residency analysis.

2. Article 32 security assessment must include legal compulsion risk

GDPR Article 32 requires that data controllers implement technical and organisational measures appropriate to the risk. The risk of a US federal production order reaching a SEAL-2 provider's data should be included in your Article 32 risk assessment. For most SaaS applications, this risk may be low enough to accept. For applications handling health data, legal communications, financial records, or personal data of EU public officials, the risk profile looks different.

3. DPIA outcomes may change when CLOUD Act exposure is included

Data Protection Impact Assessments under GDPR Article 35 are required for processing that is likely to result in a high risk to the rights and freedoms of natural persons. If your current DPIAs analysed your cloud provider's GDPR exposure based on technical data residency without considering the CLOUD Act legal layer, they may need to be updated in light of the Commission's own sovereignty assessment that led to S3NS's consortium receiving SEAL-2 rather than SEAL-3.

4. The "adequacy decision" does not resolve CLOUD Act exposure

The EU-US Data Privacy Framework (DPF), adopted in 2023 as a replacement for Privacy Shield, provides an adequacy finding that allows transfers from the EU to DPF-certified US companies. But the DPF's adequacy decision covers voluntary data transfers under GDPR Chapter V. It does not address the scenario where a US company is legally compelled to produce data under CLOUD Act authority that was never intended to leave the EU. The CLOUD Act and the DPF operate on different legal tracks.

5. Public sector and regulated industry contracts may require SEAL-3 equivalence

The EU procurement decision signals that SEAL-3 equivalent sovereignty will increasingly be a requirement for public sector contracts and regulated industry work (financial services, healthcare, critical infrastructure). If your SaaS product targets these segments, understanding your cloud provider's sovereign certification level — and communicating it accurately to prospective customers — is becoming a commercial differentiation factor, not just a compliance exercise.

6. Clever Cloud's PaaS position is directly relevant to deployment decisions

Clever Cloud is not just a data storage provider. It is a PaaS in the same category as Render, Railway, and sota.io. Developers who need SEAL-3 equivalent sovereignty for their application deployment layer — not just for object storage or databases — now have EU-government-endorsed evidence that Clever Cloud achieves that standard. This matters for compliance teams that need to explain to their DPO why they chose their PaaS provider.

What This Means for PaaS Choices in 2026

The EU sovereign cloud award is directly relevant to the PaaS selection decisions that development teams make every day. It is easy to think about cloud sovereignty in terms of data storage — where is my database? what region is my S3 bucket? But PaaS providers are also part of your data processing chain. Your application code runs on PaaS infrastructure. Your application processes personal data. Your application runtime environment is a data processor under GDPR Article 4(8).

If your PaaS is operated by a US company — even a US company that has committed to EU-only operations — the CLOUD Act analysis applies to your PaaS layer just as much as it applies to your cloud storage layer. A production order directed at the US PaaS parent could compel the production of logs, configuration data, environment variables containing encryption keys, and runtime data from your application's execution environment.

The EU's procurement decision identifies four providers that have passed sovereign cloud scrutiny at different levels. The presence of Clever Cloud on that list, at the PaaS layer, is the most direct policy signal yet that EU institutions believe PaaS infrastructure can and should be selected based on sovereign certification criteria.

For development teams that need to make defensible GDPR compliance arguments — to their DPO, to their customers, to regulators — the EU government's certification framework provides exactly the kind of external validation that makes those arguments credible. Saying "we use a SEAL-2 provider because we prioritised ecosystem maturity" is a defensible position for many workloads. Saying "we use a SEAL-3 eligible provider because our DPA concluded we needed structural sovereignty guarantees for this data category" is the argument that passes regulatory scrutiny for the most sensitive use cases.

Where sota.io Fits

sota.io is a European PaaS operated from EU infrastructure with no US parent company. Our legal structure does not create the CLOUD Act exposure that kept S3NS at SEAL-2. We are not SecNumCloud certified — certification is a formal process that takes years and resources — but the structural conditions that make SEAL-3 eligibility possible are present.

For developers who need to deploy containerised applications in the EU without the legal sovereignty uncertainty that comes with US-parent PaaS providers, sota.io offers:

• Git-push deployments to EU-owned infrastructure without US parent exposure
• EU-native data processing under GDPR jurisdiction without CLOUD Act overlay
• No per-seat pricing — a flat resource model rather than the enterprise pricing that characterises established EU PaaS providers
• Developer workflow parity with Render, Railway, and Vercel for teams that need both sovereignty and DX

The eu-sovereign-cloud-award-2026 decision validates the direction of the EU compliance market. Developers who chose EU-native providers for structural reasons rather than just operational ones are now seeing those choices endorsed at the policy level.

EU-Native PaaS Alternatives for Structurally Sovereign Deployments

Beyond sota.io and Clever Cloud, several EU-native PaaS providers offer deployments without US parent CLOUD Act exposure:

Clever Cloud — French PaaS, part of the EU Commission's SEAL-3-rated consortium in the April 2026 tender, EU government endorsed, strong multi-language support, higher price point than newer entrants.

Exoscale — Swiss and Austrian infrastructure, owned by A1 Telekom (Austrian), no US parent CLOUD Act exposure. Kubernetes, S3-compatible storage, strong Swiss compliance credentials.

Scaleway — French provider owned by Iliad Group, strong AI infrastructure, no US parent. Developer-friendly pricing, growing ecosystem.

Hetzner Cloud — German provider, privately held, no US parent. Excellent value, particularly strong for compute-intensive workloads. Limited managed services compared to hyperscalers.

OVHcloud — French provider, publicly listed in Paris, no US parent. Largest European cloud by revenue. Complex product surface, strong on infrastructure-as-a-service.

Each of these providers offers the structural CLOUD Act immunity that S3NS's SEAL-2 rating explicitly does not guarantee. The EU sovereign cloud award has made the distinction between these two categories of provider more visible than it has ever been.

Summary

The EU's €180 million sovereign cloud award is the most concrete policy signal yet that the EU government distinguishes between technical data sovereignty (data residency plus operational isolation) and legal data sovereignty (structural immunity from foreign government compelled production). S3NS received SEAL-2 because its US parent cannot be made legally immune from the CLOUD Act. Clever Cloud received full sovereign endorsement because its French incorporation creates no CLOUD Act exposure.

For developers, this decision provides:

1. External validation that CLOUD Act exposure is a real, government-recognised compliance risk — not a theoretical concern
2. A clear framework for distinguishing between SEAL-2 style "committed sovereignty" and SEAL-3 style "structural sovereignty"
3. Policy-level evidence that PaaS layer sovereignty decisions matter, not just storage layer decisions
4. A shortlist of EU-native providers — Clever Cloud, sota.io, Exoscale, Scaleway, Hetzner, OVHcloud — whose legal structure does not create the sovereignty gap that kept S3NS at SEAL-2

If the EU government will not entrust its most sensitive workloads to a provider whose parent is subject to the CLOUD Act, your compliance team has a strong argument for applying the same standard to the data you are entrusted with.