The EU’s SEAL Framework: Cloud Sovereignty Is Now a Score, Not a Slogan

“Sovereign cloud” was a marketing term until April 2026. It’s now a scored, procurement-tested framework with €180 million already awarded against it — and the scoring reveals something most vendor pitches get quietly wrong: sovereignty is about legal jurisdiction, not server location.

I’ve written separately about the distinction between data residency and data sovereignty. The European Commission’s Cloud Sovereignty Framework, published in October 2025 and first applied in a real €180 million tender in April 2026, is the instrument that turns that distinction from a conceptual argument into a number — and it’s worth understanding even for organisations that will never bid on an EU institutional contract, because it’s fast becoming the reference vocabulary regulated industries use to interrogate vendors.

How the framework actually scores a provider

The framework defines eight Sovereignty Objectives — strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability — assessed against 48 specific criteria. Each objective earns a Sovereignty Effectiveness Assurance Level, or SEAL, on a scale from SEAL-0 (no sovereignty — the service sits entirely under non-EU control and law) to SEAL-4 (full digital sovereignty — a complete EU-controlled stack from chip to application, with zero critical non-EU dependencies). SEAL-2 marks data sovereignty: EU law applies and is enforceable, even if some non-EU dependencies remain. SEAL-3 marks digital resilience: the service is substantively immune to supply-chain disruption from non-EU third parties.

The genuinely important nuance, easy to miss in summary coverage: a provider does not have a single SEAL rating. It has one rating per objective, and those ratings are context-specific to a given procurement’s requirements. Press releases collapse this into a headline number — “most awarded providers reached SEAL-3” — but a serious procurement assessment has to look at the objective-by-objective breakdown, not the summary.

Why the S3NS result is the actual lesson

The April 2026 tender’s most instructive outcome wasn’t the winners who reached SEAL-3 outright. It was S3NS — a joint venture between Thales and Google Cloud, holding France’s own SecNumCloud certification — landing at only SEAL-2, despite a technical environment that reads, on paper, as thoroughly European. The gap is jurisdictional, not technical: S3NS’s underlying technology runs on Google Cloud infrastructure, and the framework’s scoring asks not where a server sits but which legal jurisdiction can compel access to what runs on it. A provider can be EU-operated, EU-certified, and EU-hosted, and still fail to reach the framework’s higher tiers if a foreign parent’s legal obligations create a theoretical access path the framework is specifically designed to detect.

This is the exact distinction I’ve argued elsewhere: residency answers where; sovereignty answers who can compel access regardless of where. The SEAL framework is simply the first instrument precise enough to score that distinction rather than argue about it.

What this looks like as a migration decision

A European insurance-adjacent fintech, several years into operation on a major hyperscaler with data genuinely resident in an EU region, had its compliance function review the arrangement against the SEAL objectives following an institutional investor’s due-diligence question. The honest score landed at SEAL-2 — EU law applicable and enforceable, but with a non-EU parent’s legal exposure still present underneath. The investor’s own risk appetite required SEAL-3. The resulting migration — to an EU-domiciled provider with a clean legal chain, French SecNumCloud certification, and EU-run operations — took roughly nine months and a few hundred thousand euros in engineering time, against annual transaction volume in the hundreds of millions. Measured against that volume, the cost was a rounding error. Measured against what happens to a growth-stage fintech that loses an institutional investor over an unresolved sovereignty gap, it was the cheapest insurance the company bought that year.

Why this matters before it’s mandatory

The framework was built for one specific EU institutional procurement and carries no direct legal force outside it — yet. A subsequent legislative proposal, the Cloud and AI Development Act, would extend a sovereignty risk-assessment requirement to public authorities, healthcare providers, and critical infrastructure operators across all member states handling significant data volumes or contract values, well beyond the framework’s original scope. Regulated organisations don’t need to wait for that to become binding to find the framework useful now: it’s the first vocabulary precise enough to ask a cloud vendor a real question instead of accepting a marketing claim. The practical use, for most private-sector organisations, isn’t running the full 48-criterion assessment on every system — it’s identifying which specific workloads would actually require SEAL-2 or SEAL-3 if the organisation were a public body, and treating only those as worth the evaluation effort.

Scoping which parts of a cloud estate genuinely warrant a sovereignty assessment against the SEAL framework — rather than running the full assessment everywhere, or ignoring it entirely — is exactly the kind of triage a technology control assessment is built to perform.