Frequently Asked Questions

What is the Cloud Sovereignty Index?

It is a structured self-assessment instrument that lets organisations evaluate how well a cloud service supports their digital sovereignty goals. You answer a set of questions about a cloud provider or deployment, and the tool produces a weighted score from 0–100% and a result level — a 0–4 assurance level (SEAL for EU-CSF, CSL for CSI Composite) for EU/EEA assessments, or a Progressive Sovereignty Maturity tier (Dependent, Managed Dependency, Strategic Autonomy, Sovereign) for non-EU assessments.

Why does this tool exist?

Cloud sovereignty is increasingly relevant for public administrations, regulated industries, and any organisation that needs to retain meaningful control over its data and operations in the cloud. Existing frameworks (BSI C5, EU-CSF) are technically sound but require significant expertise to apply. This tool makes those criteria accessible as an interactive questionnaire with plain-language questions and immediate scoring.

Is this a certification or a legal opinion?

No. This is a self-assessment instrument, not a certification. Per the BSI C3A §1.1: "The C3A Framework is not binding in itself." The score is indicative only and depends entirely on the accuracy and honesty of the answers provided. The result carries no legal weight and should not be treated as a substitute for formal audit, legal advice, or procurement due diligence.

Are you affiliated with BSI, the European Commission, or any standards body?

No. The Cloud Sovereignty Index is an independent project. We are not affiliated with the German Federal Office for Information Security (BSI), the European Commission, ENISA, or any other standards body. We reference and apply their published frameworks — specifically BSI Criteria Enabling Cloud Computing Autonomy (C3A) v1.0 and EU Cloud Sovereignty Framework v1.2.1 — but we do not speak on their behalf. See the Methodology page for a full list of source documents.

Who is this tool designed for?

The instrument is designed to be used by anyone who needs to evaluate a cloud service's sovereignty posture:

• Cloud customers (public administrations, enterprises, NGOs) assessing a provider or a planned procurement.
• Cloud providers doing a self-assessment of their own offering before a customer engagement.
• Auditors and consultants producing a third-party assessment of a deployment on behalf of a client.
• Researchers and policymakers comparing sovereignty postures across providers or jurisdictions using the public corpus.

Does the service model (IaaS, PaaS, SaaS…) change anything in the assessment?

From a sovereignty scoring perspective: no. The same set of criteria and the same scoring logic applies regardless of whether you are assessing an IaaS, PaaS, or SaaS service. The BSI C3A and EU-CSF criteria were written to be applicable across service models — sovereignty properties such as jurisdiction of data storage, legal access by third parties, or portability are relevant for all of them.

In practice, different service models place different responsibilities on the customer vs. the provider. An IaaS customer controls the software stack; a SaaS customer does not. Some questions may therefore be more or less applicable in practice — use N/A where a criterion genuinely does not apply to the deployment you are assessing.

Can I fill in the questionnaire offline or share it with my cloud provider?

Yes. Download the blank Excel template (.xlsx) and send it to your cloud service provider (CSP). The CSP fills in their answers and returns the file; you upload it on the setup page to generate a scored result instantly. Nothing is submitted until you review and confirm.

What does the template contain?

The template has three visible sheets:

• Setup — variant selection (EU/EEA or non-EU), country, and optional company name.
• Assessment — all criteria for both EU/EEA and non-EU variants in a single merged sheet. The "tier" column identifies each row (eu_csf, generalized, bloc, national, or single).
• Privacy — what data is and is not collected by this tool.

The Assessment sheet has 14 columns; 4 are hidden metadata used by the import parser. The visible columns the CSP interacts with are:

• question_id, tier, objective, title, text — locked, pre-filled by CSI. Identify and describe the criterion.
• evidence_expected — locked, pre-filled by CSI. Describes exactly what evidence should be provided: document type, required fields, and where to find it.
• evidence_provided — free text, filled by the CSP. Document name, URL, contract clause reference, attestation ID, or page number. "none available" is acceptable.
• evidence_type — dropdown, filled by the CSP: Audit report / certification, Contract clause, Public documentation, Provider statement, or Verbal / none.
• answer — dropdown (yes / no / partial / planned / n/a), filled by the CSP. See "What do the answer options mean?" below.
• guidance — read-only contextual notes on how to interpret a criterion. Provided selectively for questions that are commonly misunderstood or require regulatory context; not every row includes it.

Why does the template ask for evidence references, not just answers?

A "Yes" answer with no supporting reference is a claim, not evidence. The evidence columns turn the template into an audit-ready document that records what was claimed and where it can be verified. This matters in three scenarios:

