A category is only as good as its definition of what qualifies. This page holds the proof layer of the framework: the support model that sovereignty is tested against, the conformance checklist and the Sovereignty Test, the Mark that turns a result into something a buyer can compare, and the members who govern the whole.

Four parts, in the order they build on each other:

• The support model - the six levels, and why each must be sourceable independently
• Conformance and the Sovereignty Test - the checklist, what EU law already requires, and the one practical test
• The Verified Sovereign Computing Mark - tiers, assessment levels, and how a buyer reads them
• Members - the organisations building and governing the category

Full definitions of every level, the conformance criteria per level, and the scoring rubric are in the support definitions.

The support model

Open source code is necessary for sovereignty, but it is not sufficient. An organisation can run entirely open software and still be captive to the one vendor that knows how to operate it. Sovereign computing closes that gap by treating support itself as something you must be able to buy from more than one supplier.

The principle

A sovereign cloud must deliver support from Level 0 through Level 5. The defining property of an open sovereign cloud is that each level can be sourced from a different vendor. Any organisation offering support at a given level must expose open, documented interfaces to the levels on either side of it - downstream, towards the end user, and upstream, towards the maintainer.

Without those interfaces, the cloud is locked to a single support vendor, whatever the licence on its code.

The six levels

Level 0 — Self-service (free)

Documentation, FAQs, a public community forum, and Knowledge Briefs covering known defects and workarounds - published under a redistributable licence and offered through a machine-readable feed.

Level 1 — First contact

Human or AI-assisted help for end users, plus triage: deciding whether an issue belongs to the application, the cloud, the network, or the device, and raising a tracked ticket to the right Level 2 desk.

Level 2 — Helpdesk and application support

Staff experienced in the specific technology. They reproduce issues, apply known workarounds, resolve configuration problems, escalate genuine defects to Level 3, and contribute new workarounds back to Level 0.

Level 3 — Engineering

Root-cause analysis of suspected bugs and of issues with no existing Knowledge Brief. Produces documentation fixes, enhancement requests, defect filings to Level 4, or operational change requests - and a Knowledge Brief for each.

Level 4 — Vendor, upstream, and maintainer

The party that actually changes the code, the schema, or the hardware - upstream open source projects, commercial distribution maintainers, and hardware vendors.

Level 5 — Strategic and advisory

Long-horizon engagement: architecture, roadmap influence, regulatory alignment, multi-vendor coordination, and sovereignty assurance. Partial to the customer, not to any one vendor.

How escalation works

Consider a CRM service: a web application, running on platform infrastructure, on underlying infrastructure, reached by a client over a network. Two triage decisions structure the escalation across that stack:

• Level 1 decides whether the issue lies with the client, the network, or the application, and routes to the matching Level 2 desk.
• Level 3 decides whether the root cause is in the application, the platform, or the infrastructure, and routes to the matching Level 4 maintainer.

In an open sovereign cloud, each of those desks may be a different organisation. The handovers between them are therefore not internal workflow steps but contractual handovers, each crossing a documented, open interface.

The interfaces every level must expose

• a documented ticket or case-exchange API for handover between levels
• read access to Level 0 knowledge for every higher level
• a contribution path back into Level 0 knowledge from every higher level
• a bug or change-request API into the next level up

These interfaces are what let a customer mix providers - community Level 0, one vendor for Levels 1 to 3, the upstream project at Level 4 - and change any of them without losing continuity. That ability to switch is the practical test of sovereignty, set out below.

Conformance and the Sovereignty Test

Sovereign computing makes its claims testable: a cloud demonstrates conformance through a published, signed report, assessed item by item against a shared checklist.

How conformance works

The conformance checklist uses the keywords MUST, MUST NOT, SHOULD, and SHOULD NOT in the sense of RFC 2119: MUST items are required for conformance; SHOULD items are strongly recommended, and any deviation must be justified in the report.

A cloud's conformance report completes the checklist item by item - each marked pass, fail, or not applicable, with rationale - dated and signed by the operator, and published openly. A cloud that claims to be an open sovereign cloud without a current public conformance report does not meet the definition.

What the checklist covers

Cross-cutting requirements

