Cloud sovereignty, checked against evidence.
Cloud sovereignty is the most marketed and least proven category in enterprise IT. Vendors describe themselves as sovereign without saying against what. This tool tests those claims against the European Commission's Cloud Sovereignty Framework, with an open methodology that runs entirely in your browser.
Cloud sovereignty is the most marketed and least proven category in enterprise IT. Vendors describe themselves as sovereign, residency is sold as sovereignty, customer-managed keys are sold as customer-controlled keys. This tool tests those claims, against the European Commission's Cloud Sovereignty Framework v1.2.1 and ten plain-English objectives. It returns a weighted score, a SEAL minimum (the framework's Sovereignty Effectiveness Assurance Level, the bottom band any objective falls into), the marketing claims your answers contradict, and the working that produced each. The methodology sits in the same file, every score is contestable, and nothing leaves your browser.
Scope. Built for buyers, regulators and providers operating under EU and UK sovereignty pressure: GDPR, the EU Cloud Sovereignty Framework, DORA, the Data Act, NIS2 and the AI Act. The structural questions translate to other jurisdictions, but the SEAL bands and regulatory overlays are EU/UK-anchored. Regional overlays for other regimes (FedRAMP, IRAP, MeitY, NCA ECC) are candidates for a later release.
New to cloud sovereignty? Read the plain-English primer →
More on what this tests
The problem. Vendors describe themselves as sovereign. Residency is sold as sovereignty. Customer-managed keys are sold as customer-controlled keys. None of those things are true on inspection, but they survive on the page because no one tests them.
What you get. A weighted Sovereignty Score, a SEAL minimum (the framework's bottom-band assurance level), the marketing claims your answers contradict, and the working that produced each. The methodology sits in the same file. Every score is contestable.
Scope. Built for buyers, regulators and providers under EU and UK sovereignty pressure — GDPR, the EU Cloud Sovereignty Framework, DORA, the Data Act, NIS2, the AI Act. The structural questions translate to other jurisdictions; the SEAL bands and regulatory overlays are EU/UK-anchored.
Five SEAL bands. Ten objectives. One open methodology.
SEAL stands for Sovereignty Effectiveness Assurance Level, defined by the European Commission in the Cloud Sovereignty Framework v1.2.1. The bands describe how much sovereignty an objective demonstrates, from no sovereignty (SEAL 0) to full digital sovereignty (SEAL 4). Click any band for what it means in practice.
Who this is for
Built for people who have to make sovereignty decisions and defend them later. That means CIOs, CTOs and procurement leads facing CLOUD Act exposure, Schrems II supplementary measures, or DORA resilience requirements on regulated workloads. It also means sustainability, risk and compliance teams working under CSRD, NIS2 and the AI Act.
Providers can use the same assessment. Running it against your own service gives you an open, contestable rating to take to customers, rather than a vendor-supplied claim that buyers cannot easily evidence.
How it works
Pick the kind of service you are assessing. Answer 30 to 60 plain English questions, each with a short list of options. Behind the scenes each option maps to a SEAL band, where 0 is no sovereignty and 4 is full digital sovereignty as defined in the EU framework.
You get a weighted Sovereignty Score, a SEAL minimum across all objectives (a service can't be more sovereign than its weakest objective), critical findings written in language a board will read, and a list of marketing claims your answer pattern flags as misleading.
What this is not
It is not a regulatory test, not legal advice, and not a substitute for due diligence. SEAL bands are an assurance framing. The point is to make trade-offs visible, so buyers, regulators and providers can have a clearer conversation than the marketing allows.
Cloud sovereignty, without the jargon
A short read for people who have to make sovereignty decisions, not live inside the framework. If you are briefing a board, a procurement team or a business owner, start here. The Methodology tab has the technical detail.
What the EU Cloud Sovereignty Framework is
The European Commission published the Cloud Sovereignty Framework v1.2.1 in October 2025. It is the EU's first formal definition of what cloud sovereignty means.
Before that, "sovereign cloud" was a marketing term with no test behind it. Different providers used it to mean different things, and nobody had a defensible answer when a buyer asked "according to what".
The framework sets out ten sovereignty dimensions (the Commission's original eight, plus two extensions in this tool) and a five-band assurance scale called SEAL. Both are published openly. Buyers, regulators and providers can now have the same conversation about the same thing, using the same definitions.
It is policy guidance, not law. It does not regulate anyone directly. It does sit behind a growing body of EU regulation that does: GDPR, the Data Act, DORA, NIS2, the AI Act. It is also the language used in the EU certification schemes that carry direct contractual and regulatory weight, including EUCS, SecNumCloud and BSI C5.
Why it matters
Three reasons, depending on what you do.
Sovereignty has moved from a marketing layer to a procurement layer. The framework is what makes that possible.
What the SEAL bands mean
SEAL stands for Sovereignty Effectiveness Assurance Level. The bands describe how much sovereignty a service has, from 0 (none) to 4 (full). They are the Commission's framing, used unchanged.
- SEAL 0No sovereignty
- The provider, the technology and the operations all sit outside the EU. EU law does not reach. Most non-EU services running globally without sovereign branding fall here.
- SEAL 1Jurisdictional only
- EU laws apply on paper. The provider is still under non-EU operational and technological control. The law exists. The enforcement does not. This is where most "sovereign cloud" branded services from US hyperscalers sit.
- SEAL 2Data sovereignty
- EU laws are enforceable. Data is broadly under EU control. Material non-EU dependencies remain in the stack: control plane, identity, software supply chain. The data sits inside EU walls. The bones do not.
- SEAL 3Digital resilience
- EU actors exercise meaningful but not complete control. Most things work without non-EU dependencies. Some structural ceilings remain (silicon, firmware, accelerators) that no commercial provider can fully control today.
- SEAL 4Full digital sovereignty
- Technology and operations under complete EU control. No critical non-EU dependencies. Mostly aspirational for commercial services at the time of writing.
When the tool returns a result it shows two numbers: a weighted sovereignty score out of 100, and a SEAL minimum across all objectives. The minimum is the one that matters. A service is no more sovereign than its weakest objective. A SEAL 4 average with one SEAL 1 weak spot still has a SEAL 1 problem.
The ten objectives
The framework tests sovereignty against ten things. The first eight come from the Commission. The last two are added in this tool, because the framework does not yet reach far enough.
- Strategic. Who owns the business, who funds it, where the IP sits. The structural question before all the others.
- Legal and jurisdictional. Which country's laws can compel the provider to hand over your data, even when the data is in an EU region. The CLOUD Act question.
- Data and AI. Where your data, metadata, telemetry and AI-derived artefacts live, who can read them, and whether deletion is verifiable.
- Operational. Whose hands are on the keyboard. Privileged access, escalation paths, what happens at 3am when a non-EU engineer has to look.
- Supply chain. Where the silicon, firmware and software come from, who controls the updates, whether you can audit any of it.
- Technology. Open standards, portability, transparency of architecture, whether you can leave without a rebuild.
- Security and compliance. EU-specific certification schemes (EUCS, SecNumCloud, BSI C5) versus generic global ones (ISO 27001, SOC 2). The latter does not mean sovereignty.
- Environmental. Site-level efficiency you can audit, hourly carbon-free energy on the grid the site actually draws from (24/7 CFE), demand response when the grid asks for it, and honest embodied-carbon disclosure. Not glossy sustainability reports and not certificates bought on a different grid.
- Identity and root-of-trust. Posetiv extension. Where the identity control plane lives, who controls break-glass, whose code-signing chain you trust.
- SaaS and dependency graph. Posetiv extension. The transitive third-party services your data hits: identity, payments, observability, communications. This is where SaaS sovereignty most often unravels in practice.
What to do with your score
The tool returns a weighted sovereignty score and a SEAL minimum. The minimum is the headline. The score is the supporting detail. What to do next depends on what the report tells you.
The full methodology, the per-objective rubric, the anchor instruments per band, and the 35 pre-scored providers all live in the other tabs.
Run an assessment
Pick the service type, set the boundary, answer the questions. Each answer maps to a SEAL band, and the result is built up as you go. Nothing leaves your browser; progress is saved locally so you can step away and come back. The methodology meta on the right shows the version, question count for the chosen mode, time remaining, and where your work is held.
What are you assessing?
Different service types pull different questions. SaaS, for example, places more weight on sub-processors and the dependency graph than IaaS does.
Workload classification (optional)
Used to produce an acceptability statement on the result. Leave blank if not relevant.
Assessment boundary (optional)
What is inside the boundary you are scoring? Anything excluded becomes a transparency gap on the result, not a free pass.
Your result
Run an assessment to see your result here.
Pick a service type, set the boundary, answer a structured set of plain-English questions. Your weighted Sovereignty Score, SEAL minimum, critical findings and the marketing claims your answers contradict will appear in this panel. Nothing leaves your browser; progress is saved locally.
Compare providers
Pre-scored against the ten objectives using public evidence and the same SEAL bands as the assessment. Click any provider name for the full breakdown and evidence trail.
On grouping. "European-controlled (EU + adequacy)" covers providers headquartered and operated inside the EU plus adequacy-aligned jurisdictions (currently the UK and Switzerland). The UK is in the group because it holds an active EU adequacy decision (2021, renewed 2025), not because UK = EU. EU-strict mode caps UK and Swiss providers at SEAL 3 to reflect that distinction. The full reasoning is in the methodology under "Cross-cutting rules: adequacy framing".
Visual comparison
Pick up to three providers and see their sovereignty profile plotted side by side. The shape, not the score, tells you where the asymmetry sits — a tall narrow shape is uneven sovereignty; a balanced large shape is structural sovereignty.
Side-by-side evidence
The same providers picked above, plotted as an evidence table. Each cell shows the SEAL band and the public evidence behind it. Change the picks in the dropdowns above to update this view.
Marketing Claims
Claims providers make that are technically true but commonly mistaken for sovereignty. Grouped by where they do the most damage. The assessment surfaces these automatically when your answer pattern matches them.
Methodology
Foundation and scope
Foundation
This tool uses the EU Cloud Sovereignty Framework v1.2.1 (October 2025), published by the European Commission's Directorate-General for Digital Services, as its structural spine. The eight Sovereignty Objectives (SOV-1 to SOV-8), the five Sovereignty Effectiveness Assurance Levels (SEAL-0 to SEAL-4), and the published 15/10/10/15/20/15/10/5 weightings are preserved.
Two extension objectives, SOV-9 and SOV-10, cover ground the framework does not yet reach: identity and root-of-trust, and the SaaS / network / dependency-graph layer. These extensions carry weight in the default ("Posetiv extended") scoring and zero weight in "EU framework strict" scoring. Both are shown on results.
The assessment also references the STEP Seal as a marker of EU strategic alignment, not as a sovereignty determination in itself.
Scope and applicability
This tool is built for buyers, regulators and providers operating under EU and UK sovereignty pressure. The methodology is anchored to GDPR, the EU Cloud Sovereignty Framework, DORA, the Data Act, NIS2 and the AI Act, with UK applicability through equivalent or aligned regimes. Multinationals headquartered outside the EU but operating inside it are squarely in scope.
The ten objectives and the question structure translate to other jurisdictions, and many of the principles, jurisdictional reach, identity control plane, sub-processor disclosure, exit and substitutability, are useful in any sovereignty assessment. However, the SEAL bands, the EU-strict weighting, and the regulatory overlays are EU/UK-anchored. Buyers under FedRAMP, IRAP, MeitY, NCA ECC or comparable regimes will find the structural questions useful, but should expect to layer their own regional overlay.
Regional overlays for other regimes are a candidate for a later release. Submissions and corrections from buyers, regulators or providers in those jurisdictions are welcomed at sovereignty@posetiv.co.uk.
How scoring works
Plain English answers, SEAL bands underneath
Users do not need to know what SEAL-2 means to answer the questions. Each option is plain language. Behind the scenes, options map to a SEAL band 0 to 4. The total Sovereignty Score uses the framework's published formula: the weighted sum of (objective score divided by max objective score) multiplied by objective weight.
"I don't know" and unanswered questions
Every question allows "I don't know." This is deliberate. If a provider cannot answer a sovereignty question with evidence, that is a finding, not a missing data point. "I don't know" is treated as SEAL-1 for scoring and flagged separately as a transparency gap.
An unanswered question is treated as a more severe gap than "I don't know" and is handled differently. Unanswered questions are excluded from the score, the SEAL minimum and the per-objective bars; the score reflects only the questions the user has actually answered. The completeness count is shown on the result page, and unanswered foundational questions appear in the Foundational unknowns card. With "I don't know" the user has at least registered the question; an unanswered question has not been engaged with at all, and folding it into the score would manufacture a number out of nothing.
If no questions have been answered, the tool refuses to produce a score at all. If not every in-mode objective has at least one answered question, the SEAL minimum and the workload acceptability statement are withheld until coverage is complete.
Absence of evidence
Absence of evidence is not proof of absence. The provider may have the capability but not have published or contractually documented it. The expectation is that providers can supply the evidence on request, and that buyers should require it during procurement. A sovereignty claim that cannot be evidenced is a sovereignty claim worth challenging, not automatically a sovereignty failure.
How to read a provider score
Provider scores are at the provider level. Real-world deployments may vary by:
- Service, different services within the same provider can have different sovereignty profiles (e.g. Azure SQL Database is not Azure OpenAI).
- Region, sovereign regions may differ from commercial regions of the same provider.
- Configuration, controls that exist as options may not be enabled by default.
- Contract, bespoke contractual terms can move some objectives, particularly SOV-2 and SOV-7.
- Operational model, what happens at runtime under load, support, incident response, failover, and break-glass scenarios may differ from the default posture.
Treat the provider-level score as an indicative starting point. The questionnaire mode is for assessing a specific service, configuration and contract.
SEAL band rubric
Each provider score is the result of applying the rubric below to public evidence. The rubric is published so any score is contestable against an explicit standard rather than an opinion.
Framework anchoring and interpretation
The EU Cloud Sovereignty Framework v1.2.1 defines the eight Sovereignty Objectives (SOV-1 to SOV-8), the five SEAL bands (0–4), and the published weightings (15/10/10/15/20/15/10/5). The framework's per-band descriptions are strategic in tone. It does not define operational tests for what each SEAL band means per objective. That work is left to assessors.
The rubric below is Posetiv's interpretation of each (objective × SEAL band) cell, anchored to current EU law and recognised standards. The interpretation is published so it can be challenged. A different assessor could reasonably draw the band cut-offs elsewhere. Where the cell criteria are tighter than the framework's published wording, that is a deliberate operationalisation, not a re-statement.
SOV-9 (identity, auth and root-of-trust) and SOV-10 (SaaS, network and dependency-graph) are explicit Posetiv extensions to the framework rather than reinterpretations of it. They carry weight in the default scoring and zero weight in EU-strict scoring so the EU-strict score remains comparable to the framework as published.
Anchor instruments per objective are listed under each rubric heading below ("Anchored to…"). They are: extraterritorial law (CLOUD Act, FISA 702, EO 14117, UK IPA, PRC NIL); EU-specific cloud certification schemes (EUCS, SecNumCloud, BSI C5, ENS, HDS); EU sustainability instruments (ISO 30134, EU Energy Efficiency Directive Annex VII, EU Code of Conduct for Data Centres, CSRD); EU adequacy decisions (UK 2021/2025, Switzerland Decision 2000/518/EC); open-standards bodies (GAIA-X, IDSA, OpenStack, Kubernetes). Each anchor is a real instrument; the band cut-offs are interpretation.
Not all objectives need the same amount of interpretation. SOV-2 and SOV-7 sit closest to the framework, which names extraterritorial laws and EU certification schemes itself. SOV-1, SOV-3 and SOV-6 are framework-aligned with operational detail layered on. SOV-4 and SOV-5 require heavier operationalisation, especially the structural ceiling on SOV-5 around silicon. SOV-8 is the heaviest interpretation: the framework is largely silent on operational environmental tests, so band cut-offs lean on ISO 30134, the EED Annex VII, the EU Code of Conduct for Data Centres and CSRD. SOV-9 and SOV-10 are not interpretations, they are explicit extensions, because the framework does not cover identity / root-of-trust or the dependency graph.
Contesting the interpretation. If you think a specific cell cut-off is wrong, send the contesting evidence and reasoning to sovereignty@posetiv.co.uk. That is how the methodology gets better.
Cross-cutting rules
Structural ceiling on supply chain (SOV-5). SEAL 4 in supply chain requires EU silicon, EU firmware and an EU-controlled hardware build chain. None of these exist at production scale at the assessment date. No current cloud provider can score SEAL 4 on SOV-5. The ceiling lifts when EU silicon (RISC-V on EU fabs, EU-designed accelerators) reaches production maturity.
SEAL 3 on SOV-5 is read against the same ceiling. Because no EU provider currently controls upstream firmware (AMI, Insyde, AMI Aptio) or the dominant OS distributions, SEAL 3 is awarded where a provider demonstrates EU-controlled hardware design and assembly, plus published supply-chain transparency (component origin, SBOM or equivalent). EU control of firmware and OS remains the SEAL 4 expectation, not the SEAL 3 threshold. This avoids penalising EU providers for an industry-wide gap that no provider can independently close, while keeping the bar honest: design, assembly and transparency are minimum evidence, not a free pass.
SEAL 4 requires across-the-offering scope. Where a provider holds an EU certification for "some offerings" but not the broader cloud, the band is SEAL 3 at most. SEAL 4 requires the certification to cover the entire assessed offering, not a sovereign sub-product line.
SEAL 4 in SOV-3 (Data & AI) requires both. A strong data-residency posture without a comparable AI-sovereignty posture caps SOV-3 at SEAL 3.
"I don't know" sits at SEAL-1 for scoring. Unanswered questions are excluded from the score arithmetic. Some derived risk rules (sub-processor disclosure, privileged access, exit posture, DORA findings) treat "I don't know" as the worst case because the operational risk is the same.
UK and Swiss adequacy: SOV-1 and SOV-2 SEAL 4 eligible. UK-controlled providers are eligible for SEAL 4 on SOV-1 (Strategic) and SOV-2 (Legal & jurisdictional) on the basis of UK GDPR adequacy (granted 2021, renewed 2025), UK regulatory authority (ICO), and UK courts' independent judicial oversight. Swiss-controlled providers are eligible on the same basis (long-standing EU adequacy under Decision 2000/518/EC). UK Investigatory Powers Act exposure is narrower than US CLOUD Act and is acknowledged in evidence rather than capping the score. EU-strict mode applies a stricter view: UK and Swiss providers are capped at SEAL 3 on SOV-1/SOV-2 in the EU-strict score, because from a strict EU-sovereignty perspective UK and Switzerland remain non-EU. The headline (extended) score reflects EU/UK sovereignty as scoped by this methodology; the EU-strict score reflects the stricter EU-only reading.
SOV-1 Strategic sovereignty weight 12 · EU-strict 15
Anchored to: EU corporate law (incorporation, board domicile, equity ownership disclosure); EU adequacy decisions (UK 2021/2025, Switzerland Decision 2000/518/EC). Band cut-offs reflect Posetiv's interpretation of "appropriate corporate sovereignty" against these instruments.
| SEAL 4 | EU-incorporated parent, EU-domiciled board majority, EU-registered IP, no material non-EU equity or debt. UK or Swiss-controlled providers are also eligible on the basis of UK GDPR adequacy and Swiss adequacy (see cross-cutting rules); EU-strict mode caps these at SEAL 3. |
|---|---|
| SEAL 3 | EU parent with EEA exposure, or minority non-EU equity that does not control material decision rights. Also: UK or Swiss-controlled providers in EU-strict mode (see above). |
| SEAL 2 | EU operating entity but parent is non-EU, or EU parent with material decision rights flowing to non-EU jurisdictions. |
| SEAL 1 | Non-EU parent (US, UK post-Brexit, CH, RU, CN) with EU operating subsidiary. Parent jurisdiction can compel direction of the subsidiary. |
| SEAL 0 | Non-EU controlled with no material EU operating presence, or EU operating entity with no decision rights independent of the parent. |
SOV-2 Legal & jurisdictional sovereignty weight 10 · EU-strict 10
Anchored to: US CLOUD Act (2018), FISA Section 702, Executive Order 14117 (data brokers), UK Investigatory Powers Act, PRC National Intelligence Law, PRC Cybersecurity / Data Security / Personal Information Protection Laws. GDPR adequacy decisions for UK and Switzerland. Band cut-offs reflect Posetiv's interpretation of mitigated vs structural exposure.
| SEAL 4 | Only EU and member-state law applies. No CLOUD Act, FISA 702, EO 14117, PRC NIL or comparable broad extraterritorial reach. Direct EU audit rights survive change-of-control. UK-controlled providers are also eligible: UK Investigatory Powers Act exposure is narrower than US CLOUD Act, with independent judicial oversight via the Investigatory Powers Tribunal, and is acknowledged in evidence rather than capping the score (see cross-cutting rules); EU-strict mode caps these at SEAL 3. Swiss-controlled providers eligible on the same basis. |
|---|---|
| SEAL 3 | EU law primary with limited or contractually mitigated extraterritorial exposure, supported by independent legal opinion. Also: UK or Swiss-controlled providers in EU-strict mode (see above). |
| SEAL 2 | EU law applies but parent jurisdiction's extraterritorial law can compel the parent. Mitigation is contractual or organisational, not structural. |
| SEAL 1 | Parent in a broad-extraterritorial jurisdiction with no structural mitigation. Risk of compelled access without notice. |
| SEAL 0 | Parent jurisdiction's law overrides EU law in practice; no EU law application meaningfully reaches the service. |
SOV-3 Data & AI sovereignty weight 10 · EU-strict 10
Anchored to: GDPR (data residency, data subject rights), EU Data Boundary frameworks, EU AI Act (high-risk AI provisions), customer-held HSM standards (FIPS 140-2/3), verifiable cryptographic erasure principles. The "data and AI" dual test is required by the framework but operationalised here.
| SEAL 4 | All customer primary data, telemetry, metadata, control-plane API calls and AI artefacts (embeddings, fine-tuned models, RAG indices) reside, process and route within the EU. Customer-held EU HSMs. Verifiable cryptographic erasure on termination. AI training, weights and inference EU-only. |
|---|---|
| SEAL 3 | Data EU-resident with EU keys. Telemetry, metadata and AI inference predominantly EU with documented exceptions. Provider can identify all non-EU data flows. |
| SEAL 2 | Data EU-resident, but telemetry and AI silently route non-EU by default. Customer key custody possible but not default. |
| SEAL 1 | Residency available as configuration, not default. AI features non-EU. Provider keys, not customer keys. |
| SEAL 0 | No meaningful data residency or AI control. Data, telemetry and AI flows are global or US-centric by design. |
SOV-4 Operational sovereignty weight 12 · EU-strict 15
Anchored to: SecNumCloud privileged-access requirements, EUCS operational sovereignty criteria, NIS2 supply-chain due diligence (Article 21), DORA ICT third-party risk requirements (Articles 28–30). Band cut-offs reflect the difference between contractual and structurally enforced geofencing.
| SEAL 4 | All privileged access, including break-glass and tier-3 support, is EU-resident, EU-employed, EU-jurisdiction. Geofencing contractual and technically enforced. Customer-accessible audit trail of every privileged session. EU-located SOC. |
|---|---|
| SEAL 3 | EU privileged access by default with documented exceptions and named approvals. Geofencing technically enforced for routine operations. Tier-3 EU. |
| SEAL 2 | EU privileged access available as a paid tier or for specific certifications, not default. Support is "follow-the-sun" with non-EU staff in routine operations. |
| SEAL 1 | Global SRE pool retains technical capability for privileged access regardless of geofencing claims. Break-glass crosses jurisdictions. |
| SEAL 0 | Operations entirely non-EU. No EU privileged access path. |
SOV-5 Supply chain sovereignty weight 16 · EU-strict 20 · ceiling SEAL 3
Anchored to: EU Chips Act, EU Cyber Resilience Act (SBOM requirements), EU Critical Raw Materials Act, NIS2 supply-chain due diligence, Open Compute Project (OCP) hardware transparency, RISC-V on EU fabs roadmap. The structural ceiling at SEAL 4 reflects current EU silicon production reality, not Posetiv interpretation.
| SEAL 4 | EU silicon (CPU and accelerator), EU firmware, EU OS, EU build infrastructure, EU code-signing chain, EU Tier-1 suppliers. No current provider qualifies. Structural ceiling. |
|---|---|
| SEAL 3 | EU-controlled hardware design and assembly, with published supply-chain transparency (component origin, SBOM or equivalent). EU control of OS, firmware, build and signing is preferred but not required at SEAL 3 because no EU provider currently controls these layers (see structural ceiling). Silicon remains non-EU by definition at this band. |
| SEAL 2 | Mixed supply chain. Standard non-EU silicon (Intel, AMD, NVIDIA), non-EU firmware (AMI, Insyde), Linux-based OS with mixed contribution. Some EU manufacturing or design. |
| SEAL 1 | Full reliance on US silicon, firmware, OS distributions, and build/sign infrastructure. Limited or no supply-chain transparency. |
| SEAL 0 | No supply-chain transparency, full non-EU dependency, no EU control points anywhere in the stack. |
SOV-6 Technology sovereignty weight 12 · EU-strict 15
Anchored to: GAIA-X policy rules and labels, IDSA (International Data Spaces Association), open-standards bodies (CNCF/Kubernetes, OpenStack Foundation, S3 API ecosystem, PostgreSQL). EU Data Act portability and switching obligations (Articles 23–31). Band cut-offs reflect substitutability, not just open-source presence.
| SEAL 4 | Open standards portable across multiple EU providers. No proprietary lock-in. APIs follow open EU standards (GAIA-X, IDSA). Workloads and data exit at no significant rebuild cost. |
|---|---|
| SEAL 3 | Open standards (Kubernetes, OpenStack, S3-compatible, PostgreSQL) with provider-specific extensions on top. Documented exit plan with reasonable parallel-run window. Most workloads portable. |
| SEAL 2 | Mostly open standards but with material proprietary extensions. Exit possible with significant refactor effort. |
| SEAL 1 | Proprietary APIs and managed services dominate. Exit requires substantial rebuild. Open-standard compatibility is partial or aspirational. |
| SEAL 0 | Fully proprietary stack with no open-standard compatibility. Exit at customer's full rebuild cost. |
SOV-7 Security & compliance sovereignty weight 8 · EU-strict 10
Anchored to: EUCS (EU Cybersecurity Certification Scheme for Cloud Services) Substantial and High; ANSSI SecNumCloud 3.2 (France); BSI C5 (Germany), Type 1 vs Type 2 attestations; ENS (Spain); HDS (France healthcare); ISO/IEC 27001/27017/27018/27701; SOC 2 Type II; ISO/IEC 42001 (AI management). UK-procurement portfolio equivalents (G-Cloud, NCSC Cloud Security Principles, NHS DSP Toolkit, CSA STAR) where UK adequacy framing applies.
| SEAL 4 | EUCS High or SecNumCloud across the entire assessed offering. EU-resident regulator audit rights, contractually enforceable. EU-resident certificate authority chain. Telemetry and security event data EU-only. |
|---|---|
| SEAL 3 | Either: (a) EUCS Substantial, SecNumCloud, BSI C5 high, ACN-qualified or UK procurement portfolio (G-Cloud + NCSC Cloud Security Principles + NHS DSP Toolkit) across most of the offering, with audit rights via EU/UK regulator with named scope; or (b) alternate path: EU- or UK-incorporated provider with EU/UK SOC, EU/UK-only data processors, full EU/UK regulator audit access (no extraterritorial blocking), ISO 27001 + SOC 2 Type II, and regulator-validated privacy posture (positive DPIA or equivalent). The alternate path recognises EU/UK-native providers whose operational posture meets SEAL 3 expectations even where formal sovereignty certification is still in progress. |
| SEAL 2 | ISO 27001 and SOC 2 with one or two EU-specific certifications (EUCS Substantial, BSI C5 basic, HDS) or a regulator-validated privacy assessment (positive DPIA) for specific offerings. Paper-based audit only. |
| SEAL 1 | ISO 27001 and SOC 2 only. No EU-specific certification at scope. Generic compliance posture treated as a substitute for sovereignty. |
| SEAL 0 | Self-declared compliance only. No third-party certifications or no audit rights of any kind. |
SOV-8 Environmental sustainability weight 5 · EU-strict 5
Anchored to: ISO/IEC 30134 series (PUE, WUE, CUE, REF, ITEU); EU Energy Efficiency Directive (Directive (EU) 2023/1791) Annex VII data centre reporting obligations; EU Code of Conduct for Data Centres (voluntary scheme run by JRC); Corporate Sustainability Reporting Directive (CSRD); EMAS (EU Eco-Management and Audit Scheme); Climate Neutral Data Centre Pact targets; Climate Group 24/7 Carbon-Free Energy technical criteria and the UN-backed 24/7 CFE Compact; EnergyTag granular certificate scheme (hourly-matched energy attribute certificates); Green Software Foundation Software Carbon Intensity (SCI) specification (ISO/IEC 21031). The framework's environmental objective is high-level; the band cut-offs operationalise these specific instruments. SOV-8 is read as a sovereignty-of-impact test, not a sustainability badge: a service whose energy claims rely on market-based RECs on a different grid is operationally less sovereign over its own footprint than one matching hourly on the grid it actually draws from.
| SEAL 4 | Site-level ISO 30134 metrics (PUE, WUE, CUE, REF, ITEU) publicly disclosed and externally assured. Hourly (24/7) carbon-free energy matching on the same grid zone the site draws from, evidenced by EnergyTag-style granular certificates or equivalent third-party-verified hourly data, with disclosed annual CFE coverage and disclosed residual fossil hours. Demonstrated grid-flexibility participation (demand response, frequency response, or workload time-shifting to align with CFE supply). Embodied carbon (Scope 3 upstream) disclosed at hardware level. CSRD with limited assurance. EU CoC for Data Centres signatory at site level. Hardware lifecycle traceability documented. |
|---|---|
| SEAL 3 | Site-level PUE and WUE disclosed and audited. Renewable sourcing through a same-country (or same balancing zone) PPA with at least daily or sub-daily matching, or hourly matching across most hours. CSRD reporting in place. Active in EU CoC for Data Centres or equivalent voluntary scheme with disclosed metrics. Some grid-flexibility or workload-shifting participation. Embodied carbon disclosed at portfolio level. |
| SEAL 2 | Site-level PUE published but unaudited, or portfolio-averaged disclosure. Renewable claim through annual PPA matching, EU grid by preference. RECs / Guarantees of Origin may supplement. No grid-flexibility participation disclosed. Embodied carbon not disclosed. CSRD intent declared but not yet reported. |
| SEAL 1 | Portfolio-level claims only. Renewable claim relies on unbundled certificates (RECs, Guarantees of Origin) or market-based instruments without locational deliverability. No site-level metrics. Generic "carbon neutral" or "net zero" claims, often with offsets. CSRD compliance unclear. |
| SEAL 0 | No environmental disclosure beyond marketing claims. No metrics, no third-party assurance, no renewable sourcing evidence. |
Note on 24/7 CFE. The Climate Group 24/7 CFE technical criteria distinguish granularity (hourly vs daily vs annual), locational deliverability (same balancing area, same grid zone, same country, market-based), generation eligibility (additionality, technology mix), and verification (granular certificates, third-party audit). SOV-8 uses the same axes but compresses them into the SEAL bands above. A provider scoring SEAL 4 here would typically pass the Climate Group's CFE Score Tier 1 / 2.
SOV-9 Identity, auth & root-of-trust weight 7 · EU-strict 0 (extension)
Posetiv extension to the framework. Anchored to: eIDAS / eIDAS 2.0 trust services regulation; EU Digital Identity Wallet framework; FIPS 140-2/3 HSM standards; EU code-signing CA chain expectations. SOV-9 is not in the EU CSF v1.2.1 published scope; carries weight in the default scoring and zero weight in EU-strict scoring.
| SEAL 4 | EU-located IdP control plane. EU HSMs for all key custody, customer-controlled. EU code-signing chain. Break-glass and root-account recovery EU-only. |
|---|---|
| SEAL 3 | IdP control plane EU. HSMs in EU sites. Some non-EU root authority dependency in code-signing chain. Break-glass EU-led with documented exceptions. |
| SEAL 2 | Identity decisions made in EU regions but IdP control plane (Microsoft Entra, AWS IAM/STS) is global with non-EU coordination. HSMs available but not default. Break-glass crosses jurisdictions. |
| SEAL 1 | Identity and IdP control plane non-EU-anchored. EU regions consume identity from non-EU control plane. Customer-managed keys are provider-stored. |
| SEAL 0 | No EU identity or key control. Root of trust entirely non-EU. |
SOV-10 SaaS, network & dependency-graph weight 8 · EU-strict 0 (extension)
Posetiv extension to the framework. Anchored to: GDPR Article 28 sub-processor disclosure obligations; CISPE Code of Conduct for Data Protection; DORA ICT third-party register (Article 28); transitive dependency expectations for DNS, CA, CDN, identity, telemetry, observability and AI routing. SOV-10 is not in the EU CSF v1.2.1 published scope; carries weight in the default scoring and zero weight in EU-strict scoring.
| SEAL 4 | Full transitive sub-processor list disclosed including DNS, CA, CDN, identity, telemetry, observability, AI routing dependencies. Audit rights with change-on-consent. All disclosed sub-processors EU-resident or EU-operated. No silent fallback to non-EU services. |
|---|---|
| SEAL 3 | Full direct sub-processor list disclosed. Transitive disclosure on request with reasonable scope. Most sub-processors EU. Documented exceptions for DNS, CA, CDN where no EU alternative exists. |
| SEAL 2 | Direct sub-processor list disclosed in standard DPA. Transitive disclosure not standard. DNS, CA, CDN dependencies global by default. |
| SEAL 1 | Direct sub-processor list partial or significantly delayed. No transitive disclosure. Heavy use of US-anchored network and identity dependencies. |
| SEAL 0 | No sub-processor disclosure. Opaque dependency chain. |
The ten objectives, weights and summaries
Provider data and contestability
Pre-scored providers
The comparison view pre-scores 37 providers across seven groups: US hyperscalers, US "sovereign" wrappers, AI services (non-EU and EU), other non-EU, EU joint ventures, and European-controlled (EU member states plus adequacy-aligned jurisdictions, currently the UK and Switzerland). Each cell carries an evidence note. Where a provider claims more than the public evidence supports, the score reflects what is verifiable, not what is claimed. Scores are based on publicly available information at the per-provider review date.
Open methodology, contestable scores
This methodology is open. The full question set, the SEAL mappings, the provider scores and the evidence references are all in this single file. If a provider believes a score is wrong, contact sovereignty@posetiv.co.uk with the contesting evidence. Corrections that hold up will be incorporated and credited.
This is maintained by Posetiv as an open methodology. It is not a commercial product. There is no telemetry. Nothing leaves your browser.
Linking and citation
The tool lives at sovereignty.posetiv.co.uk and that subdomain is stable. Per-provider deep links use hash routing (e.g. sovereignty.posetiv.co.uk/#provider/datavita) and the provider IDs do not change between releases. Anything you link to today will resolve under future methodology versions. Tab links use the same pattern (#methodology, #compare, #confusions).
For citations, please reference the methodology version (shown below) so any later score change is traceable. Provider scores reflect the methodology version date on each provider detail page (Last reviewed).
Methodology version 1.3.43 · last reviewed June 2026.