On 7 April 2026 Germany's BSI published C5:2026 — the second substantial revision of the Cloud Computing Compliance Criteria Catalogue. 258 pages, 17 criteria areas, and explicit requirements for container management, confidential computing and post-quantum cryptography for the first time.
For organisations using or providing cloud services, C5 is not an optional badge. It is the reference framework that customers, regulators and insurers work from.
What is new
The BSI sets out the changes in the catalogue's own introduction:
Container management (OPS-34, OPS-35). Entirely new criteria covering both policy and implementation. Given that container-based deployment has been standard for years, overdue.
Confidential computing (OPS-32, OPS-33). Requirements for processing inside protected enclaves and for remote attestation. Technically the most interesting addition: it allows data to be protected cryptographically during processing, not only at rest and in transit.
Post-quantum cryptography (CRY area). Primarily affects cryptographic change management (CRY-02) and review of cryptography practices (CRY-03). Providers must demonstrate they are preparing for the transition — post-quantum readiness is now an audit subject, not a future concern.
Supply chain management (SSO-01 to SSO-08). Expanded to eight criteria. New requirements include maintaining a register of all service organisations (SSO-04), monitoring supplier compliance (SSO-05), contract termination strategies (SSO-06) and governance of suppliers of functional components (SSO-08).
Multi-tenancy and sovereignty. Data separation (OPS-30, OPS-31) plus a new taxonomy of partitions, regions and zones. The BSI defines these precisely: a partition comprises regions under uniform IAM, a region is confined to one metropolitan area, a zone consists of at least two physically separate sites.
Structure. Criteria now consist of clearly delimited sub-criteria, making mapping onto providers' control systems more precise. Additional criteria are explicitly classified as "additional sharpen" or "additional complement".
The BSI names EUCS substantial level, CSA Cloud Controls Matrix v4, ISO/IEC 27001:2022 and the NIS2 directive as reference standards.
One change that gets lost in the coverage: the catalogue is being issued in machine-readable form for the first time — planned as YAML, XLSX and PDF, in German and English. Anyone automating GRC processes or running a compliance platform finally gets a processable version instead of a PDF to transcribe. First publication was in English, because the catalogue is used internationally.
A correction to the original: the legal reference no longer holds
The first version of this piece stated that operators of critical infrastructure must demonstrate appropriate technical and organisational measures under § 8a BSIG. That was already out of date when it was written.
The German NIS2 transposition amended the BSIG. Obligations for essential and important entities now sit elsewhere — risk management measures in § 30, the specific requirements for operators of critical installations in § 31, management duties in § 38. A compliance file still citing § 8a BSIG is citing a superseded version.
None of that changes the substance: a C5 attestation from your cloud providers remains a central building block of the evidence. Only the citation has to be right.
The point almost everyone misses
"Request a C5 attestation" is sound advice and still falls short. An attestation is an audit report, not a seal — and its value lies in reading it.
Type 1 or type 2. A type 1 attestation certifies the suitability of control design at a point in time. A type 2 attestation additionally certifies operating effectiveness across a review period. Only type 2 says anything about whether the controls actually worked. A provider years into the market still presenting only type 1 should be able to explain why.
The exceptions. Audit reports contain identified deviations and limitations. That is the informative part — not the summary on page one. A report with no exceptions at all is unusual, not a mark of quality.
The obligations that sit with you. Every C5 report names measures the cloud customer must implement for the provider's controls to work at all — access administration, encryption configuration, log review. File the attestation without working through that list and you have a document in a folder and a gap in operations. For your own NIS2 documentation, that list is the usable part.
The scope. An attestation covers named services in named regions. Whether the exact service in the exact region you use is in scope is stated in the scope section — and it diverges from the sales material more often than you would expect.
When the provider has no attestation
The most common situation in the mid-market, and absent from the original. No C5 attestation does not automatically mean exclusion, but it shifts the burden of proof to you.
A workable route: check whether ISO 27001 with a suitable scope serves as substitute evidence, run the C5 criteria catalogue as a questionnaire against the provider, document the answers, and carry the residual uncertainty as a consciously accepted risk in your risk assessment — with a date, a rationale and a sign-off. That is more work than filing an attestation, but it is auditable. An empty field in the supplier assessment is not.
One sector is exempt from this flexibility: since July 2025, German digital healthcare requires a type 2 attestation as soon as patient data is processed in a cloud. For practices, medical centres and hospitals that is not a procurement preference but a precondition.
C5 in the regulatory landscape
NIS2. Article 21(2)(d) requires supply chain security. C5 supplies the assessment framework for the cloud portion of that chain.
DORA. For financial services, a recognised framework for assessing ICT third-party providers.
Cyber Resilience Act. Complementary rather than overlapping: the CRA addresses the product, C5 the operation.
EUCS. The European certification scheme builds on C5, and C5:2026 was explicitly designed to be compatible with the substantial level. An attestation today is preparation for it.
What to do
As a cloud customer: request type 2 attestations from every critical provider — and read them. Check the scope, check the exceptions, and carry the customer-side obligations into your own implementation. The new supply chain criteria give you concrete questions: does the provider maintain a register of its service organisations (SSO-04)? How does it monitor their compliance (SSO-05)?
As a cloud provider: start the gap analysis against C5:2026. Container management and confidential computing are new and require technical as well as procedural change. The cryptography strategy needs review.
As an operator of critical installations: provider attestations form part of your evidence under the amended BSIG. While you are at it, check whether your existing documentation still cites the old version.
From practice
C5:2026 is a substantial update, not a cosmetic one. The expanded supply chain criteria in particular make it easier to evidence the NIS2 requirement on supply chain security concretely — previously an assertion, now an audit subject with a number attached.
An attestation nonetheless documents a state across a review period that has already passed by the time you receive it. Whether the measures hold in daily operation is shown only by continuous observation. That is where XIEM® comes in: we monitor the interfaces to cloud services and detect deviations before they become incidents.
The attestation is the entry ticket. Ongoing control is a different thing.
Sources