Germany BSI C5 Guide: Cloud Compliance Criteria and Attestation

Cloud customers in Germany are increasingly asked to prove that their providers meet the BSI Cloud Computing Compliance Criteria Catalogue (C5), and many teams discover too late that a C5 report is an attestation they must read and act on, not a certificate they can file. C5 is published by the German Federal Office for Information Security (BSI) and sets minimum security requirements for cloud services, assessed by public accountants under ISAE 3000. It is mandatory for federal bodies buying external cloud services and, since 1 July 2024, for cloud processing of health and social data under section 393 of the German Social Code Book V (SGB V). This guide explains the two current versions (C5:2020 and C5:2026), how Type 1 and Type 2 attestations work, what the identity and key management criteria demand, and how providers and customers should prepare. It is written for cloud providers' compliance and engineering leads, and for security, procurement and audit teams at cloud customers. Status was checked on bsi.bund.de and gesetze-im-internet.de in October 2026.

Key takeaways

• C5 is an attestation, not a certificate. The BSI states there is no C5 certification procedure; a public accountant issues an opinion under ISAE 3000 (or the German equivalent IDW PS 860), and the BSI neither selects auditors nor reviews reports.
• Two versions are in play. C5:2020 has 121 criteria in 17 subject areas; C5:2026 has 168 criteria, split into subcriteria aligned with the EU cloud scheme EUCS, and applies to examinations on or after 1 June 2027, with earlier adoption allowed.
• Type 2 is what counts. The BSI says Type 1 should be used only for an initial audit; section 393 SGB V has required a current Type 2 attestation for health data in the cloud since 1 July 2025.
• Half the controls sit with the customer. Every C5 report lists corresponding controls the customer must operate; section 393 SGB V makes implementing them a legal condition, and most cloud breaches start on the customer side.
• Identity and keys are the core of the catalogue. The IDM and CRY areas cover account lifecycle, privileged rights, access to customer data, authentication and key management, which is where machine identities and signing keys must be in scope.

What it is and who it applies to

The BSI first published C5 in 2016. It is aimed at professional cloud service providers, their auditors and their customers, and it contains only auditable, technology-neutral criteria: it says what must be achieved, not which product to use. The BSI reports that more than 100 attestations have been issued to national, European and global providers, including small and medium-sized ones.

Section 393 SGB V in practice

• Data location: processing must take place in Germany, another EU Member State, a state treated as equivalent under section 35(7) SGB I, or a third country with a GDPR Article 45 adequacy decision, and the responsible body must have an establishment in Germany.
• Attestation type: a Type 1 attestation counted as current until 30 June 2025; from 1 July 2025 a current Type 2 attestation is required. Systems placed on the market after 30 June 2025 may rely on Type 1 for their first 18 months, then need Type 2 from month 19.
• Customer criteria: the healthcare organisation must implement the customer criteria listed in the attestation's audit report.
• Equivalence: the Federal Ministry of Health interprets the provision and may specify comparable standards by regulation in agreement with the BSI. The BSI states that it does not assess legal equivalence under section 393(4).

See the Healthcare Identity Security Guide for the wider identity controls in clinical environments, and the Data Sovereignty and Residency Guide for location and jurisdiction questions that C5 reports but does not decide.

Structure and key requirements

Both versions group criteria into 17 subject areas. In C5:2020 the areas are, by their catalogue abbreviations: OIS (organisation of information security), SP (security policies and instructions), HR (personnel), AM (asset management), PS (physical security), OPS (operations), IDM (identity and access management), CRY (cryptography and key management), COS (communication security), PI (portability and interoperability), DEV (procurement, development and modification of information systems), SSO (control and monitoring of service providers and suppliers), SIM (security incident management), BCM (business continuity management), COM (compliance), INQ (dealing with investigation requests from government agencies) and PSS (product safety and security).

