The SEAL framework, decoded: what the eight objectives actually measure, and why almost nobody scores clean.

The EU Cloud Sovereignty Framework scores cloud providers against eight objectives, each rated SEAL-0 to SEAL-4. A tender sets a minimum SEAL per objective, and missing even one floor rejects the bid outright. Providers that clear every floor are then ranked by a weighted composite score, in which the weakest objective, not the average, decided whether they were in the running at all.

That distinction, between a floor and an average, is the single most important thing to understand about SEAL, and it is the thing most coverage of the framework gets wrong. This article explains what the eight objectives measure, walks through a real tender where the mechanism produced a contested result, and gives you a reading list for how providers are presenting their own scores today.

What is the SEAL framework measuring, and why does it exist?

The European Commission's Directorate-General for Digital Services (DG DIGIT) published the Cloud Sovereignty Framework on 20 October 2025. It gives European public buyers a common scoring methodology for cloud sovereignty claims, built with reference to Gaia-X, CIGREF's Trusted Cloud referential, NIS2, and DORA, and designed to sit alongside national schemes such as SecNumCloud and C5 rather than replace them.

For its first year the framework existed mainly as a reference document. That changed on 17 April 2026, when the Commission used it as a binding award criterion in the Cloud III procurement, a Dynamic Purchasing System contract worth up to 180 million euros over six years. Four European consortia were awarded, and the results, discussed below, gave the market its first real test of how the scoring actually behaves under pressure.

That test matters because SEAL is no longer a thinkpiece. It is a procurement instrument with money attached, and this article treats it as one.

What are the eight objectives, and how are they weighted?

SEAL scores providers across eight Sovereignty Objectives, known as SOV-1 through SOV-8. Each is weighted, and the weights sum to 100 percent.

SOV-1, Strategic Sovereignty (15%). Whether decisive authority over the provider sits within EU jurisdiction, whether financing, jobs, and value creation stay in the EU, and whether operations can continue if a foreign vendor or government tries to withdraw support.

SOV-2, Legal and Jurisdictional Sovereignty (10%). Which legal system governs the provider and how exposed it is to non-EU laws with extraterritorial reach. The framework names the US CLOUD Act and Chinese cybersecurity law specifically, and asks whether any channel exists for a non-EU authority to compel access to data.

SOV-3, Data and AI Sovereignty (10%). Whether the customer holds effective cryptographic control, whether access is auditable, whether storage and processing stay within EU jurisdictions, and whether AI models are developed and governed under EU control.

SOV-4, Operational Sovereignty (15%). Who runs the infrastructure day to day: staffing, administrative access, and incident response.

SOV-5, Supply Chain Sovereignty (20%, the single heaviest weight). Dependence on non-EU hardware and software throughout the stack.

SOV-6, Technology Sovereignty (15%). Independence of the underlying technology stack itself.

SOV-7, Security and Compliance (10%). Ties into GDPR, NIS2, and DORA obligations.

SOV-8, Environmental Sustainability (5%).

Supply chain carries more weight than any other objective, and that is a deliberate design choice, not an accident. It reflects where structural dependence on US hardware and hyperscaler software is hardest to remove, and it is the objective most providers with otherwise strong European credentials still struggle to score well on.

If you read the cover feature's three-layer model, the mapping is direct: the jurisdictional layer corresponds most closely to SOV-2, the operational layer to SOV-4, and the technical layer spans SOV-3 and SOV-6.

Floor or average? The mechanism almost everyone misreads.

Here is the design that the coverage of SEAL most often collapses into a single misleading number.

SEAL levels are floors, not grades. A tender sets a required minimum SEAL for each of the eight objectives individually. A provider that falls below the floor on even one objective is rejected outright, no matter how strong its scores are everywhere else. The weakest objective decides whether the bid survives, not the average.

The Sovereignty Score is a composite, calculated only among survivors. Once a bid clears every floor, its scores across all eight objectives are combined into a single weighted percentage, using the weights above, and that composite score is used to rank the bids that already passed. It is a differentiator among qualified offers, not a qualification test in itself.

The practical consequence is this: a headline sovereignty percentage, on its own, tells you almost nothing. A provider could publish an impressive 78 percent composite while having failed a tender's floor on the one objective that mattered most to that specific buyer. The only way to read a SEAL score honestly is to ask for the per-objective breakdown and identify the weakest link, because that is what actually determined whether the bid was in contention at all.

Case study: what happened when a real bid tested this design.

