Reboot Germany

BSI C3A: Cloud Sovereignty Becomes Auditable

Cloud Magazine explains the BSI-C3A catalog for sovereign clouds. It shows architects how to spot sovereignty-washing and select providers based on six…

By Alec Chizhik July 11, 2026 4 min read

BSI C3A: Cloud Sovereignty Becomes Auditable

The BSI introduced a verifiable framework for cloud sovereignty in April 2026 with the C3A catalogue. This turns a marketing buzzword into a requirement that can be written into tenders. For architects in the DACH mid-market, this is a turning point: sovereignty can now be queried like any other technical property.

Key Takeaways

C3A complements C5: While the established C5 catalogue assesses information security, C3A evaluates digital sovereignty. C5 compliance is a prerequisite; C3A builds on it.
Six incremental domains: From SOV-1 to SOV-6 with basic and advanced criteria. The higher the level, the greater the customer’s control over data and operations.
A tool against sovereignty-washing: Writing C3A into a tender forces providers to give verifiable statements instead of empty marketing promises.

What C3A Assesses Beyond C5

The BSI’s C5 catalogue has long been the benchmark for cloud-service security. It answers whether a provider operates cleanly and transparently. What it does not answer is the question of control: can the customer steer its data and processes independently of the provider, even if the relationship sours?

C3A-short for Criteria enabling Cloud Computing Autonomy-closes this gap. The catalogue evaluates whether a cloud offering can be used self-determinedly within the respective risk context. In practice, C3A assumes C5 compliance. A provider that fails the security requirements is not even considered for the sovereignty assessment. The German-language version is slated for release in Q2 2026.

Six Domains from SOV-1 to SOV-6

The BSI structures sovereignty into six domains, SOV-1 through SOV-6, each building on the last. Every domain contains basic criteria and advanced requirements, labelled C and AC in the catalogue. This creates a maturity model in which an offering reaches a defined level of autonomy, from the base domain to the highest tier.

For architects, this gradation is the real advance. It enables risk-based decisions. A non-critical dev workload may not need the top tier, whereas a process handling highly sensitive data certainly does. The domain structure forces an honest assessment of the sovereignty level a given use case truly demands.

How Providers Can Be Benchmarked

The real value of C3A emerges when applied to real offerings. A purely European-operated stack from a provider without a non-EU parent company will reach different domains than a sovereign zone technically isolated by a US hyperscaler whose operator remains subject to non-EU law. Both can be legitimate. C3A makes the difference visible instead of burying it in fine print.

For procurement, the question is no longer whether a provider uses the word “sovereign” in its data sheet. It is which C3A domain the provider demonstrably achieves-and whether that level matches the workload’s protection needs.

The Autonomy Question: Operations Without the Provider

The toughest test of sovereignty is a thought experiment with real-world implications. What happens if the provider fails, terminates the contract, or is legally blocked? Can the customer maintain operations or migrate without starting from scratch? The higher C3A domains specifically address this autonomy: key sovereignty, data portability, and operational independence.

In practice, autonomy rarely fails due to technology and often due to formats and contracts. Embedding proprietary data formats and exclusive managed services deep into your own architecture erodes sovereignty, no matter what the certificate claims. C3A provides the language to identify such dependencies early.

Checklist for Architects Before Tendering

Three steps make C3A actionable within your own organization. First: define the protection requirements for each workload class and derive the required sovereignty domain. Second: include the domain as a hard criterion in the tender and demand evidence-not just a self-declaration. Third: plan the exit from the outset by contractually securing data formats, key sovereignty, and migration paths.

Providers who invest early in C3A audits gain an edge in precisely those regulated tenders that will increase in 2026. For procurement, the catalog serves as a filter; for providers, it’s an entry ticket.

Frequently Asked Questions

What’s the difference between BSI C5 and C3A?

C5 assesses the information security of a cloud service. C3A adds digital sovereignty-the customer’s ability to control data and processes independently of the provider. C5 compliance is a prerequisite for a C3A assessment.

What do domains SOV-1 through SOV-6 mean?

BSI structures cloud sovereignty into six progressive domains. Each has basic and advanced criteria. The higher the domain achieved, the greater the customer’s control over data, keys, and operations.

Is C3A mandatory?

C3A is initially a criteria catalog, not a legal obligation. Its impact arises through procurement: once public and regulated buyers require C3A domains in tenders, the catalog effectively becomes the benchmark.

Can a US hyperscaler achieve a C3A domain?

In principle, yes-depending on the specific operating model. What matters is which control over keys, operations, and legal frameworks actually resides with the customer or an EU operator. The achievable domain varies significantly by design.

When will the German version be available?

BSI released the C3A catalog in April 2026. The German-language version is slated for the end of Q2 2026. Until then, the published structure can already be used to prepare your own procurement.