• Surrounding parameters: section 4 of the catalogue requires the provider to report framework conditions such as availability and troubleshooting information, sub-service providers used, data centre locations and how government investigation requests are handled. These are disclosures, not pass or fail criteria, so the customer must judge them.
• Non-applicable criteria: where a basic criterion is irrelevant to the service, the report must explain why (C5:2020 section 3.4.2.1, C5:2026 section 3.4.3). Read every exclusion.
• Transition rule: if a C5:2020 examination period ends on or after 28 February 2027, the provider must describe planned control changes for C5:2026 in its system description.
• EUCS alignment: C5:2020 was the basis for the EUCS "Substantial" level, and C5:2026 was revised with the CEN/CENELEC technical specification derived from it, the CSA Cloud Controls Matrix v4, ISO/IEC 27001:2022 and NIS2 as inputs.

Identity and NHI requirements

The IDM area in C5:2020 has nine criteria. They read naturally for human users, but cloud services run on service principals, workload identities, API keys, automation accounts and signing keys. An attestation is only as good as the scope the provider defines, so customers should check that the system description treats these as user accounts.

• Keys as identities: the CRY area covers cryptography and key management. Signing and token-issuing keys are the most powerful non-human identities a provider holds. The Microsoft Storm-0558 key breach showed what happens when a retired signing key stays active and relying services do not enforce key scope (ATT&CK T1606 Forge Web Credentials).
• Customer side: the provider attests its own IDM controls; the customer still owns its tenant accounts. Abuse of valid cloud accounts (ATT&CK T1078.004 Cloud Accounts) is a customer-side failure that no provider attestation covers.
• C5:2026 additions: the new focus on container management, supply chain and client separation pulls workload identities, pipeline credentials and tenant isolation further into scope. Confirm the exact subcriteria in the published C5:2026 catalogue before mapping controls.

See the Service Account Security Guide and the Secrets Management Guide for the controls behind IDM-06, IDM-08 and IDM-09.

Implementation steps

For cloud service providers

1. Choose the version and timeline. If your next period starts on or after 1 June 2027, plan for C5:2026; if it ends on or after 28 February 2027 under C5:2020, prepare the planned-changes disclosure.
2. Define the service scope. Name the services, regions, data centres and sub-service providers in scope. Customers will reject reports whose scope does not match what they buy.
3. Map existing controls. Use the BSI cross-reference tables to reuse ISO/IEC 27001 controls. The BSI notes C5 basic criteria include all ISO 27001 requirements, so a joint audit saves effort, but an ISO certificate is not recognised as C5 evidence on its own.
4. Decide on additional criteria. Add them where target customers have high protection needs (for example health or public sector data). In C5:2026 decide per subcriterion whether you are sharpening or complementing.
5. Write the system description. This is part 3 of the report and describes the service's internal control system mapped to the criteria. Include machine identity, key management and customer data access controls in plain terms.
6. Run a readiness assessment. A gap review with the auditor or an internal team before the formal period starts. Fix design gaps first; operating gaps will appear in Type 2 testing.
7. Perform the initial Type 1, then move to Type 2. The BSI advises Type 1 only once. Plan a Type 2 period of 6 or 12 months and back-to-back periods so customers always have a current report.
8. Publish the corresponding customer controls. Write them as testable statements, for example "customer enforces MFA for all administrative identities in its tenant".

For cloud customers

1. Assess protection needs for confidentiality, integrity and availability of the data you will place in the service.
2. Obtain the report directly from the provider under NDA, and check version, Type, period, scope and the auditor's opinion.
3. Review exceptions, exclusions and surrounding parameters against your needs, including data location and government access handling.
4. Request additional criteria if the basic criteria are not enough, accepting that the provider may decline.
5. Implement and evidence the customer controls in your own control framework, with owners.
6. Write C5 into the contract: annual (or more frequent) delivery of new reports, notification of qualified opinions, and the right to further audits.
7. Repeat yearly. The BSI recommends the customer analysis is repeated each year.

Fallback: if a provider loses or cannot produce a current Type 2 report, record it as a risk exception, apply compensating controls (stronger encryption under your own keys, tighter access), and set a dated exit or remediation plan. For healthcare use under section 393, take legal advice before continuing processing.

Evidence and assessment

