Methodology

The Cloud Sovereignty Index (CSI) is a structured self-assessment instrument for evaluating the sovereignty posture of cloud services. It supports three distinct, source-faithful assessment modes:

Source traceability: Every question carries a source reference (framework name + clause identifier) linking it to the original control it is derived from. Questions are written to be simple and directly answerable — editorial rewrites of framework legalese — but each one is bullet-proof traceable to its source clause. The source reference is shown below each question in the questionnaire and in the Source columns of the XLSX workbook.

Scope: cloud sovereignty only. Security attestation (ISO 27001, SOC 2, BSI C5:2026) is assumed and not assessed by this instrument. C5 is presupposed, not a CSI source.

Users may select one, two, or all three modes for the same assessment. Results for each mode are completely independent — there is no combined cross-mode score.

For EU/EEA assessments, CSI Composite uses the same 0–4 weakest-link scale and gate as EU-CSF, named CSL (Cloud Sovereignty Level) rather than SEAL (see §3.1).

For non-EU (Generalized) assessments, CSI Composite uses the Sovereignty Ladder model:

No weakest-link gate applies in Generalized mode. A single "no" on a strict EU criterion does not collapse the score. Fallback questions provide alternative routes to partial credit for CSI Composite Generalized assessments. They are CSI Composite-only and appear in the questionnaire only when the parent criterion is answered No — hidden otherwise. Active fallbacks: SOV-4-01-FB (personnel residency), SOV-4-03-FB (multi-homed BGP connectivity), SOV-4-09-FB (disconnect tabletop exercise), SOV-6-01-FB1 (local build capability), SOV-6-01-FB2 (documented exit and tested data export).

The CSI question catalog is fully transparent about the relationship between each criterion and its source framework. EU-CSF v1.2.1 (§4) defines contributing factors — high-level principles per sovereignty objective — but does not specify assessment questions. Any tool based on EU-CSF must operationalize those factors into testable criteria; CSI documents every such design choice. BSI C3A v1.0, by contrast, defines explicit MUST/SHOULD requirements that are used verbatim or minimally paraphrased.

Every criterion carries one of three fidelity labels, visible as a coloured chip in the questionnaire interface below each question:

• Direct The question text is verbatim or minimally paraphrased from a named criterion or contributing factor in the source document. No substantive editorial judgment was required.
• Inferred The question operationalizes the intent of a source contributing factor, but the source document does not specify a testable criterion at this level of detail. CSI had to make a design choice to bridge the gap between a principle and a measurable control. The specific contributing factor and the reason for the derivation are documented inline in the questionnaire (tap the amber ▾ badge on any Inferred question to expand the rationale) and in the Decisions Register.
• CSI An editorial addition not present in either source framework. Used for LMIC fallback questions, AI-sovereignty criteria, and Generalized-variant adaptations where neither EU-CSF nor C3A provides a control but the underlying sovereignty objective still applies.

Attribution breakdown — instrument v2.2

No Inferred criterion changes the scoring formula of its source framework. Inference applies only to the question design — the SEAL gate logic, the weights, and the pass/fail rules are all faithful to source. All derivation decisions are recorded in the Decisions Register (DR-E25 through DR-E29).

BSI C3A defines criteria at two levels: bloc-level (EU) and national-level (Germany in the source document). The national tier is a strictly higher bar than the bloc tier — it applies to a specific member state rather than the EU as a whole.

Nesting rule: National tier ⊆ Bloc tier. A cloud provider that satisfies the national-level requirement automatically satisfies the bloc-level requirement. The reverse is not true.

Questionnaire flow for EU/EEA assessments with a country selected (EU-CSF and CSI Composite):

1. The national tier question is shown first.
2. If the answer is Yes → the EU-level requirement is auto-satisfied.
3. If the answer is No, Partial, or N/A → the EU-level (bloc) fallback question is shown.

In C3A mode, each tier is an independent criterion — national and bloc tiers are scored separately with no auto-satisfaction. This is faithful to the C3A source (which lists national and EU variants as distinct requirements).

Text substitution: Geographic placeholders are resolved at render time. {{COUNTRY}} → selected member state name. {{BLOC}} → "EU" (EU-CSF) or country name (Generalized). {{NATIONAL_ADMIN}} and {{EMERGENCY_REGIME}} → country-specific values.