Every inter-level handover is exposed via a documented, versioned API; those APIs accept any licensed adjacent-level provider without a separate partnership; the operator publishes a machine-readable registry of providers at each level; and nothing in the operator's terms prevents a customer sourcing a provider independently.

Per-level requirements (Levels 0 to 5)

Each support level has its own checks - from Level 0's public documentation, forum, and machine-readable Knowledge Brief feed, through the ticket and escalation APIs at Levels 1 to 3, to Level 4's public issue tracker, public source, signed reproducible builds, and CVE feed, and Level 5's public governance and migration guarantees.

Component conformance

Every component is listed in a Component Conformance Manifest with its Level 4 status, and marked either substitutable or load-bearing.

What EU law already requires

Two of the requirements in this checklist are not only good practice. They are becoming conditions that European law attaches to cloud and digital infrastructure, which means an organisation asked to demonstrate them will need the same evidence a sovereignty assessment asks for.

A software bill of materials

The Cyber Resilience Act, Regulation (EU) 2024/2847, defines a software bill of materials at Article 3, point (39). The Cloud and AI Development Act proposal, COM(2026) 502 final, then makes one a condition of assurance. Annex II requires that an audited provider demonstrates that

a complete and up-to-date software bill of materials (SBOM), as defined in Article 3, point (39), of Regulation (EU) 2024/2847, and a list of identified dependencies relevant to the provision of the service are documented and made available to the auditing organisation.

The Cyber Resilience Act supplies the definition; the Cloud and AI Development Act proposal makes producing one a thing you are audited on. An SBOM is therefore not an artefact you generate for a certificate and file away, but a document that has to be current and has to be handed over.

Components you cannot support are a stated risk

The same Annex II clause continues, addressing components from outside the Union. Where such components are used, a provider must implement and document controls to

block any remote features that could materially tamper with or disrupt a device, system, or software (including during updates) and to ensure that the security-relevant components from third-country software manufacturers [...] are subject to source code audits, and have a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

Two things follow. Source code audits require the source, which is why supportability and openness are the same question in practice. And a migration plan for vendor failure is exactly the multi-vendor property the support model describes: if only one organisation can support a component, the migration plan has nowhere to migrate to.

A further clause addresses open-source software directly, requiring a provider that uses it to have implemented and documented controls preventing the use of remote features that could tamper with or disrupt a system. Using open source does not remove the obligation to know what it does and to be able to stop it.

Status of these instruments

Regulation (EU) 2024/2847, the Cyber Resilience Act, is adopted law. The Cloud and AI Development Act, COM(2026) 502 final, is a Commission proposal and its text may change before adoption. The direction is consistent with the checklist either way: know what your software is made of, and be able to keep it running without the original vendor.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act); COM(2026) 502 final annexes, Annex II, assurance level criteria.

The Sovereignty Test

Behind the detail is one practical test. A cloud passes only if all of the following are true at the same time:

• For each of Level 1, Level 2, and Level 3, the customer could today source that level from at least two independently owned providers. At Level 4, at least two independent organisations offer commercial-grade maintenance of the component.
• A customer that switches its Level 2 provider next quarter keeps its historical tickets, its Knowledge Brief contributions, and the operational telemetry it generated.
• Every interface used in such a switch is one of the documented APIs published under the cross-cutting requirements.
• The conformance report is published openly, dated, and signed.

A cloud that fails any one of these is not an open sovereign cloud, however much else it satisfies. The principle is simple: a customer that cannot change its Level 2 provider next quarter is not on a sovereign cloud.

The Verified Sovereign Computing Mark

The conformance checklist tells an operator whether it qualifies. The Verified Sovereign Computing Mark turns that into something a buyer can recognise and compare across competing clouds. This part of the framework is in active development; the shape below is the working model.

A Mark has two parts: a tier for how much of the framework a cloud meets, and an assessment level for how rigorously that has been verified. Written together they form a single grade - A/2, say - that a buyer can read at a glance.

A tiered rating

The Mark grades a cloud into one of four tiers. The tier is a coarse classification for a procurement comparison; finer ranking within a tier is by operational metrics and market plurality, not by raw item counts.