• Who may issue it: only public accountants can issue the attestation, though the team may include other experts. Team qualifications (for example CISA, CISM, CRISC, CCSK, CCSP, ISO 27001 or IT-Grundschutz auditor) must be listed and verified in the report.
• Report contents: the auditor's opinion, the management statement (omitted for direct engagements), the system description, the criteria with controls, test procedures and results, and optionally the provider's response to deviations. Subcontractor controls the provider relies on (complementary subservice organisation controls) must also be shown.
• Validity: a report does not expire, but the BSI notes older reports are of limited use for current risk management, which is why annual examinations are normal.
• Reading tools: the BSI publishes a report summary template and an evaluation guideline (Excel) to help customers assess provider reports and define their own user controls.

Detection and measurement

• Coverage: percentage of cloud services processing sensitive data with a current Type 2 C5 report (target 100% for health and public data).
• Currency: number of days since the end of each provider's last examination period; alert above 12 months.
• Customer controls: percentage of corresponding customer controls with a named owner and tested evidence.
• Deviations: count of open deviations from provider reports that affect your use, and median time to agree a mitigation.
• Identity hygiene in your tenant: percentage of administrative and service identities with MFA or workload federation, and number of static keys older than 90 days.

Mapping to other frameworks

• SOC 2: the BSI FAQ draws the analogy to SOC 2 and ISAE 3402. Many providers run combined examinations; a SOC 2 report alone does not satisfy C5. See the SOC 2 Guide.
• ISO 27001 and IT-Grundschutz: neither certificate yields a C5 attestation automatically. IT-Grundschutz is the BSI's ISMS methodology for the organisation; C5 is a service-level cloud attestation. See the ISO 27001 Certification Guide.
• CSA CCM and STAR: CCM v4 was an input to C5:2026. See the Cloud Security Alliance CCM and STAR Guide.
• NIS2: C5:2026 took NIS2 into account, and cloud providers are in NIS2 scope. A C5 report is useful supply chain evidence but is not NIS2 compliance in itself. See the NIS2 Directive Guide.

Common pitfalls

• Filing the report unread. Procurement ticks "C5: yes" without checking Type, period, scope or exceptions. The BSI is explicit that the customer must assess the report critically because no independent body reviews it.
• Ignoring corresponding customer controls. The provider can pass every criterion while the tenant is open. In the Snowflake breach, about 165 customer accounts were accessed with infostealer credentials on accounts without MFA; the platform itself was not found to be flawed.
• Scope that misses the service you use. Reports cover named services and regions; a new feature or region may sit outside them.
• Repeated Type 1 reports. A provider offering Type 1 year after year has not shown that controls operate. Under section 393 SGB V this is no longer enough for established systems.
• Machine identities left out of IDM scope. Service principals, CI tokens and signing keys are treated as "technical" and excluded from reviews and privileged access controls.
• Late C5:2026 planning. Providers whose C5:2020 periods end after 28 February 2027 must already disclose planned changes; 47 more criteria and subcriteria splitting mean real control work, not a relabelling exercise.

Practitioner checklist

• List every cloud service that processes health, social or official federal data and record its C5 version, Type, period end and auditor.
• Reject or escalate any service relying on a Type 1 report beyond the limits in section 393 SGB V.
• Extract the corresponding customer controls from each report into your control register with owners and test dates.
• Check the surrounding parameters for data centre locations, sub-service providers and government request handling against your data residency rules.
• Confirm the IDM and CRY scope covers service accounts, workload identities, API keys and signing keys.
• Contract for annual report delivery, deviation notification and audit rights.
• Providers: map your control set to C5:2026 now and plan the first C5:2026 period start on or before 1 June 2027.
• Providers: publish customer controls as testable statements and keep reports back-to-back.
• Re-run the customer assessment every year and after major service changes.

Standards and references

• BSI: Cloud Computing Compliance Criteria Catalogue (C5)
• BSI: C5:2026
• BSI: C5:2020
• BSI: C5 introduction
• BSI: C5 frequently asked questions
• Federal Ministry of Justice: Section 393 SGB V, cloud use in healthcare
• MITRE ATT&CK: Valid Accounts: Cloud Accounts
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Data Sovereignty and Residency Guide · Global Cybersecurity Regulatory Map · Third-Party Risk Management Guide · ISO 27001 Certification Guide. For the BSI's organisation-wide ISMS methodology, see our BSI IT-Grundschutz Guide. This guide summarises the BSI C5 catalogue and section 393 SGB V as checked in October 2026 and is not legal advice.