The EU Cloud Sovereignty Framework Finally Has a Score — Here's How SEAL Actually Works

"EU sovereign" has been a marketing word for two years — every vendor with a Frankfurt data center uses it, and until recently there was no shared yardstick to check the claim against. That changed quietly on June 1, 2026, when the European Commission published the full Implementation Guidance for its Cloud Sovereignty Framework — the exact methodology it used a few weeks earlier to score bidders in the roughly EUR 180 million Cloud III procurement for EU institutions. Unlike most Commission publications, this one includes the actual weights, the actual level definitions, and — per the document itself — "is complemented with a calculator... regarding the various computations performed in the context of the framework, based on the return on experience of the cloud tender."

That's a different kind of document than another sovereignty explainer. It's a scoring instrument that real bidders were actually measured against, published after the fact with its worked logic intact. This post walks through how it actually computes a score, corrects a number that's circulating incorrectly in secondary coverage, and gives you a small Python self-assessment scorer built on the real mechanic — not a marketing simplification of it.

Two separate numbers, not one

The framework produces two distinct outputs, and conflating them is the single most common misunderstanding:

1. The Sovereignty Score — a weighted percentage across eight objectives, each with a fixed weight (e.g. 20% for Strategic Sovereignty, 5% for Environmental Sustainability). This is a compensating average: weakness in one area can be offset by strength in another.
2. The SEAL (Sovereignty Effective Assurance Level) — a 0–4 rating. The Implementation Guidance states this in one unambiguous line: "The overall SEAL level is the lowest SEAL level achieved in any of the objectives."

That second sentence is the part almost every summary skips, and it matters more than the score itself. A provider can post a strong 80%+ weighted Sovereignty Score and still be capped at SEAL-1 because one single objective — often Legal & Jurisdictional Sovereignty, which is largely determined by where your parent company is incorporated — pulled the floor down. The document is explicit about which number actually gates procurement decisions: "It is important to emphasize the prevalence of the SEAL criterion over the Sovereignty Score. In the context of cloud services procurement, the Contracting Authority decides what is the minimum SEAL required. Sovereignty score is used to compare offers that have reached the minimum required SEAL." SEAL is the gate. The percentage only ranks the providers who already cleared it.

The eight objectives and their weights

The framework's eight Sovereignty Objectives, verbatim from the Implementation Guidance, with the weighting used in the actual tender:

The five SEAL levels themselves, also quoted directly from the guidance:

• SEAL-0 — No Sovereignty: service, technology or operations under exclusive control of non-EU third parties, governed entirely by non-EU jurisdictions.
• SEAL-1 — Jurisdictional Sovereignty: EU law formally applies with limited practical enforceability; still under exclusive control of non-EU third parties.
• SEAL-2 — Data Sovereignty: EU jurisdictions apply, but material dependencies remain; operations under indirect control of non-EU third parties.
• SEAL-3 — Technological Sovereignty: EU jurisdictions apply, EU actors exercise meaningful but not full influence; operations under marginal control of non-EU third parties.
• SEAL-4 — Full Digital Sovereignty: technology and operations under complete EU control, subject only to EU jurisdiction, with no critical non-EU dependencies.

Worth noting: the Commission's own "Lessons learnt" section admits SEAL-4 isn't a realistic bar for anyone right now — "not today relevant... considering existing dependence to specific supply chains (chips, hardware)." That's a candid acknowledgment, in an official document, that full EU digital sovereignty doesn't exist yet at the semiconductor layer, no matter how EU-native the software stack above it is.

A primary-source correction: it's 43 questions, not 48

Several third-party explainers of this framework — and, in the interest of transparency, an earlier internal research note we drew on before writing this post — cite "48 criteria" as the size of the assessment. That number does not appear anywhere in the Commission's own Implementation Guidance document. What the guidance actually says, in its "Lessons learnt" section, is this: "The sovereignty assessment, in the version of the framework used for this first tender, is composed of 43 questions spread over the sovereignty objectives. On these 43 questions, 9 are targeting solely the contractors and sub-contractors entities and covered most of the strategic and jurisdictional dimensions, while 19 questions are asked for every technical dimension."