The April 2026 Cloud III award is the clearest illustration available, because the mechanism produced a genuinely contested outcome in public.

Three of the four winning consortia, Post Telecom with OVHcloud and CleverCloud, STACKIT, and Scaleway, reached SEAL-3, Digital Resilience. The fourth, led by Proximus and including S3NS alongside Clarence and Mistral, reached only SEAL-2, Data Sovereignty, one tier below the other three.

S3NS is a joint venture in which Thales holds the majority stake and Google Cloud participates as a minority technology partner. Its lower SEAL result traces specifically to SOV-2: the US CLOUD Act obliges American companies to produce data on request regardless of where that data is physically stored, and that exposure is difficult for any provider with a US-linked technology partner to fully insulate against, whatever its ownership structure.

The result was immediately contested. CISPE, the trade association representing 38 European cloud infrastructure providers, called the inclusion of S3NS in a sovereign award an own goal that threatens to institutionalize sovereignty washing at the highest levels. S3NS published a public rebuttal, describing itself as a French entity fully controlled by Thales, with customer contracts held by S3NS, operations run exclusively by S3NS personnel, and Google Cloud confined to a supervised technical role without system access. The Commission's own position, stated in its award announcement, drew a deliberate line: non-European technology, operated within a sufficiently strict governance framework, can meet the minimum level of sovereignty required. In other words, the Commission explicitly treats sovereign operation as capable of compensating for non-sovereign technology, at least at the SEAL-2 level.

This is the ownership-versus-operation debate from the cover feature, playing out with public money and a published, contested score attached. Whatever view you take of the outcome, one detail is worth isolating for what it teaches about reading SEAL scores generally: S3NS holds SecNumCloud certification, France's own high-assurance national sovereignty qualification, and it still scored SEAL-2 rather than SEAL-3 in this tender. A national certification and a procurement-graded SEAL level are not the same instrument, and holding one does not guarantee a particular result on the other.

What do providers get wrong when they publish their own score?

Beyond the S3NS case, three patterns show up repeatedly when providers publish their own sovereignty claims.

The first is publishing a single composite percentage with no per-objective breakdown. Given what the floor mechanism actually does, a composite number without the underlying eight scores tells a buyer almost nothing about where the real exposure sits.

The second is conflating a national certification with a SEAL rating. The S3NS case shows this can trip up even a well-resourced, closely scrutinised bid: certification and procurement-graded assessment answer related but distinct questions, and one does not stand in for the other.

The third is presenting a self-assessment as though it carries the same weight as a tender-graded result. Self-assessment is a legitimate and useful exercise, and the next section links to several published examples, but it should be labelled clearly as a self-assessment against the framework's criteria, not implied to be equivalent to a Commission-graded SEAL level awarded in the context of an actual procurement.

How providers are scoring themselves: a reading list.

Several providers and independent groups have published tools and assessments against the framework's criteria, ahead of or alongside any formal procurement context. Presented here as examples of the practice, not as endorsements or a ranking:

nLighten has published its own explainer of the framework's levels and objectives, alongside a public self-assessment tool that scores an organisation's data sovereignty maturity against the framework's criteria.

SUSE offers a public, no-signup self-assessment tool that scores a provider or organisation against the framework's eight objectives and flags critical violations where a fundamental sovereignty question scores SEAL-2 or below.

An independent, open-source calculator, published on GitHub and aligned with the Commission's own Implementation Guidance and scoring annex, lets anyone score a set of 48 official criteria across the eight objectives and returns both a weighted score and the weakest-link SEAL level.

Reading several of these side by side is a useful exercise in itself: it shows how differently the same eight objectives can be presented depending on who is doing the presenting.

What should you actually ask for when a provider cites a SEAL score?

A SEAL score is only as useful as the detail behind it. When a provider cites one, ask for:

1. The per-objective breakdown, not just the composite percentage.

2. Which objective scored weakest, since that is what would have determined pass or fail in an actual tender.

3. Whether the score was self-assessed or produced in the context of a real procurement with defined floors.

4. Whether a national certification, such as SecNumCloud or C5, is being presented alongside or instead of a SEAL level, and if so, how the two relate.

5. The date the assessment was made, since both the framework's guidance and a provider's own architecture can change.

6. Whether the cited score reflects the whole company or a specific, ring-fenced service or joint venture, as the S3NS case shows these can differ substantially within a single group.

A composite number handed over without answers to these questions is a marketing figure. The same number, with the breakdown behind it, is a procurement-grade fact.