For a non-EU (Generalized) assessment these adaptations are applied identically in the questionnaire and in the result/report: a question carrying a Generalized variant is shown — and scored — with its adapted, jurisdiction-neutral wording in both places, and a criterion that is EU-industrial-policy-only is excluded from both. The on-screen report, the PDF, and the exported risk register never fall back to the EU-native phrasing for a non-EU country.

All adaptations are documented in the Decisions Register.

The control matrix uses a six-layer model (L1–L6) that maps to established cloud architecture frameworks. No other sovereignty framework splits exactly at L3/L4 or elevates Operations to L5 — both are sovereignty-specific distinctions justified by EU law. Do not conflate this with a generic NIST stack.

CSI presupposes that the security baseline (BSI C5:2026 or equivalent) is met. The control matrix does not re-assess security controls; it assesses sovereignty governance on top of a security foundation. The layered model is used in the scoping flow (scenario picker → refine → readback) to derive a control profile — who owns, operates, and supports each layer — which determines which risk predicates and procurement bridges are relevant for the assessment.

Archetype-driven relevance

A question is relevant to your assessment based on the facet of a layer it interrogates, never on a scenario label. Each layer has four facets — ownership, operation, dependency, location — with a sovereign baseline (client-owned, client-operated, self-supported open source, in-country). Any deviation is a risk surface, and each question is tagged to one or more archetypes that fire on a specific facet deviation:

The decisive distinction: ownership, operation, and location questions are ruled out when you control that facet — but reversibility questions are not. You can own and operate a platform and still be unable to patch a zero-day because the software is licensed. So a third-party-owned facility is treated as a physical custodian (landlord), not a cloud provider, and its data-residency / service questions vanish when you own the data layers — while reversibility questions follow the software dependency, independent of who owns the kit.

Hidden questions never hide a risk. When a question vanishes because it is out of scope, the questionnaire checks whether a structural sovereignty risk it maps to is still live for your declared profile. If so, that risk is recorded as a read-only finding with a locked score and its source-anchored rationale — never dropped. These findings are consolidated into a single “Structural findings from your scope” summary on the review page (one entry per risk, even when it spans several objectives), rather than repeated inline page by page. Only questions with no live risk for that facet (for example, jurisdiction questions hidden because the layer is in-country) fall away quietly. An invariant test guarantees that, across the reference deployment scenarios, no fired structural risk can become invisible.

Domain maturity radar. The result page plots an eight-axis radar of per-domain maturity across the SOV-1…SOV-8 objectives, complementing the single headline score and the per-layer control posture. Axes with no answered questions are drawn dashed and are not scored.

Profile-determined questions are answered for you. Some questions ask a fact your declared infrastructure already fixes — whether the provider is under your jurisdiction, whether data is resident in-country, where operating staff sit. Putting these to you is needless friction (and, for a self-operated deployment, would ask about "the provider" when there is none). They are instead derived from your control profile, answered automatically, and listed in full on the review page ("Answers set by your declared infrastructure") with the reason for each and an override control. These derived answers count toward your score exactly like a typed answer — so a foreign provider cannot raise its score simply by not being asked the questions it would fail, and an in-country deployment is credited for the residency it genuinely has. Only pure facts are derived this way; anything that depends on a provider's offering, a process, or a commitment (key management, client-side encryption, audit cooperation, exit drills) is always asked.

Every amendment is auditable. Where this tool re-words a source criterion to fit your context, each question carries a collapsible "Original source wording" revealing the verbatim source sentence beneath its source reference.

The CSI headline is weakest-link gated. The CSI Composite reports two numbers: a readiness % (weighted coverage of what you've implemented) and a maturity tier (Dependent → Sovereign). The tier is gated by the weakest sovereignty domain: a domain at the lowest assurance level (CSL 0–1) caps the headline, so a high coverage % cannot read "Strategic Autonomy" while a domain is still "Dependent". The result page lists those blocking objectives — raising them is what lifts the gate. SOV-8 (environmental/ESG) is excluded from the gate, as it does not bear on sovereignty attainment. CSI levels are reported as CSL (Cloud Sovereignty Level), never SEAL — SEAL is an EU-CSF concept.