We ran the full PDF through pdftotext and grepped for both numbers directly — "43" appears three times in exactly the passage above; "48" does not appear once in the entire 13-page document. Whether "48" comes from a later framework revision, a different version number, or a chain of secondary sources each rounding or approximating from the last, we can't verify from this document — but if you're citing a hard number, the Commission's own Implementation Guidance for the version actually used in the completed EUR 180M tender says 43, split as 9 entity-level questions plus 34 spread across the technical dimensions (of which 19 apply per technical layer, since a bid's technical stack — compute, storage, network, IAM, PaaS — gets evaluated in depth, not just once at the whole-service level).

Self-assessing against the framework

Since the real 43-question instrument isn't public in reusable form (only the "Sovereign Cloud Framework Matrix" is shown as annotated screenshots in the PDF, not as extractable structured data), the following is a deliberately simplified reproduction of the mechanic — weighted scoring plus weakest-link SEAL — using the real objective weights, applied to a small representative set of criteria per objective rather than the full 43. Treat it as a directional self-check, not a substitute for the Commission's own calculator or a real audit.

#!/usr/bin/env python3
"""Simplified EU Cloud Sovereignty Framework self-assessor.
Reproduces the two real mechanics from the Commission's Implementation
Guidance (June 2026): a weighted Sovereignty Score (0-100%) and a
weakest-link SEAL level (0-4). NOT the official 43-question instrument --
see the source PDF for the full assessment.
"""

# Official weights, verbatim from the Implementation Guidance.
OBJECTIVE_WEIGHTS = {
    "SOV-1 Strategic":            0.20,
    "SOV-2 Legal & Jurisdictional": 0.10,
    "SOV-3 Data & AI":            0.10,
    "SOV-4 Operational":          0.15,
    "SOV-5 Supply Chain":         0.10,
    "SOV-6 Technology":           0.15,
    "SOV-7 Security & Compliance": 0.15,
    "SOV-8 Environmental":        0.05,
}

def score_objective(seal_level: int) -> float:
    """Map a 0-4 SEAL answer to a 0-100 objective score for the weighted
    average. The real calculator uses per-criterion point tables; this
    is a linear stand-in for illustration."""
    return seal_level * 25.0

def assess(answers: dict[str, int]) -> dict:
    """answers: {objective_key: seal_level (0-4)} -- your honest,
    lowest-scoring answer within that objective, since a real objective
    score is itself a weakest-link across its own sub-criteria."""
    missing = set(OBJECTIVE_WEIGHTS) - set(answers)
    if missing:
        raise ValueError(f"missing objectives: {missing}")

    weighted_score = sum(
        OBJECTIVE_WEIGHTS[obj] * score_objective(level)
        for obj, level in answers.items()
    )
    overall_seal = min(answers.values())  # weakest link, per the guidance
    capped_by = [obj for obj, level in answers.items() if level == overall_seal]

    return {
        "sovereignty_score_pct": round(weighted_score, 1),
        "overall_seal": overall_seal,
        "capped_by": capped_by,
    }

if __name__ == "__main__":
    # Example: an EU-incorporated PaaS with no non-EU parent, open-source
    # build tooling, but immature environmental reporting.
    example = {
        "SOV-1 Strategic":            4,
        "SOV-2 Legal & Jurisdictional": 4,
        "SOV-3 Data & AI":            3,
        "SOV-4 Operational":          3,
        "SOV-5 Supply Chain":         2,  # hardware still sourced non-EU
        "SOV-6 Technology":           3,
        "SOV-7 Security & Compliance": 3,
        "SOV-8 Environmental":        1,  # no disclosed carbon reporting yet
    }
    result = assess(example)
    print(result)
    # {'sovereignty_score_pct': 74.5, 'overall_seal': 1, 'capped_by': ['SOV-8 Environmental']}

Run that example and the mismatch jumps out immediately: a 74.5% weighted Sovereignty Score, but an overall SEAL of 1 — because Environmental Sustainability, worth only 5% of the weighted score, single-handedly caps the whole assessment. That's the counterintuitive part of the design, and it's deliberate: the Commission's own procurement decision-makers set a minimum SEAL as a hard gate, then use the percentage only to rank whoever clears it. A vendor optimizing purely for the weighted average — piling up strength in the 20%-weighted Strategic objective while ignoring a 5%-weighted one — is optimizing the wrong number entirely.