Tier	Meaning
Tier 1 — Conformant	Passes every MUST and the Sovereignty Test.
Tier 2 — Conformant with exceptions	Passes the cross-cutting MUSTs and the Sovereignty Test; a small number of named MUST exceptions, each with a dated remediation plan.
Tier 3 — Aspirant	Passes the cross-cutting MUSTs; has a published roadmap to Tier 1.
Tier 4 — Non-conformant	Anything below Tier 3, including any cloud claiming a tier without a current public report.

The tier says what a cloud meets. How thoroughly that claim has been checked is a separate axis - the assessment level.

Assessment levels

How much scrutiny stands behind a Mark is graded from A to C, with A the strongest. The level is set by who verified the claim, not by the operator alone.

Assessment level A — Audited technology

The Sovereign Computing Initiative has audited the running technology itself, not only the paperwork. The strongest form of the Mark.

Assessment level B — Audited report

The Initiative has independently reviewed the conformance report and the evidence behind it.

Assessment level C — Self-assessed

The operator has published, dated and signed its own conformance report. Credible, but not independently verified.

Reading the Mark

A Mark is written as level/tier - the assessment level first, then the tier. A/2 is an audited-technology assessment of a Tier 2 cloud; C/1 is a self-assessed Tier 1 claim.

Not every combination is offered. Independent audit is available to clouds that reach Tier 1 or Tier 2; an Aspirant (Tier 3) may only self-assess; and a non-conformant cloud (Tier 4) earns no Mark at all.

Conformance	A — Audited technology	B — Audited report	C — Self-assessed
Tier 1 — Conformant	A/1	B/1	C/1
Tier 2 — With exceptions	A/2	B/2	C/2
Tier 3 — Aspirant	—	—	C/3
Tier 4 — Non-conformant	—	—	—

Evidence

The assessment level grades the report as a whole. Within it, every individual claim is backed by evidence of a stated class:

• Publicly verifiable - a linked, dated public artefact. Acceptable for any item.
• Audit-verified - confirmed by an independent auditor's review of internal systems.
• Declared - self-declared by the operator. Counts only for SHOULDs, never toward Tier 1 or Tier 2 qualification.

Components bound the score

A cloud is a composition of components, and its tier is bounded by the weakest one - with a deliberate exception. A non-conformant component that the customer can substitute through the cloud's documented APIs does not drag the tier down; only a load-bearing, non-conformant component does. The Component Conformance Manifest records which is which.

The procurement comparison

The Mark is designed to drop into a procurement comparison. For each candidate cloud, a buyer can line up:

• the Mark - assessment level and tier - with the last audit date and the auditor
• the number of independent providers at support Levels 1 to 4 - the measure of market plurality
• open MUST exceptions, and the count of load-bearing non-conformant components
• a link to the full conformance report

What the Mark does not measure

Some things cannot honestly be reduced to a rating and need a parallel due-diligence process: the strategic alignment of a cloud's governance with your legal and regulatory environment, the quality of the Level 5 advisory available to you, and the political or ownership exposure of the operator and of each component's maintainer.

The Mark measures openness and replaceability. It does not measure fitness for a specific sovereignty mandate.

Members

The Sovereign Computing Initiative is built by its members - the organisations that help define the category, develop the conformance framework, and offer conformant products and services.

Founding members

We are assembling a founding group of member organisations. Founding members will be announced as the group forms, ahead of the initiative's first public presentation.

If your organisation would like to be among them, get in touch.

What members do

• shape the category definition and the conformance framework
• help develop and govern the Verified Sovereign Computing Mark
• offer conformant infrastructure, integration, support, or hosting across the support levels above
• represent the needs of buyers, providers, and the public interest in the initiative's governance

What membership offers

• a voice in defining a category that procurement teams will use
• early alignment with the conformance framework and the Mark
• a place in the ecosystem that forms around sovereign computing

Becoming a member

Membership is open to organisations that share the goal of making sovereign computing a well-defined, procurable reality. There is no fee to take part at this stage. To express interest, see community.

Where to go next

• Check your own position with the buyer self-assessment or the provider self-assessment.
• Read the full support definitions: every level, the conformance criteria, and the scoring rubric.
• See how this is used in procurement in for buyers, or how to qualify in for providers.