Cloud Sovereignty: C5, Data Residency, Key Sovereignty

8 min. read

Sovereignty appears in nearly every cloud procurement process, yet it remains frustratingly vague. Vendors print the term on spec sheets; in proposals it quickly becomes a compliance checkbox. At the architecture level, it breaks down into three concrete questions: Where does the data reside, who operates the platform, and who holds the keys? Only those answers determine whether a cloud setup is genuinely sovereign – or merely labeled as such.

Key Takeaways

• Sovereignty requires architectural decisions: It breaks down into data residency, operational control, and key control. Checking only the data location means overlooking two of the three layers.
• BSI C5 is the benchmark, not a residency promise: The criteria catalogue audits the security of a cloud service, but says nothing about where data is stored. Both questions must be addressed separately.
• C5:2026 raises the bar: 168 criteria instead of 121, with new requirements for containers, post-quantum cryptography, and confidential computing. The demands reach deeper into existing architectures than before.

Related:AI Sovereignty Starts with Infrastructure  /  Sovereign – but from what, exactly?

Sovereignty Requires Architectural Decisions

What is BSI C5? C5, short for Cloud Computing Compliance Criteria Catalogue, is a criteria framework published by Germany’s Federal Office for Information Security (BSI). It defines minimum information security requirements for cloud services and is audited by certified public accountants. A C5 attestation confirms that a provider has implemented verified security measures. In Germany, it is the de facto standard for credible cloud procurement.

The most common mistake starts with a mix-up. A C5 attestation in a proposal gets read as proof of sovereignty. It is not. C5 audits how securely a service is operated – not where the data is stored or who is permitted to access it in an emergency. A provider can hold a C5 attestation and still fall under a legal jurisdiction that allows access to European data. The two questions are related, but they are not the same.

Rigorously assessing sovereignty means breaking it into its components. Only once it is clear which of the three layers a project actually requires can you evaluate whether a given offer fits. Many sovereignty promises fail not because of technology, but because of this missing distinction.

Data Residency, Operational Control, Key Sovereignty: Three Layers

The first layer is data residency – the question of physical location. It is the easiest to verify, which is why it is often conflated with sovereignty as a whole. Data stored in a Frankfurt data center is a good start, but it answers only the simplest of the three questions.

The second layer is operational control: who administers the platform, from where, and under which legal jurisdiction does that personnel operate. A data center located within the EU but remotely administered from a third country has data residency – but not operational control. The third and most demanding layer is key sovereignty. Whoever holds the encryption keys controls the data, regardless of where it physically resides. If the provider holds the keys, residency becomes secondary.

In practice, not every project requires all three layers to the same degree. A public-facing website is perfectly suited to a standard cloud setup. A patient record or engineering dataset demands key sovereignty and operational control – not merely an EU-based location. The architectural task here is to assign each data asset the appropriate tier, rather than blanket-mandating sovereignty or defaulting to a standard cloud across the board.

What C5:2026 Means for Architecture in Practice

The criteria catalog has been substantially expanded. The edition published in April 2026 raises the bar considerably: what was 121 criteria in the previous version has grown to 168. The new requirements target core areas of modern cloud architecture.

Three new focus areas are directly relevant to architects. Container management is examined as a standalone domain for the first time – a change that immediately affects teams running Kubernetes platforms. Post-quantum cryptography is now included, because the threat posed by future quantum computers already requires lead time in today’s architectural decisions. Confidential computing – encrypting data even while it is being processed – receives considerably greater scrutiny under the new framework. The updated requirements become binding for audit periods beginning mid-2027, which means the planning window for architecture teams opens now.

Anyone designing a platform today should treat these topics as fixed items on the roadmap. An architecture that accounts for container isolation, crypto-agile mechanisms, and confidential processing from the outset will pass the next attestation without requiring rework. One that has to retrofit them will pay twice.

What Sovereignty Delivers – and What Merely Claims To

The gap between genuine and asserted sovereignty is rarely a question of technology – it is a question of how rigorously you examine the details. The patterns below separate one from the other.

The difference between those two columns is not solely a matter of which provider you choose. Even large international clouds now offer sovereign regions with separate administration and key control. What matters is that your own architecture demands and verifies the right tier, rather than relying on a label. In the end, sovereignty is not a product you purchase – it is a property you demonstrate.

Frequently Asked Questions

Does a C5 attestation mean my data is stored in Germany?

No. The C5 audits the information security of a cloud service, not the data location. A provider can hold a full C5 attestation and still process data outside Germany. Data residency must be clarified and verified separately by contract – it is not part of the C5 certification.

What is the difference between BYOK and HYOK?

With Bring Your Own Key, the customer supplies their own keys, but the provider manages them within its infrastructure. With Hold Your Own Key, the keys remain entirely under the customer’s control – the provider cannot decrypt without explicit authorisation. HYOK delivers stronger key sovereignty but is more complex to operate.

Is an EU data centre sufficient for sovereignty?

It covers data residency only. Operational control and key sovereignty remain unaddressed. If the platform is administered from a third country, or the provider holds the keys, an EU location alone offers no reliable protection. True sovereignty requires all three layers to be resolved.

What does C5:2026 change for my architecture?

The updated version expands the catalogue to 168 criteria and adds container management, post-quantum cryptography, and confidential computing. Platforms should plan for container isolation, crypto-agile procedures, and confidential processing from an early stage. The new requirements become mandatory for audit periods beginning mid-2027.

Which data requires the highest sovereignty level?

Datasets with high protection needs or strict regulatory obligations: health records, engineering and research data, personal data at scale. For these, key and operational sovereignty pay off. Public or non-critical data is well served by a standard cloud. The real skill lies in classification – not blanket maximum demands.

Image credit: Cover image AI-generated (June 2026), C2PA certificate embedded in image