ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A BSI C5 report review is the step most cloud customers skip: the provider sends a C5 attestation report, procurement files it, and nobody checks whether it covers the service in use or what the customer must do in return. That gap turns a strong assurance document into a filing exercise, and it is the customer, not the provider, who answers for it when a regulator asks.
This guide is for organisations buying cloud services from providers that hold a C5 report. It explains what to check in the report, how the shared-responsibility model shows up in it, how to handle subservice organisations, and what to record. If you are the provider preparing for the audit, start with our BSI C5 attestation guide instead.
Free gap assessment
Are you ready for C5:2026?
Score all 17 domains of the 2026 catalogue, free, including container management, confidential computing and the customer responsibility boundary.
Run the free BSI C5 gap assessment → or View premium report sample
C5, the Cloud Computing Compliance Criteria Catalogue published by Germany’s Federal Office for Information Security, gives cloud customers a basis to judge a provider’s security. The provider engages an auditor, who issues an attestation report against the criteria. Your review should answer five questions.
Our C5 criteria guide lists the objectives and criteria the report is measured against, and the BSI C5:2026 overview explains the revision.
Begin with the system description. It should name the cloud service, the infrastructure and locations, the people, the processes and any parts operated by others. A common trap is a report that covers a provider’s flagship platform while you are using an adjacent product that sits outside the scope. Another is a report for one region when your data sits in another. If the description is silent on something you rely on, ask the provider in writing and record the answer.
Type 1 reports describe whether controls are suitably designed at a point in time and are typically used for a first engagement. Type 2 reports test whether controls operated effectively across a period, and they give considerably more assurance. Sources differ on the minimum period for a Type 2 report, so read the dates in the report you hold and judge whether the period is long enough and recent enough for your risk. An old report leaves a gap between the end of testing and today, so ask what has changed since.
Cloud security is not the provider’s job alone. C5 describes responsibilities as shared: the further you move from infrastructure services toward software services, the more responsibility shifts to the provider, but the customer remains accountable for its own data classification and access control. Advisers put it plainly: customers should read the report for what they must implement on their side, not only for what the provider demonstrates.
Practically, build a table from the report. In one column, list each customer-side expectation. In the next, name your internal owner. In the third, record the evidence that you meet it. Typical items include managing your own user accounts and privileges, configuring encryption and logging options the service offers, classifying and labelling data, and reviewing the provider’s notices. Our guide to complementary user entity controls explains the same idea in the SOC context, and the mapping in BSI C5 vs SOC 2 shows where the two overlap.
| Report section | What to check | What to record |
|---|---|---|
| System description | Service, regions and locations covered | Match to your contract and usage |
| Auditor’s opinion | Qualifications and emphasis of matter | Your view of their effect on you |
| Deviations | Control failures and management responses | Risk rating and follow-up |
| Customer-side controls | What you must operate | Owner and evidence per item |
| Subservice organisations | Method used and monitoring described | Whether you need more assurance |
Most cloud providers run on infrastructure supplied by another company. C5 allows the provider to use either the inclusive method, which brings the subservice organisation’s controls into the audit, or the carve-out method, which excludes them and documents how the provider monitors them. Commentary on C5:2026 states that the catalogue warns against using carve-out as a way to avoid demonstrating conformity, and that the provider remains accountable either way.
For a customer, the important point is what the report says the provider does to watch its own suppliers. Look for named providers, the assurance the provider obtains from them, and any complementary controls the provider expects from them. The same logic applies to carve-out in other frameworks, which we cover in our SOC 1 subservice organization guide.
A report with deviations is not automatically a bad report, and a clean one is not automatically enough. Read each deviation, the control affected, the number of instances, the provider’s explanation and the remediation date. Ask whether the affected control matters for your data. A logging exception on a service you use for public content is a different matter from an access control exception on the system that stores personal data. Record your conclusion and, where needed, your compensating measures.
A hospital group in Germany intends to move a patient scheduling application to a software service. The provider shares its C5 Type 2 report. The reviewer confirms the scheduling module is inside the scope, notes that the hosting region matches the contract, and finds two deviations, one on timely revocation of leaver accounts. The report lists customer-side expectations: the hospital must manage its own user provisioning and enable multi-factor authentication. The reviewer records both, assigns owners in IT, and asks the provider to describe its remediation. The example is illustrative and does not describe any real provider.
The outcome of a BSI C5 report review should feed contracts and risk decisions, not sit in a folder. If the report is stale or narrow, add a clause requiring the provider to deliver a new report on a schedule and to notify you of any qualified opinion. If a deviation matters to you, ask for a dated remediation commitment. If the provider relies on a subservice organisation with no visible assurance, request a summary of how it is monitored. Where gaps remain, record the residual risk and have a named manager accept it, or plan compensating controls on your side such as extra logging, stricter access review or encryption under your own keys.
Link the review to your exit plan as well. If a provider loses its attestation or the report turns unfavourable, you need to know how you would move the workload, where your data can be exported and how long that takes. A review that ends with an accepted risk and a tested exit route is a much stronger position than one that ends with a filed PDF.
Keep a single review record per provider. It should hold the report and its date, the reviewer, the scope check, the opinion summary, the deviation log, the customer-side controls table with owners, the subservice conclusion, the decision to accept or escalate, and the next review date. Set the review on a yearly cycle, tied to the provider’s report renewal, and add an unscheduled review after any significant incident or a change in the provider’s supply chain. This record is what a supervisor or an internal auditor will ask to see. For a wider method, see our third-party risk assessment guide.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
A repeatable review needs a checklist, a customer-controls register, a deviation log and a summary form for management. The BSI C5:2026 Cloud Toolkit includes templates for the provider side of C5, and the same structure helps customers organise their own checks. For the source material, consult the C5:2026 catalogue from the BSI, and read your provider’s report against it.
Usually the security or vendor risk team, with input from the business owner of the service and legal where contract terms are affected.
No. It is an attestation report from an independent auditor, which you must read for scope, opinion, deviations and customer-side controls.
No. C5 assumes shared responsibility, and you remain accountable for controls on your side, such as access management and data classification.
At least annually, when the provider issues a new report, and after any significant change or incident.
September 30, 2026
