The most common first time C5 mistakes are scoping the whole company instead of a cloud service, ignoring subcontractors, treating the general conditions as paperwork, picking the wrong catalogue version, and relying on Type 1 reports year after year. BSI's own pages warn about most of them.
Mistake 1: scoping the company, not the service
A C5 attestation is not issued for a provider as a whole. It covers specific cloud services in defined geographical regions. Teams that write a scope like "our engineering organisation" get stuck at the first auditor meeting. Name the service, the regions it runs in, and the infrastructure and people that operate it. Everything else is out.
Mistake 2: forgetting that subcontractors inherit your criteria
If another provider runs part of your service, BSI says you must pass the catalogue's criteria on to them, including the transparency conditions. Your report then lists the complementary subservice organisation controls you rely on. First timers discover this late, when a hosting or support vendor has no audit report to hand over. List every subservice organisation in week one and ask for their reports.
Mistake 3: treating the general conditions as a form
C5 asks you to disclose where data is processed, which jurisdiction applies, how you handle government investigation requests, and which other certificates exist. BSI frames this transparency as a core purpose of the report, because customers use it in their own risk analysis. Vague answers hurt you more than honest ones that name a limit.
Mistake 4: assuming BSI will review you
BSI says it does not take part in selecting auditors and does not check audit reports. Only auditors may issue a C5 attestation, working to the ISAE 3000 framework. If you were hoping for a BSI stamp, adjust expectations and spend the effort on your auditor relationship.
Mistake 5: repeating Type 1
Type 1 means controls are suitably designed and implemented at a point in time. Type 2 adds operating effectiveness across a period. BSI recommends Type 1 only for the first audit of a service and says customers should question a provider who keeps sending Type 1 reports. Budget for a Type 2 follow up now, and start keeping period evidence on day one.
Mistake 6: picking a catalogue version by accident
C5:2020 has 121 criteria. C5:2026 has 168, split into sub-criteria, with additional criteria marked as sharpening or complementing the basic ones. BSI says C5:2026 applies to engagements dated or beginning on or after 1 June 2027, and earlier adoption is permitted. Decide with your auditor, in writing, which version applies to your first engagement.
Mistake 7: writing a policy for every criterion and calling it done
C5 criteria are testable and technology neutral. A policy states intent, but the auditor tests whether a control operates. For each criterion you need a control, an owner, a frequency and a trail of evidence.
Mistake 8: telling customers C5 settles their risk
BSI is explicit that an attestation is not the sole guarantee of secure cloud use. Customers must check whether the basic criteria fit their own use case, and they keep their own duties. Your sales material should say so too.
What to do
- Write a one page scope: services, regions, subservice organisations.
- Collect subcontractor audit reports and note any gaps.
- Draft the general conditions answers and have legal review them.
- Confirm the catalogue version with your auditor.
- Build the criterion to control to evidence sheet.
- Plan a Type 1 and a dated Type 2 follow up.
- Keep a change log of anything that alters the in scope service during the period.
Quick check
Who issues a C5 attestation?
An independent auditor, under ISAE 3000. BSI maintains the catalogue but does not take part in audits or review the reports.
Is one Type 1 report enough for ever?
No. BSI says a Type 1 should be used for the initial audit only and recommends Type 2 for a meaningful result.
How Safeguard helps automate this
Several of these mistakes come down to evidence arriving late or not at all. 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 between audits. That helps you start the Type 2 trail on day one. For the subcontractor question, technical evidence comes from your real code and dependencies, including scans, SBOMs and reachability, so you can show which third party components are in the service. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. Your auditor still performs the attestation.
Try the framework mapping demo full screen.
Sources
Last reviewed: 18 October 2026.