What actually moves each objective, and what doesn't

Not all eight objectives are equally fixable, which is the part worth planning around if you're building or buying:

• Structural, hard to change: SOV-1 (Strategic) and SOV-2 (Legal & Jurisdictional) are largely determined by your cap table and your parent company's country of incorporation. If your ultimate parent is a non-EU entity, no amount of technical or contractual effort raises these objectives past the level that legal exposure allows — the guidance's own criteria list asks directly whether "ultimate decision-making authority resides within EU jurisdiction" and whether the provider is exposed to "non-EU laws with cross-border reach (e.g., US CLOUD Act, Chinese Cybersecurity Law)."
• Slow but tractable: SOV-5 (Supply Chain) and SOV-6 (Technology) improve as you document your hardware/firmware provenance and adopt open, auditable standards — real engineering work, but not a legal restructuring.
• Fast and cheap: SOV-8 (Environmental) is the lowest-weighted objective (5%) but, per the worked example above, still fully capable of being your weakest link if you've simply never measured or disclosed it. Low weight does not mean low risk to your overall SEAL — it means low risk to your percentage, which is exactly the trap the weakest-link rule exists to close.

Not mandatory (yet), but not hypothetical either

The framework carries no binding legal force for private commercial contracts today — the Commission's own June 2026 explainer frames it as guidance it "encourages all organisations, both public and private, to consult and use." But it is not a hypothetical exercise either: it is the methodology that already decided a real EUR 180 million EU institutional procurement, and the guidance says explicitly it exists to "support public entities that intend to apply similar approach when assessing the level of sovereignty of digital services." If your product sells into EU public sector, regulated finance, or health, expect a version of this scoring — or a procurement officer who's read this same document — to show up in your next RFP, not your next decade.

One clarification worth making explicitly, since we've seen the two conflated in other coverage of EU cloud sovereignty: SEAL is not part of ANSSI's SecNumCloud qualification. SecNumCloud is France's own national cloud security qualification, administered by ANSSI, and — per ANSSI's own current referential — it is a single unified qualification a provider either holds or doesn't; it does not use a "SEAL-1/2/3" tiered scale. SEAL is the European Commission's separate, EU-level scoring construct from the Cloud Sovereignty Framework covered here, built for the Cloud III DPS tender. They address a related question — how sovereign is this provider, really — through two genuinely different instruments, and treating a SecNumCloud qualification and a SEAL level as the same certification will produce a wrong answer to a due-diligence question, not just an imprecise one.

If you want a ready-made calculator

Two independent, unofficial tools already implement approximations of this methodology if you'd rather answer a questionnaire than adapt the script above: Scrydon's EU Cloud Sovereignty Score Calculator and the open-source flavienbwk/cloud-sovereignty-score project on GitHub. Neither is Commission-endorsed, and — per the same caveat that applies to this post's own script — neither can reproduce the full 43-question instrument exactly, since the underlying per-criterion scoring tables aren't published as structured data, only as an annotated spreadsheet screenshot in the PDF. Both are useful for a directional read; only the Commission's own procurement process produces the number that actually counts in a tender.

Where this leaves EU-native infrastructure choices

For teams choosing infrastructure with an eye on where this is heading: the objectives that weigh heaviest (Strategic at 20%, Operational and Technology and Security & Compliance at 15% each — 65% of the total score between just four of eight objectives) all correlate strongly with one structural fact — whether your provider has a non-EU parent capable of being legally compelled to act against EU interests. That's not a sota.io-specific claim; it's what the framework's own weighting says matters most. An EU-incorporated provider with no non-EU parent starts every one of those four objectives from a structurally better position than a US-parented subsidiary can reach regardless of its technical or contractual commitments — the same dynamic the guidance's own SOV-2 criteria describe directly. Whether that translates into a specific SEAL level for any given vendor is a question only a real assessment against the full 43-question instrument can answer — which is exactly why the framework, and not another marketing claim, is the right thing to actually run your stack against.

See also: why enterprise sovereign cloud launches still leave a developer PaaS gap, what the Airbus AWS exit means for cloud sovereignty.