• Procurement due diligence. If a procurement decision is challenged, the completed template shows not only the score but the specific documents that supported each answer. Reviewers can verify references without re-running the assessment.
• Audit support. Internal or external auditors can spot-check answers against cited evidence (certificates, DPA clauses, SOC 2 sections) without needing to interview the provider again. BSI C3A §1.1 requires that criteria be verifiable — the evidence column is the mechanism that makes this possible in practice.
• Provider accountability. A CSP that provides document references is making a traceable commitment. If a cited certificate expires or a contract clause is later amended, the discrepancy becomes visible. This creates a higher bar than an uncorroborated self-declaration.

The evidence columns do not affect the score — a "Yes" backed only by a provider statement scores the same as a "Yes" backed by a BSI C5 attestation. The scoring engine deliberately does not penalise evidence quality, leaving that judgment to the assessor. What the columns provide is a paper trail that makes the assessment defensible.

Why would I send this to my CSP rather than filling it in myself?

Many criteria ask about internal provider controls that you as a customer cannot verify directly: personnel jurisdiction policies, disconnect test results, SBOM availability, source code backup frequency. The CSP is the only party who can accurately answer these — and who can attach the document references that make those answers credible. Sending the template to the provider's compliance or pre-sales team and asking them to complete it with evidence references is the most defensible approach, and creates a natural checkpoint in your procurement or vendor review process.

What do the answer options mean?

Planned requires evidence: a board-approved roadmap with a named milestone and target date, a signed project plan, an approved budget line, or a vendor contract with delivery date. A "Planned" without a traceable artefact should be treated as No in any external review.

What are the result levels?

The result level depends on your assessment variant:

