How do you measure whether something is sovereign?
Ask it about a real system and the question splits. Can you keep running if conditions turn, or does someone else decide when you stop? Who holds the levers – the access, the keys, the legal authority? And how deep does it go: your provider may be sovereign, but what about their suppliers three layers down?
These have different answers, and they don’t move together. A service can be operationally solid and legally exposed. Jurisdictionally clean at the top and dependent on a single foreign supplier underneath. “Is it sovereign?” has no single answer, because sovereignty was never a single property – which is exactly why you can’t put one number on it.
The European Union has built a way to measure it anyway. It’s worth understanding correctly, because the way it’s built makes it easy to misread.
The EU’s answer
The Cloud Sovereignty Framework (CSF), published by the European Commission in late 2025, does the obvious right thing: it refuses to treat sovereignty as one number. It assesses a cloud service against eight separate objectives (called SOV) – strategic, legal, data and AI, operational, supply chain, technology, security, and environmental. Each objective gets its own assurance level on a scale called SEAL, from SEAL-0 (none) to SEAL-4 (full). Separately, the objectives are weighted into a single Sovereignty Score, used to rank offers in a tender.
Two things, then, not one: a SEAL level for each objective, and one weighted score on top. The eight objectives are roughly the questions you’d reach anyway by interrogating a system honestly. The framework’s contribution is to make them explicit, consistent, and comparable.
How to use it
Used as intended, the CSF assesses a concrete cloud service and hands you a profile: a SEAL level on each objective, for that service, in context. That profile is the value. It tells you not whether a service is “sovereign” in the abstract, but where it’s strong and where it’s weak.
The framework also rolls the objectives into a single weighted Sovereignty Score, with some objectives counting for more than others – supply chain weighted heaviest, environmental lightest. That score is useful for ranking offers, but the weighting is the framework’s, fixed for everyone. Your priorities aren’t.
And it’s easy to misinterpret, because the framework is built in a way that invites a shortcut.
Easy to misread
The trouble starts with the SEAL levels’ names. SEAL-1 is “Jurisdictional,” SEAL-2 “Data,” SEAL-3 “Resilience,” SEAL-4 “Full Sovereignty.” Suggestive names for what are only per-objective levels – and they read as a grade for the whole service. Almost every misreading follows from that one slip.
So “Are you SEAL-2?” sounds precise but says nothing without an objective attached. Worse, read as an overall grade, the level hides holes: a service can post a respectable weighted score – supply chain counts for four times as much as environmental – while sitting at SEAL-0 on the one objective a particular workload can’t afford to be weak on. The score stays high; the gap stays hidden.
Inside a tender the framework guards against this, since each objective carries a minimum threshold and falling below it means rejection regardless of the total. But that safeguard lives in the procurement. “We’re SEAL-2,” said in a meeting, leaves it behind – and even the Commission speaks this way, reporting that providers “reached SEAL-3” as if a single level described a whole company.
Two more misreadings appear once a supply chain is involved. A SEAL level belongs to a service or solution, not a company. And nothing passes it up a stack: a solution built on a sovereign foundation doesn’t inherit that sovereignty. An infrastructure service strong on supply-chain sovereignty says nothing about the technology sovereignty of the software on top – different layers, different objectives. And an objective that barely applies isn’t a gap: a bare compute service has little to show on data-and-AI sovereignty because it was never meant to. That low mark is scope, not weakness.
One last one: there’s no such thing as “SEAL-certified.” The CSF is an assessment used in procurement, not a certification – no certificate, no certifying body. The phrase should raise an eyebrow wherever it appears.
Its neighbours
A few other instruments sit nearby, and get mixed in. EUCS is a cybersecurity certification scheme, not a sovereignty assessment. France’s SecNumCloud has qualified providers against strict sovereignty criteria for years. Germany’s BSI C3A, from April 2026, builds on the CSF, adding a cloud-autonomy layer on top. And the Commission’s proposed CADA carries its own four-level structure that’s easy to mistake for SEAL – though it’s still only a proposal. Different tools, different jobs. Each deserves its own article.
What it comes down to
The CSF is the best answer yet to a hard question: how to measure something that was never a single thing. Its value is that it keeps sovereignty’s dimensions apart instead of averaging them away.
A score collapses eight different strengths into one number. A profile keeps them apart, so you can see the one that matters for your workload. It was built to give you the second, a profile. Almost every mistake comes from treating the profile as if it were a score.
The EU’s Cloud Sovereignty Framework gives you a profile, not a score.
Originally published on LinkedIn