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 for a €180 million sovereign cloud contract. One of those providers was S3NS — Google Cloud's French subsidiary, established specifically to address European sovereignty concerns. S3NS received France's SecNumCloud certification. But it 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 parent company is incorporated in Delaware?

The short answer is no. And the EU government's own procurement decision — choosing Clever Cloud, a 100% French PaaS provider with no US parent, as its primary sovereign-compliant infrastructure winner — makes that answer official.

This post explains what SecNumCloud SEAL-2 and SEAL-3 mean, why S3NS is structurally unable to reach 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 certification levels assigned to each provider revealed a clear hierarchy: providers subject to the CLOUD Act through their US parent companies received lower certification levels regardless of their technical commitments to data localisation.

SecNumCloud: France's Cloud Sovereignty Certification Framework

SecNumCloud is France's cloud security certification framework, administered by ANSSI — the Agence Nationale de la Sécurité des Systèmes d'Information, France's national cybersecurity agency. ANSSI created SecNumCloud to give French and EU public sector organisations a clear standard for evaluating whether a cloud provider can actually protect sensitive data from foreign government access.

SecNumCloud defines three certification levels:

SEAL-1 covers basic security controls: encryption, access management, incident response, physical security. It is essentially a hygiene baseline. A provider can be a US company subject to the CLOUD Act and still achieve SEAL-1. Most enterprise cloud providers can obtain or are on a path to SEAL-1.

SEAL-2 adds significant operational controls including isolation of EU operations, restricted access from non-EU personnel, and enhanced supply chain controls. Critically, SEAL-2 does not require that the provider be legally immune from foreign government data demands. A SEAL-2 provider can commit to EU operational isolation while still being a US company subject to US federal law. S3NS received SEAL-2 certification.

SEAL-3 is where legal sovereignty becomes a hard requirement. To achieve SEAL-3, the cloud provider must be able to demonstrate that it cannot be legally compelled by a non-EU government to produce data or grant access. This is not a technical requirement. It is a legal one. A provider incorporated in the United States, or whose ultimate parent is incorporated in the United States, cannot achieve SEAL-3 under current US law because the CLOUD Act applies to all US providers regardless of where data is physically stored or which subsidiary operates the service.

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.

ANSSI concluded that this legal uncertainty is irreconcilable with SEAL-3. The certification body cannot certify, at the highest sovereignty level, a provider whose parent company is 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. SEAL-3 requires that the provider structurally cannot be compelled — not that it has agreed not to comply.

S3NS's SEAL-2 certification reflects exactly this distinction. ANSSI certified what S3NS can actually guarantee: technical isolation, operational independence, and contractual sovereignty commitments. It did not certify what S3NS cannot guarantee: immunity 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.

SecNumCloud's SEAL-2/SEAL-3 distinction exists precisely to surface this gap. SEAL-2 says: "this provider has implemented technical and operational controls that are significantly better than the baseline." SEAL-3 says: "this provider cannot be legally 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 ANSSI analysis that led to S3NS 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, SecNumCloud SEAL-3 eligible, 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 certification 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.