For a BSI C5 attestation you prepare a description of your service related internal control system, a written statement from your legal representative, policies and procedures behind each criterion, and records that let an auditor test them. The auditor produces the report under ISAE 3000. C5:2026 has 168 criteria and C5:2020 has 121.
What is C5 and who issues the attestation?
C5, the Cloud Computing Compliance Criteria Catalogue, is published by Germany's Federal Office for Information Security (BSI). BSI states that it contains criteria that can be audited and does not prescribe the measures you must use. Auditors, not BSI, perform the audits and issue attestations. According to BSI's FAQ, attestations are issued by auditors working under the ISAE 3000 standard or national equivalents, and an attestation covers specific cloud services and regions rather than the provider as a whole.
BSI's introduction says C5:2020 has 121 criteria and C5:2026 has 168 criteria, divided into 17 subject areas, with the 2026 criteria split into sub-criteria. BSI recommends C5:2020 for test periods ending on or after 15 February 2021, and recommends C5:2026 for test periods ending on or after 1 June 2027. Check the current page for which applies to your audit period.
What are the documents an auditor reads?
BSI defines the structure of a C5 report. The parts are the independent auditor's report, a written statement by the cloud provider's legal representative, a description of the service related internal control system, and the criteria with your controls and the auditor's test procedures and results. The statement and description are yours to write for an audit of a statement. In a direct engagement the statement part is omitted.
1. System description Describes the cloud service and its control system in relation to the criteria. BSI's introduction lists framework information that must be provided: availability and troubleshooting, the sub-service providers used, the geographic location of data centres, and how investigation requests from government agencies are handled. Build a template early and keep it current.
2. Management statement A written statement by your legal representative that the description is accurate and, for the assessment type, that the controls are suitably designed (Type 1) and, if commissioned, effective (Type 2). Have a named executive prepared to sign.
3. Policies and standards Each criterion needs a documented rule. Typical set: information security policy and risk management, organisation and responsibilities, asset management, human resources security, access and identity management, cryptography and key management, operations and monitoring, logging, vulnerability handling, communications security, portability and interoperability, secure development, supplier and sub-service management, incident management, business continuity, compliance and audit, and handling of government investigation requests. Use headings that match C5's subject areas so mapping is obvious.
4. Procedures and runbooks How each control operates, with owners and frequency: provisioning and deprovisioning, change management, patching, backup and restore, incident response, supplier review, and so on.
5. Control matrix A table with one row per criterion or sub-criterion: your control description, owner, frequency, evidence source, and system or service covered. This is the document the auditor tests against. Keep wording consistent with the system description.
6. Records The evidence each control produces: access reviews, change tickets, scan reports, restore tests, supplier reviews, incident reports, training attendance, monitoring logs. The standard BSI example for OPS-02 shows the difference between types: Type 1 checks that the monitoring software exists and is set up with thresholds, Type 2 checks that monitoring ran continuously through the audit period, using logs and sampled events.
7. Sub-service provider documentation Which providers you rely on, which are included or carved out of your scope, and their own attestations or evidence.
Type 1 or Type 2?
BSI explains that Type 1 gives an opinion on whether controls are suitably designed and implemented at the time of the audit, while Type 2 adds an opinion on operating effectiveness over an audit period, typically 6 or 12 months. BSI says a Type 2 is needed for appropriate informative value, and that Type 1 belongs to the initial audit of a cloud service and should not be repeated in succession. BSI also recommends that customers ask providers who keep supplying Type 1 reports why. Plan your first audit and your second accordingly.
What mistakes should you avoid?
- Describing intended controls instead of operating ones.
- A system description that conflicts with the control matrix.
- Forgetting the framework information such as data centre locations and sub-service providers.
- Scope defined for the company, not the service, when the attestation is service specific.
- Policies mapped to ISO or SOC headings and not to C5 criteria.
- Evidence missing for the full audit period.
What to do
- Decide the service and regions in scope and which C5 version applies to your test period.
- Obtain the current catalogue and BSI's report summary and evaluation guidance from the BSI site.
- Draft the system description and the control matrix side by side.
- Fill policy gaps and write short procedures with owners.
- Start collecting records now, with consistent file naming by criterion.
- Collect sub-service provider evidence and decide carve outs.
- Agree the audit type, period and sampling approach with your auditor.
- Brief the executive who will sign the statement.
Quick check
Who issues a C5 attestation?
Auditors authorised to work under ISAE 3000 issue it. BSI publishes the criteria but does not perform the tests or issue attestations.
Does a C5 attestation cover the whole company?
No. BSI says it is issued for the tested cloud services in defined regions, not for the provider as a whole.
How Safeguard helps automate this
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, which helps for a Type 2 period. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. The attestation comes from an independent auditor.
Open the framework mapping demo or book a call.
Sources
The criteria catalogue itself was not read. The typical policy topics listed above are a general guide, so map them to the actual criteria in the version you are audited against.
Last reviewed: 18 October 2026.