• EU/EEA assessments: output is a 0–4 assurance level — a SEAL (Sovereignty Effectiveness Assurance Level, defined in EU-CSF §3) for EU-CSF, and the equivalent CSL (Cloud Sovereignty Level) for CSI Composite EU/EEA. 0 = No Sovereignty, 1 = Jurisdictional Sovereignty, 2 = Data Sovereignty, 3 = Digital Resilience, 4 = Full Digital Sovereignty. The level is computed with a weakest-link gate: each criterion carries a contribution level (1–4); the objective level is the highest L where every criterion with contribution ≤ L is answered Yes. A single failed criterion at level 1 drops the objective to level 0. The overall level is the minimum across all objectives.
• Non-EU assessments (CSI Composite Generalized): output is a Progressive Sovereignty Maturity tier — Dependent (0–40%), Managed Dependency (41–70%), Strategic Autonomy (71–90%), or Sovereign (91–100%) — derived from the weighted percentage score, then gated by the weakest sovereignty domain (the headline tier cannot exceed your weakest domain's CSL). There is no weakest-link gate: a single No on a strict EU criterion does not collapse the result.
• C3A: no level. Output is a binary pass/fail percentage (criteria met / applicable).

Why is my overall score high but my assurance level low?

This applies to EU-CSF (SEAL) and EU/EEA CSI Composite (CSL) assessments. The percentage score and the assurance level measure different things. The score is a weighted average of how many points you earned across all questions — partial answers count toward it. The assurance level is a strict threshold: a single No or Partial on a foundational criterion (contribution level 1) drops the objective to level 0, regardless of how well you scored on everything else. This is intentional — the level is designed to identify the most critical sovereignty gaps, not be averaged away.

For non-EU assessments (CSI Composite Generalized), there is no per-criterion weakest-link gate, but the headline maturity tier (Dependent, Managed Dependency, Strategic Autonomy, Sovereign) is still capped by your weakest sovereignty domain — so a high percentage will not read "Strategic Autonomy" while one domain remains "Dependent".

Does this tool assess security?

No. Security and sovereignty are complementary but distinct dimensions.

• Security asks: "Is the data protected against unauthorised access?" This is addressed by certifications like ISO 27001, SOC 2 Type II, and BSI C5:2026. The Cloud Sovereignty Index presupposes that the cloud provider already meets a recognised security baseline and does not reassess encryption, access controls, or vulnerability management.
• Digital sovereignty asks: "Does the organisation retain independent control over its data and services, including the ability to operate, audit, and if necessary migrate or disconnect, regardless of external dependencies?" A provider can hold strong security certifications while having structural dependencies — in jurisdiction, ownership, supply chain, or staffing — that limit the customer's independent governance. Sovereignty addresses those structural properties.

This scope boundary comes from the frameworks themselves. BSI C3A §1.2 states: "C3A presupposes that the cloud service provider meets the C5 criteria, as they reflect the security aspect of the sovereignty definition." The same document explains: "SOV-7 Security & Compliance Sovereignty is already covered by established BSI publications like C5:2026, IT-Grundschutz or the HA Benchmark compact."

Note on security attestations: A current BSI C5:2026 attestation is useful evidence for several CSI criteria (secure configuration, multi-tenancy isolation, supply-chain monitoring). But C5 does not cover sovereignty criteria such as data jurisdiction, staffing location, or disconnect capability — those require separate assessment here.

Use this tool alongside security attestations, not instead of them.

Does this tool assess whether I can exit my cloud provider?

Yes — substantially, across both dimensions of reversibility.

Provider-side operational independence. Whether the provider can keep operating if external connections or vendors are severed: SOV-4-09/10 (Disconnect/Reconnect, CSL 3), SOV-6-01 (source code and build toolchain held locally, CSL 4 — the highest single contribution in the framework), and SOV-6-02/03 (contingency strategies and internal engineering capability).

Customer-side exit & portability. Whether you retain the technical and contractual means to leave with your data intact: tested data export in open, documented formats (SOV-6 exit/portability), standards-based API and data-plane portability conformance (e.g. OpenStack Powered / RefStack), switching, notice, transitional and data-retrieval periods plus verifiable erasure (CADA Art. 25 / CADA verifiable-erasure), notice and a no-penalty termination right on material licensing-model changes (SWIPO TR05), and customer-held keys / client-side encryption (SOV-3-04/07) and open-standard identity (SOV-3-05 + AC1/2/3).

What it does not do: it does not audit your signed contract or negotiate terms on your behalf. It measures whether the provider has built the controls that make exit possible, and your report includes a Recommended Contract Clauses section listing the procurement clauses to require — but confirming your executed agreement actually reflects them (and any exit fees specific to your deal) remains your job.

See the Methodology page for the full criteria mapping and procurement complement checklist.

What is the difference between EU-CSF, C3A, and CSI Composite?

Three independent frameworks are available. Each produces a completely separate result — no combined cross-framework score is calculated.

• EU Cloud Sovereignty Framework (EU-CSF) v1.2.1 — Published by the European Commission. Covers all 8 sovereignty objectives (SOV-1 through SOV-8). Output is a SEAL level (0–4) using a strict weakest-link gate: a single unanswered foundational criterion collapses the objective to level 0. Designed for EU cloud procurement compliance. Partial answers earn half points but do not satisfy the gate.
• BSI C3A v1.0 — Published by Germany's Federal Office for Information Security. Covers SOV-1 through SOV-6 only (no security or sustainability objectives). Output is a binary pass/fail percentage — no SEAL or maturity tier. Criteria are strict: Partial counts as not-met. Some criteria are "Additional Criteria" that customers select before the assessment. Designed for EU government procurement, particularly for sovereign cloud in Germany and EU public administration.
• CSI Composite (editorial framework) — An editorial blend of EU-CSF and C3A adapted for global use. See the next two questions for detail.

For scoring formulas, level definitions, and objective weights, see the Methodology page.

What is the CSI Composite and why does it exist?

EU-CSF and C3A were designed for EU procurement. Applied to non-EU cloud providers, their strict weakest-link gate creates a cliff effect: a single "No" on an EU-specific criterion (e.g. "all staff must be EU citizens") collapses the entire score to level 0 — even if the provider has strong controls everywhere else. For a Korean, Singaporean, or Ugandan CSP, this produces a misleadingly low score that obscures real progress.

CSI Composite solves this with two variants:

• EU/EEA variant: Same 0–4 weakest-link model as EU-CSF, expressed as CSL (Cloud Sovereignty Level) rather than SEAL. Suitable for EU procurement comparison.
• Generalized (non-EU) variant: Replaces the per-criterion weakest-link gate with a Progressive Sovereignty Maturity model. Score is a weighted percentage mapped to four tiers — Dependent (0–40%), Managed Dependency (41–70%), Strategic Autonomy (71–90%), Sovereign (91–100%) — then capped by the weakest sovereignty domain. This rewards genuine progress without penalising providers for failing EU-specific staffing or legal requirements that don't apply in their jurisdiction.

CSI Composite is an editorial framework — it is not published by BSI or the European Commission and does not constitute EU-CSF or C3A certification.

Which framework should I use?

• EU/EEA public procurement: EU-CSF (for regulatory language) + C3A (for technical depth). Both are source-faithful to their published standards.
• Global vendor comparison or progress tracking: CSI Composite (Generalized). Shows where a non-EU provider stands against EU sovereignty expectations without the cliff-effect penalty.
• German federal procurement specifically: C3A is the authoritative standard. Add EU-CSF for broader context.
• UK providers targeting EU contracts: Run EU-CSF explicitly. UK assessments default to CSI Composite Generalized since UK law is not EU law.
• All three together: Fully supported. Each framework result is reported independently.

What are fallback questions and when do they appear?

Two CSI Composite-only fallback questions exist for criteria that are structurally impossible to satisfy in a non-EU context:

• SOV-4-01-FB — "Operating Personnel — Security-Cleared Local Residents." Appears only if SOV-4-01 (EU/EEA citizen staffing) is answered No. Provides partial credit when the provider ensures staff hold national security clearances and are bound by local confidentiality law instead.
• SOV-4-09-FB — "Disconnect / Reconnect — Documented Plan and Annual Exercise." Appears only if SOV-4-09 (proven disconnect capability) is answered No. Provides partial credit when the provider has a documented procedure with evidence of at least one annual tabletop exercise.

Fallback questions are hidden in the questionnaire unless the parent criterion is answered No. They do not appear for EU/EEA assessments or in EU-CSF / C3A frameworks.

Why does the source material reference Germany?

The BSI C3A criteria were developed by Germany's federal cybersecurity authority (BSI) and were written with German public administration as the reference context. This means some criteria — such as "data must be stored within a specific jurisdiction" or "the provider must be registered under national law" — originally referred to German territory or German law.

This tool systematically replaces those references with geographic placeholders ({{COUNTRY}}, {{BLOC}}, etc.) that are resolved at assessment time based on the country you select. So when you run an assessment for France, the questions will read "…stored in France" and "…registered under French law." This substitution is a simulation of how the criteria would apply — national legislation and administrative structures will differ. The Decisions Register documents every such adaptation.

What is the difference between the EU/EEA and non-EU (Generalized) variants?

The EU/EEA variant uses EU-CSF as its primary lens. Questions reference the EU as the bloc-level jurisdiction. When you select a specific EU or EEA member state (e.g. France), a second tier of stricter national-level questions also appears — for example, "data stored in France" (national tier) in addition to "data stored in the EU" (bloc tier). The output is a CSL level with weakest-link gate.

The Generalized (non-EU) variant adapts the same criteria for any country outside the EU/EEA. The "bloc" level references your selected country's jurisdiction instead of the EU. Only country-level questions appear — there is no national sub-tier. The output is a Progressive Sovereignty Maturity tier (no per-criterion weakest-link gate, though the headline tier is still capped by your weakest sovereignty domain), which avoids penalising providers for failing EU-specific requirements that don't apply in their jurisdiction.

Both variants use the same merged Assessment sheet in the Excel template — the "tier" column on each row identifies whether a question applies to the EU/EEA context, the Generalized context, or both.

How accurate is the country-level adaptation for non-EU countries?

The geographic substitution is a best-effort adaptation. The underlying criteria were written for the EU regulatory environment. Concepts like "supervisory authority" or "emergency regime" map directly to most legal systems, but details of national law will differ significantly. For non-EU countries, treat the score as a directional indicator of how a cloud provider would fare under equivalent criteria, not as a precise regulatory compliance measurement. Country-specific legal review is always needed for compliance decisions.

If I select France (EU), which questions appear?

For each tiered criterion, you first see the France-specific (national tier) question. If you answer Yes, the EU-level requirement is automatically satisfied and no further question is shown for that criterion. If you answer No, Partial, or N/A, the EU-level fallback question appears immediately below, so you can still satisfy the EU-level requirement even if you cannot meet the stricter France-level bar.

What data do you store?

We store your answers, the assessment metadata you provided (variant, country, service model, role), and the optional company name. All of this is stored under a random 128-bit UUID that you receive in the URL. That URL is the only access control — anyone who has it can read and modify the assessment.

We do not collect email addresses, IP addresses, browser fingerprints, or cookies. See the full Privacy page for details.

How long is the data kept?

Assessments that have not been accessed for 12 months are permanently deleted. There is no account, no login, no recovery path — if you lose the URL, the data is inaccessible. Save your URL or export a copy of your answers from the result page.

What is the public corpus?

When submitting an assessment, you can opt in to share an anonymised version of your results with the public corpus. If you do, we publish: your score, result level (SEAL, CSL, or maturity tier), variant, country, service model, role, and the month/year of submission (not the exact date). Company name is never included. The corpus is browsable at /corpus and is intended for researchers and policymakers studying aggregate cloud sovereignty postures.

Can I audit your privacy claims?

Yes. The backend Workers code that handles data storage and the scoring engine are published as open source. You can verify that we do not log IPs, do not set cookies, and that the anonymisation applied to corpus entries matches what we describe. Link on the Privacy page.