BSI C5 is Germany's cloud security criteria catalogue, and an engineering team prepares for it by being able to show, for each technical area, a written rule, a working configuration and a record that it ran. Start with identity, encryption, logging, vulnerability handling, change control and recovery, then map each to the catalogue.
What is C5, and who checks it?
The Federal Office for Information Security (BSI) describes C5, the Cloud Computing Compliance Criteria Catalogue, as a specification of minimum requirements for secure cloud computing. It is written for cloud providers, their customers and auditors. The first edition came out in 2016. BSI's page lists C5:2026 and C5:2020 and says the catalogue was completely revised in 2025 and 2026, so confirm which edition your customers expect before you build your checklist.
The checking is done by auditors the provider chooses, such as public accountants. They produce an examination report that includes a system description of your processes and measures. BSI is not involved in selecting auditors and does not review the reports. Customers are expected to obtain your report, read it and repeat that yearly. Auditors test whether criteria are met at the time of the investigation and, depending on the engagement, whether they were met over a past period. Ask your auditor which type you are being engaged for, because it changes how much history you need.
One limit on this article: BSI's overview page did not list the catalogue's area names or criteria numbers, and we did not read the full catalogue. The checklist below is an engineering preparation list organised by technical theme. Map each line to the exact criteria in the edition you are assessed against.
What should the checklist cover?
Think in themes, and for each one keep three artefacts: the rule, the configuration and the proof.
Identity and access. Single sign-on for staff, multi-factor authentication on every administrative path, role-based access for production, and a recorded access review. Proof: an export of who can reach production and the dated review sign-off.
Cryptography and key handling. Encryption in transit on every external and internal service link, encryption at rest for storage and backups, and a key lifecycle that says who creates, rotates and retires keys. Proof: configuration exports and a rotation log.
Logging and monitoring. Central logs for authentication, administrative actions and security events, with retention, time synchronisation and alerts someone reads. Proof: a sample alert and its ticket.
Vulnerability and patch management. An inventory of what you run, regular scanning of code, dependencies, images and hosts, and remediation timelines by severity. Proof: scan reports plus closure records.
Secure development and change control. Reviewed pull requests, protected branches, tested releases, separation between who writes and who deploys, and a rollback path. Proof: branch protection settings and a sample change from ticket to release.
Operations, backup and recovery. Documented backups, tested restores and a disaster recovery plan with a recent exercise. Proof: a restore test record.
Network and tenant separation. Segmentation between environments and between customers, with deny by default rules. Proof: network rules export and a separation test.
Location and subcontractors. Where customer data is stored and processed, and which subcontractors touch it. German customers often ask this first. Proof: a current location statement and a subcontractor list.
In what order should you work?
Begin with the inventory, because every other theme needs it. Then close the identity and logging gaps, since auditors sample these heavily. Next do vulnerability management and change control, which produce evidence continuously once running. Finish with the recovery test, which needs calendar time to schedule.
What mistakes appear again and again?
- Describing controls in the system description that the team does not actually operate.
- Logging without anyone reviewing alerts.
- A backup that has never been restored.
- Treating a subcontractor's report as covering your own responsibilities.
- Building to the 2020 edition while customers ask for the new one.
What to do
- Confirm the C5 edition and the engagement type with your auditor and key customers.
- Download the catalogue and map each theme above to its criteria.
- Build the system and asset inventory.
- For each theme write the rule, export the configuration and save one dated proof.
- Run a restore test and a tabletop incident exercise.
- Do a dry run internally, sampling evidence as an auditor would.
Quick check
Does BSI audit my C5 report?
No. BSI says it is not involved in selecting auditors and does not check audit reports. Customers are expected to read the report and decide whether it is sufficient.
Is C5 a certificate?
BSI describes an examination report by an auditor, including a system description, rather than a certificate issued by BSI.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Several rows of this checklist, such as the dependency inventory, vulnerability scan results and change records, can be pulled from your real code and dependencies through scans, SBOMs and reachability analysis instead of screenshots. Continuous monitoring runs between audits, so drift shows up before the auditor finds it. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you pick which categories run automatically and the approval level. An independent auditor performs the examination. Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo
Sources
- BSI Cloud Computing Compliance Criteria Catalogue C5, fetched 18 October 2026
Last reviewed: 18 October 2026.
