BSI C5:2026: What Cloud Users Need to Know Now
At the beginning of April, a piece of news arrived that received far less attention in my clients' IT leadership teams than it deserved: the BSI published C5:2026. Anyone who has spent the past months building C5:2025-readiness is now starting over. 168 criteria instead of 121. Seven new mandatory areas. And machine-readable for the first time, in YAML, XLSX and PDF.
I have been advising DACH enterprises on BSI C5 compliance for years. A conversation I have repeatedly in this context goes roughly like this: the CIO points to two certificates. ISO 27001, freshly recertified. Plus the hyperscaler's C5 attestation. "We are C5-ready." I ask: "Who on your side is evaluating the CloudTrail logs?" Silence. Then: "AWS does that, doesn't it?" No. AWS does not do that.
This misunderstanding is not naivety. It is a structural knowledge gap I have observed since the first version of C5, and one that takes on a new sharpness with C5:2026.
What C5:2026 Changes
The jump from C5:2020 to C5:2026 is not an update. It is a generational shift. 121 criteria across 16 topic areas have become 168 criteria across 17 topic areas. Three areas are new and mandatory:
Container Management. Anyone running containerised workloads on AWS, with EKS or ECS for example, must now demonstrate that container images come from trusted sources, are signed, and are regularly scanned for vulnerabilities. Image scanning in a CI/CD pipeline is not optional. It is C5.
Post-Quantum Cryptography. BSI and NIST have been working towards this moment for years. C5:2026 now requires that migration plans for post-quantum algorithms must exist. Nobody expects all TLS connections to be migrated to CRYSTALS-Kyber by tomorrow. But an inventory of critical cryptographic dependencies and a documented migration plan: that is required.
Confidential Computing. This area was a niche topic in practice two years ago. AWS Nitro Enclaves, AMD SEV-SNP on EC2 instances, Intel TDX. C5:2026 signals: anyone processing highly sensitive data in the cloud must be able to justify why they are not using hardware-isolated execution environments.
On top of this comes the EUCS alignment: C5:2026 has been coordinated with the European Cloud Security Scheme. Sovereignty criteria are coming separately. Anyone without a sovereignty position today should start developing one.
The Attestation Logic Many Get Wrong
C5 has two attestation types. Type 1 describes that controls exist at a point in time. Type 2 demonstrates that they have been operated effectively over a defined period. Type 2 is the more demanding, but also the more meaningful, form of evidence.
AWS holds a C5 Type 2 attestation for its cloud stack. That is good. But this attestation covers exactly what AWS controls: the physical infrastructure, the hypervisor layer, the network, the managed services in their operation.
What it does not cover: everything the customer configures, operates, and is responsible for. The BSI calls these Customer Unique Engagement Controls (CUECs). Anyone seeking a C5 attestation for their own cloud operations must independently demonstrate these CUECs. And C5:2026 has significantly expanded their scope.
Concretely, C5:2026 now asks: how do you manage container images and the software supply chain? Which sub-processors do you use, and which of them can access your data? Who has legal access to the data under what circumstances? IAM processes, log evaluation, supplier risk management: these are not AWS responsibilities. They are yours.
Three Steps I Recommend to My Clients
1. Gap Analysis Against the New Topic Areas
The first step is not an audit project. It is a mapping exercise. Take your existing ISMS and your NIS2 programme and lay the new C5:2026 areas alongside them. Container management, software supply chain, post-quantum, confidential computing, cloud sovereignty. For each area: do we already have a control? Does it match the C5 requirements? Or is there a gap?
Organisations already operationally implementing NIS2 often have a head start in supply chain risk management. ISO 27001 certifications frequently cover parts of the asset and access management requirements. The goal of this phase is to identify synergies and avoid duplicating work.
A practical note: C5:2026 is machine-readable for the first time. The YAML download from the BSI makes it possible to import the criteria directly into a GRC tool rather than maintaining them manually. That is a genuine improvement.
2. Compliance as Code, Not Spreadsheets
Anyone operating C5 compliance with Excel spreadsheets and manual checklists has a scaling problem. With 168 criteria across 17 topic areas, this becomes a full-time task that is already outdated by the next audit period.
The approach I recommend is based on three AWS services:
AWS Control Tower provides the foundation for a multi-account landing zone with a central logging account, preventive Service Control Policies (SCPs) as guardrails, and detective Config rules. Existing accounts can be enrolled into Control Tower retrospectively.
AWS Config with the C5 Conformance Pack. The "Operational Best Practices for Germany Cloud Computing Compliance Criteria Catalog (C5)" conformance pack is available and continuously checks against a defined set of C5 requirements. It is not a complete substitute for an audit, but it makes many technical controls continuously visible.
AWS Security Hub as the CSPM layer consolidates findings from Config, GuardDuty, and Firewall Manager in a single view. Anyone with Security Hub standards activated sees immediately where technical deviations from the expected baseline state occur.
A note for anyone still relying on AWS Audit Manager: AWS has sunset Audit Manager. It is no longer available as an actively developed solution. Evidence management now runs through AWS Config Rules, Security Hub Findings, CloudTrail, and manual evidence collections (policies, contracts, supplier risk analyses).
3. Evidence Collection Without Audit Manager
The goal of a C5 attestation is to demonstrate that defined controls are being operated effectively. The demonstration requires evidence: technical findings, process documents, contracts.
For the technical side: AWS Config Rules provide continuous compliance checks whose results can be archived in S3. Security Hub Findings can be exported via EventBridge into an S3-based evidence repository. CloudTrail logs are the immutable record of all API calls and therefore the backbone of evidence for access management controls.
For the manual side: policies, operating manuals, data processing agreements, results of supplier risk analyses. These documents must be stored in a revision-proof manner and be referenceable against the C5 criteria. Anyone using a GRC tool maintains the link between the criteria catalogue and the evidence collection here.
What This Means in Practice
I developed the Cloud Governance Accelerator (CGA) as a tool that applies this baseline to historically grown AWS environments: brownfield accounts that have evolved over years without a structured governance foundation. The goal is C5 and NIS2 readiness without costly complete re-platforming. Anyone who wants to discuss this can find me on LinkedIn or at the AWS Summit Hamburg in May.
The more important point is this: C5:2026 is not a compliance project that you complete once. It is an operational state. The challenge is not meeting 168 criteria on a single occasion. It is positioning an organisation to maintain and demonstrate that state on an ongoing basis.
Anyone who starts now has an advantage over those waiting for the next auditor.
Questions about BSI C5:2026, your compliance programme, or the Cloud Governance Accelerator? Comment below or connect directly.