You can implement BSI C5 yourself in eight steps: choose the cloud service and regions, download the catalogue, run a gap check, write the system description, build or fix controls, collect dated evidence, run a mock audit, then engage an independent auditor. Only the auditor can issue the attestation.
Who is this for?
C5 is aimed at cloud service providers, their auditors and their customers. If you sell a SaaS product, platform or infrastructure service to German or other European customers, a C5 report may come up in procurement. BSI also points out that federal agencies must ask for proof of C5 criteria under the minimum standard for external cloud use. For most other buyers the catalogue is a recommendation, so check what your actual customers ask for before you spend.
The catalogue is published by BSI under a Creative Commons licence, in PDF, Excel and, for C5:2026, machine readable YAML. You can start without buying anything.
The plan, in order
Step 1: pick the service. The audit covers specific services in specific regions. Choose one product to begin with. Owner: the head of engineering or product.
Step 2: choose the version. C5:2026 has 168 criteria in 17 areas. C5:2020 has 121. BSI says the new version applies to engagements starting on or after 1 June 2027 and can be adopted earlier. Ask a prospective auditor which they prefer.
Step 3: gap check. Copy each criterion and sub-criterion into a sheet. Mark each as met, partly met or missing. Be honest: the auditor will test it later. Owner: security lead, with engineering input.
Step 4: decide on additional criteria. The basic criteria are the minimum scope. Additional criteria suit customers with higher protection needs. Your customers will tell you whether they care.
Step 5: write the system description. It explains the service, its internal control system and how the criteria are met. It also carries the general conditions: data locations, jurisdiction, subcontractors and other certificates. Owner: a named writer with legal review.
Step 6: build and run controls. Fix the red rows. Each control needs an owner, a frequency and a place its evidence lands. Criteria are technology neutral, so pick tools you can operate.
Step 7: collect evidence and rehearse. For Type 1 you show controls exist and are implemented. For Type 2 you show they operated across the period, typically six or twelve months according to BSI. Run a mock audit by having someone not on the control team pull samples.
Step 8: engage the auditor. Agree scope, version, report type and period. Share the system description early.
What evidence should you keep?
Keep whatever shows a control ran on a date: access review records with sign offs, change tickets with approvals, vulnerability scan exports and remediation tickets, backup restore test records, incident tickets, training completion lists, supplier reports. Name them by control so a sampler can find them in minutes.
What are the common time sinks?
Subcontractor reports that do not exist yet, a scope that keeps growing, and controls that rely on one person's memory. Fix those first. Treat any timeline as your own estimate. BSI does not publish a duration.
What to do
- Pick one service and its regions.
- Download the catalogue and agree the version.
- Run the gap check with owners per row.
- Draft the system description and general conditions.
- Fix gaps and start logging evidence.
- Rehearse, then choose an auditor and fix the engagement type.
- Plan a Type 2 period straight after Type 1.
Quick check
Is C5 legally required?
Mostly it is a recommendation. BSI says federal agencies must ask for proof of C5 criteria when using external cloud services, and other sectors may require it by regulation or contract. Check your customers.
Can I use the catalogue for free?
Yes. BSI publishes it under CC BY 4.0, so you can download it and use it in your gap check.
How Safeguard helps automate this
The slow part of a C5 plan is steps 6 and 7: running controls and proving it. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. That saves the team time for other work. For the technical criteria, evidence comes from your real code and dependencies, using scans, SBOMs and reachability. 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. Safeguard helps prepare and keep evidence ready. The attestation comes from your independent auditor. Book a call to walk through it.
Sources
Last reviewed: 18 October 2026.
