Research area · Cloud & Sovereignty

Cloud sovereignty: from data location to demonstrable control

Who decides whether, where, and under which law your systems run — and your AI? Vami Research translates BSI C5, the C3A sovereignty catalog, the CSA Cloud Controls Matrix, and the Commission proposal for the Cloud & AI Development Act into auditable criteria for provider selection, contracts, and operations. In operations, what counts is context, not a list of findings: prioritization follows real-world exploitability.

BSI C5
BSI C3A
CSA CCM & CAIQ
CNAPP & CSPM
CADA draft
EUCS
Key sovereignty

Schedule an initial consultation View publications

Deep Dives: 6
Whitepapers: 0
Solutions: 1

Context

Sovereignty becomes an auditable requirement

Today, cloud security is less a technology problem than a governance problem. The top three places in the CSA Top Threats 2024 go to misconfiguration and inadequate change control, identity and access management, and insecure interfaces and APIs — all topics within the customer's area of responsibility. According to Microsoft's responsibility matrix, data, endpoints, accounts, and access management remain with the customer in every service model.

At the same time, sovereignty became measurable in 2026. With C3A v1.0, the BSI presented criteria for self-determined cloud use for the first time on April 27, 2026; the revised C5:2026 incorporates technical sovereignty, confidential computing, and post-quantum cryptography. The Cloud & AI Development Act has been available as a Commission proposal since June 3, 2026, and the European certification scheme EUCS has still not been adopted.

We assess cloud deployments along these catalogs and drafts and put the same control question to AI. VamiGRC, VamiAppSec, VamiThreat, VamiRedteam, VamiDAST, VamiReverse, and Vamiset run as SaaS on T Cloud Public, exclusively in German data centers. The language model is selectable — for VamiAppSec, VamiThreat, VamiDAST, and VamiReverse up to the local Qwen3.8 in VamiSec's data center in Sankt Augustin, and in VamiGRC for chat, assistant, and agents. Customer data is not used for AI training.

Research questions

Open questions in practice

01
How can you tell whether a cloud service is sovereign — and not just storing data in the EU?
Our approach
In the CADA draft, data residency covers only the lowest of four levels. We therefore also examine operations and technology: who operates the service, where support comes from, who owns the provider, and who develops the software further. The criteria blocks SOV-1 to SOV-6 of the BSI C3A and the level logic of the CADA draft serve as the framework.
02
How can sovereignty requirements be anchored in procurement procedures without impermissibly restricting competition?
Our approach
For each usage scenario, we select the appropriate C3A criteria and phrase them as verifiable requirements for the service specification and the provider assessment. According to the BSI, restrictions to EU or Germany variants must be justified and legally permissible; we therefore link them to the subject matter of the contract and document them — from data localization, including telemetry, to audit rights.
03
What does a C5 attestation actually prove — and what changes with C5:2026?
Our approach
We check the report type first: Type 1 confirms the design of the controls at a reference date; only Type 2 confirms their effectiveness over an audit period of usually three to twelve months. The revised C5:2026 comprises 168 instead of 121 criteria and is mandatory for attestations with reference dates or audit periods starting on or after June 1, 2027; earlier adoption is permitted.
04
What does sovereignty mean when AI systems and agents come as a service from the cloud?
Our approach
We treat an AI service like any other cloud service and additionally examine the model, inference, and training data: where prompts, outputs, and telemetry are processed, who operates and further develops the model, and whether operational or customer data flows into training. This logic follows the CADA draft, which classifies remotely operated AI systems as cloud services.

Findings

Key takeaways

01
Data location is not proof of sovereignty
Sovereignty is decided by control over the system, not by GDPR compliance alone. The US CLOUD Act allows US authorities to access data held by US-controlled providers regardless of where it is stored. “Data stays in the EU” is therefore not proof — the provider's jurisdiction and control, operations, and key sovereignty belong in every assessment.
Source: Digital Sovereignty
02
C3A makes sovereignty auditable — an attestation procedure is still missing
The BSI catalog C3A v1.0 of April 27, 2026, divides sovereignty into six criteria blocks, from strategic to technological sovereignty, and presupposes the C5 criteria. It is neither a law nor a certificate; the BSI has so far only announced standardized audit processes. Provider claims therefore need to be cross-checked against robust evidence.
Source: BSI C3A
03
A C5 attestation shifts work to the customer instead of removing it
C5 is an attestation, not a seal: independent auditors attest under ISAE 3000 or IDW PS 860, and the result is an audit report that has to be evaluated. It contains corresponding criteria for customers, which the user implements itself. Only those who map them to their own controls and document the implementation can provide evidence for their use of the service.
Source: BSI C5
04
The CADA draft applies the same level logic to AI services as to the cloud
The Cloud & AI Development Act exists as a Commission proposal of June 3, 2026; criteria and deadlines may still change during the legislative process. The draft tiers sovereignty into four Union assurance levels, from level 2 onward with a third-party audit and a ban on using operational data to train third-country AI. It treats remotely operated AI systems as cloud services.
Source: CADA — Cloud & AI Development Act

Methodology

How we work

We combine criteria catalogs, audit reports, and technical telemetry into a single assessment — from the individual workload to the procurement procedure. We label drafts such as CADA and EUCS as drafts.

Three-sovereignty grid

Assess data sovereignty, operational sovereignty, and technology sovereignty per workload — including metadata flows, support paths, and the provider's ownership structure.

Criteria alignment across C5, C3A, and CCM

Consolidate requirements from BSI C5, blocks SOV-1 to SOV-6, and the CSA Cloud Controls Matrix; we use the CAIQ for structured provider assessments.

Evaluating audit reports

Check the report type and audit period, extract the corresponding criteria for customers, and map them to your own controls.

Graph analysis instead of a list of findings

Link misconfigurations, vulnerabilities, identities, and network exposure and make attack paths visible — for example with Wiz; VamiSec is a member of the Wiz Partner Alliance.

Read-only inventory with Vamiset

Vamiset inventories assets in AWS, Azure, and GCP exclusively with read-only permissions and checks them against CIS Benchmarks and controls from frameworks such as ISO 27001 and NIS2 — currently without AI features.

Status monitoring

Continuously track the procedural status of the CADA proposal and the EUCS candidate scheme as well as the transition from C5:2020 to C5:2026.

How to get started

1Classify workloadsClassify workloads by sovereignty criticality and record data categories, protection requirements, contractual situation, and existing evidence.
2Measure and prioritize gapsCompare the current state against C5, C3A, and the levels of the CADA draft, and prioritize gaps by effort, dependency, and contract term.
3Establish and evidence controlImplement key sovereignty, exit plans, and contract clauses, test the exit, and bundle the evidence for an independent audit.

Publications