BSI C3A: When is a cloud truly sovereign?

"Sovereign cloud" used to be mostly a marketing term. Since 27 April 2026 it is measurable: Germany's Federal Office for Information Security (BSI) published the criteria catalogue C3A — "Criteria enabling Cloud Computing Autonomy" in version 1.0 (BSI press release). For the first time it provides a verifiable yardstick for when a cloud service can genuinely be used in a self-determined way — and it coins a new term that captures the whole debate: Cyber Dominance.

The timing is no coincidence. A few weeks later, on 3 June 2026, the European Commission unveiled its Tech Sovereignty Package — including the proposed Cloud and AI Development Act (CADA), which aims to move sovereignty from rhetoric into procurement practice. In 2026, sovereignty is no longer a matter of attitude but a requirement in tenders.

"Cyber Dominance": why sovereignty must now become measurable

The BSI defines Cyber Dominance as the ability of manufacturers of digital products to permanently retain access to their customers' systems and data. It frames it as the third threat dimension alongside Cyber Crime and Cyber Conflict. The difference is fundamental: here the risk is not the outside attacker, but the legitimate provider itself — through updates, remote maintenance, telemetry, model APIs, and the access powers of its home jurisdiction.

This quiet dependency cannot be disproven with glossy terms like "sovereign cloud" — only with criteria. And that is what C3A delivers.

What is the C3A criteria catalogue?

C3A translates the EU Cloud Sovereignty Framework into verifiable criteria, making it demonstrable for the first time how self-determined the use of a cloud service really is. It answers a different question from the established security catalogues: C5 checks whether a service is operated securely — C3A checks whether it can be used autonomously. The two complement each other; C3A explicitly presupposes that the C5 criteria are met.

A key point: C3A is a "guiding framework" that creates transparency but "has no regulatory effect" — i.e. it is not a law. It becomes binding wherever companies and public bodies make it a requirement. The version published on 27 April is English (v1.0); the German version is announced for the end of Q2 2026.

The six dimensions of cloud sovereignty

C3A breaks sovereignty into six dimensions (SOV-1 to SOV-6). Each is decomposed into concrete criteria and additional criteria, so providers can evidence them and customers can demand them.

(Security — SOV-7 — is deliberately left to the C5:2026 catalogue, and sustainability — SOV-8 — sits outside the BSI's remit.) More on our security and data-sovereignty model on the Security & data sovereignty page.

Data residency is not data sovereignty

This is where the most popular sovereignty promise breaks. A data location in the EU says nothing about who can legally compel access. The US CLOUD Act (2018) obliges US providers to produce data they control — regardless of where the servers sit, including in European data centers.

How real this is became clear before the French Senate on 10 June 2025: Microsoft France's Director of Public and Legal Affairs, Anton Carniaux, was asked whether he could guarantee that French citizens' data would never be handed to US authorities without their consent. His answer: "Non, je ne peux pas le garantir" — no, he could not guarantee it (report).

This is not a criticism of individual providers. Even serious offerings such as the AWS European Sovereign Cloud (available since 15 January 2026, with a first region in Brandenburg and EU operations) substantially reduce the risk — but they themselves claim no immunity from the CLOUD Act. Sovereignty is a spectrum:

Data residency (where data sits) < operational autonomy (who runs it) < legal immunity (who can compel access). Only at the end of that scale is there true sovereignty.

Sovereign AI: the blind spot of the sovereign cloud

This is exactly where AI enters — as the most overlooked point. An AI is only as sovereign as the infrastructure its models run on. Even on a perfectly sovereign cloud, an AI remains externally controlled if its answers are produced through an external model API that sits in a foreign jurisdiction, can be switched off or repriced at any time, and logs your inputs.

Hold the six C3A dimensions up to an AI solution and a cloud-based model API immediately fails SOV-2 (jurisdiction), SOV-3 (data) and SOV-4 (operations). Why even the strongest model alone is not a sovereign solution, we covered in detail using Anthropic's Fable 5: Fable 5 is here — and why the strongest AI model alone isn't enough.

What C3A means for your AI strategy

The good news: a locally operated, managed AI stack satisfies the C3A logic essentially by design. When the language models run on your hardware, there is no outbound connection, and operations are in local hands, SOV-2, SOV-3 and SOV-4 are not merely "addressed" but structurally met. Swappable open-weight models serve SOV-5 and SOV-6, because you are not tied to a single proprietary API. That is exactly how Lokalaise is built: a permission-aware knowledge layer and AI agents that work solely on your own documents and your own hardware.

What decision-makers should do now

Use C3A as what it wants to be: a checklist. Before procuring any cloud or AI solution, ask one question per dimension:

1. Jurisdiction (SOV-2): Which law governs the provider — and can a foreign government compel access?
2. Data (SOV-3): Do sensitive documents leave your company, and who holds the keys?
3. Operations (SOV-4): Who can remotely maintain, update or read along — and is that contractually and technically excluded?
4. Technology & supply chain (SOV-5/6): Can you swap models and components without rebuilding everything?

If any of these gives you pause, it's worth doing the math. In a short demo we'll show you what a C3A-aligned, locally operated AI stack looks like in your company.