The EU's Sovereign Cloud Has a Google Problem. Yours Might Too.

In April 2026, the European Commission awarded €180 million in contracts for sovereign cloud infrastructure. Four providers won. Three achieved SEAL-3 status under the Commission's own Cloud Sovereignty Framework: Post Telecom (with OVHcloud and CleverCloud), STACKIT, and Scaleway. The fourth, a consortium led by Belgian telecom Proximus, reached only SEAL-2. The difference comes down to one fact: Proximus's consortium uses S3NS, a joint venture between French industrial group Thales and Google Cloud.

Google is an American company. Under the US CLOUD Act, US authorities can compel American cloud companies to produce customer data held anywhere in the world, subject to legal process. Last year, a Microsoft executive acknowledged under oath before the French Senate that the company could not guarantee French customer data would never be disclosed under American legal orders. S3NS runs on Google's infrastructure. The legal exposure is structurally the same.

The Commission awarded the contract anyway. CISPE, the trade association representing 38 European cloud providers, called it "sovereignty washing at the highest levels".

This is not a cloud industry procurement dispute. For compliance officers and MLROs at management companies, TCSPs, and fund administrators, the Commission's own choices have just made the question of what "sovereign cloud" actually means impossible to avoid.

What SEAL Levels Actually Measure

The Cloud Sovereignty Framework that the Commission built for this tender introduces Sovereignty Effectiveness Assurance Levels from SEAL-0 to SEAL-4. SEAL-0 signals a complete absence of sovereignty criteria. SEAL-4 requires a full EU supply chain from chips to software. The minimum qualifying level for the tender was SEAL-2: "Data Sovereignty."

At SEAL-2, a provider demonstrates that it abides by EU laws and regulations without requiring the customer to apply additional technical measures. The data stays in the EU. The rules followed are EU rules. That is the claim.

SEAL-3 goes further. It requires operational independence from non-EU third parties in the supply chain. A SEAL-3 provider is immune from supply chain disruption by entities outside the EU. Three of the four winning providers reached this level. S3NS did not.

The distinction matters for a specific operational reason. SEAL-2 is a policy compliance claim: the provider follows EU rules as they stand today. SEAL-3 is a structural claim: the provider's infrastructure cannot be reached through the leverage points of a non-EU parent. When the question is whether a US regulatory order, executive directive, or court-issued subpoena can reach your client data, SEAL-2 provides a contractual firewall. SEAL-3 provides a structural one. These are not equivalent protections.

DORA Moved the Accountability Line

The Digital Operational Resilience Act, which entered into force on January 17, 2025, established one principle with direct force: a financial entity cannot transfer its regulatory responsibility for ICT resilience to a vendor. Cloud outages, data access events, and provider failures are operationally yours, regardless of what your contracts say.

This has a concrete consequence for cloud infrastructure decisions. When a financial entity selects a cloud provider on the basis that it is "sovereign" or "DORA compliant," the entity is making an assessment claim. Regulators expect that assessment to be documented, substantive, and revisited periodically. DORA does not permit compliance-by-label. The EBA reported that 68% of banks updated their vendor assessments in 2024-2025 specifically to address sovereignty requirements following DORA implementation.

The EU sovereign cloud tender now reveals something important: "sovereign" has a specific technical meaning under the Commission's own framework, and that meaning is graded. CISPE's criticism before the S3NS award was that the criteria were "so broad and weighted that they could allow a provider to tick enough boxes to get a high score without really delivering on the spirit of European sovereignty." That criticism now has a concrete illustration.

The CLOUD Act Remains an Unresolved Structural Exposure

The US CLOUD Act allows US law enforcement to compel American cloud providers to produce customer data stored anywhere in the world. This is not a theoretical risk. It is a legal structure that has not changed, applies to any US-owned entity in a cloud provider's supply chain, and is constrained only by mutual legal assistance treaty processes.

For a management company or TCSP processing client CDD files, beneficial ownership registrations, source of wealth documentation, and transaction monitoring records on infrastructure that includes a US entity in its ownership or supply chain structure, the compliance question is not whether you are currently in breach. The question is whether your documented risk assessment accurately characterises the data sovereignty profile of your infrastructure.

If your firm has represented to clients, regulators, or its own risk committee that data is stored on "sovereign EU cloud infrastructure," you need to know what level of sovereignty that claim can actually be substantiated against. A SEAL-2 provider stores data in the EU and follows EU rules. A SEAL-3 provider additionally cannot be structurally compelled by a non-EU government through its supply chain. These represent materially different risk profiles for client confidentiality obligations and cross-border data access scenarios.

What This Means for Management Companies, TCSPs, and Fund Administrators

DORA's third-party ICT risk management requirements apply to financial entities, which includes most firms supervised by the CSSF in Luxembourg and the FSC in Mauritius. The regime requires a documented inventory of ICT third-party dependencies classified by criticality, contractual arrangements addressing exit strategies and audit rights, and ongoing risk assessments of critical providers.

The EU sovereign cloud tender adds a concrete evaluation criterion to that work. Asking "what SEAL level does this provider achieve under the EU Cloud Sovereignty Framework" is now a defensible and specific question to include in a vendor assessment. It has a defined answer, a defined methodology, and a regulator that has publicly applied it.

Regulators do not expect SEAL-4. They expect documented, evidence-based reasoning. If you have chosen a SEAL-2 provider for reasons of cost, capability, incumbent integration, or service range, those are legitimate reasons. Document them explicitly. Identify the residual risks from the sovereignty profile and the controls you have applied to address them. "We use a sovereign cloud provider" is not evidence. "We assessed our provider against the EU Cloud Sovereignty Framework, determined it achieves SEAL-2, identified the residual CLOUD Act exposure, and implemented the following mitigating controls" is evidence.

The Principle

The Commission awarding €180 million in sovereign cloud contracts to a consortium that includes a Google joint venture is not a contradiction. It is a clarification. Sovereignty, like AML risk, is not binary. It exists on a spectrum. The Commission has defined that spectrum with an assurance level system, and it has publicly demonstrated that SEAL-2 is acceptable for certain use cases, while SEAL-3 represents a higher standard that three of the four winners met.

The compliance infrastructure lesson is the same one that runs through every well-functioning AML/KYC programme: the obligation on the financial entity is to demonstrate that its choices were made on documented evidence, against stated criteria, with known residual risks. The cloud provider's label does not discharge that obligation. Your assessment does.

The EU's sovereign cloud has a Google problem. So might yours. The question your regulator will ask is whether you knew it, and whether you documented it.

If your firm is reviewing its ICT vendor assessments under DORA and wants to build an auditable evidence trail for cloud infrastructure decisions, we can help.