BSI C5 (Cloud Computing Compliance Criteria Catalogue)

Introduction to BSI C5

The Cloud Computing Compliance Criteria Catalogue (Cloud Computing Compliance Controls Catalogue), universally abbreviated as BSI C5, is the cloud-security assurance framework published by the German Federal Office for Information Security (Bundesamt fuer Sicherheit in der Informationstechnik, BSI). First issued in 2016 and comprehensively revised in 2020 (the current baseline commonly referred to as C5:2020), it defines a minimum baseline of information-security controls that cloud service providers (CSPs) must demonstrate to customers, particularly customers in the German public sector, regulated industries and enterprises with elevated data-protection obligations. Unlike a certification scheme, BSI C5 is delivered as an independent third-party attestation report produced by an audit firm under the international assurance standard ISAE 3000 (and, in Germany, the equivalent IDW PS 951 / AssS 5100), giving customers audited evidence rather than a self-declared badge.

This deep-dive is written for two audiences at once: the auditor or assessor who must plan and execute a C5 attestation engagement, and the implementer or CISO team at a cloud provider (or a cloud customer performing supplier due diligence) who must build, evidence and operate the underlying controls. It enumerates every C5 control domain, explains the Type 1 versus Type 2 attestation model, the basic-versus-additional criteria tiering, the mandatory supplementary information (system description, environment parameters, complementary customer controls), and maps C5 to adjacent frameworks such as ISO/IEC 27001, SOC 2, the EU Cloud Services scheme (EUCS) and the German BSI IT-Grundschutz.

What is BSI C5

BSI C5 is a catalogue of cloud-specific information-security requirements that a CSP's control environment is measured against by an independent auditor. The output of a C5 engagement is not a certificate but an attestation report (Pruefungsbericht) containing the auditor's opinion on whether the CSP's controls are suitably designed and, in a Type 2 engagement, operating effectively across a defined period. Because the report is grounded in ISAE 3000, it is internationally recognised and directly comparable to a SOC 2 report in structure, while the control content is tailored to cloud risks and German regulatory expectations.

The framework was created to solve a specific market failure: cloud customers, especially in government and regulated sectors, could not easily and consistently assess whether a provider's security posture met a credible minimum baseline. C5 standardises that baseline and forces transparency through mandatory environment disclosures. Key characteristics include:

• Attestation, not certification — a qualified auditor issues an ISAE 3000 / IDW PS 951 opinion; there is no BSI-issued certificate or logo.
• Two report types — Type 1 (design and implementation at a point in time) and Type 2 (design plus operating effectiveness over a period, typically 6 to 12 months).
• Two criteria tiers — Basic Criteria (mandatory baseline) and Additional Criteria (for higher assurance / higher-confidentiality workloads).
• Mandatory transparency — the CSP must publish system description and environment parameters covering jurisdiction, data location, subcontractors, investigation and disclosure practices, and certifications.
• Shared-responsibility clarity — C5 requires the CSP to state Complementary Customer Controls (CCCs): controls the customer must operate for the overall system to be secure.
• Cloud-native scope — controls address multi-tenancy, virtualisation, container and orchestration security, portability and interoperability, and cloud incident response.

C5:2020 expanded the 2016 edition from roughly 114 to 121 basic criteria across 17 domains, added new subject areas (notably product security / DevOps, and enhanced dealing-with-investigation-requests disclosures), and aligned more closely with ISO/IEC 27001 Annex A and CSA CCM to reduce duplicate audit effort.

Who must comply and scope of applicability

BSI C5 is not a statute; no organisation is legally forced to obtain a C5 attestation by the catalogue itself. However, compliance is effectively mandatory in a growing set of procurement and regulatory contexts, and voluntary but commercially decisive in many others. The table below summarises who is in scope and why.

Scope boundaries within a CSP

• The scope is defined by the CSP as a specific cloud service (or set of services), with a named service model (IaaS/PaaS/SaaS), deployment model, and the supporting infrastructure, applications and processes.
• Corporate IT that does not support the in-scope service can be excluded, but must be delineated clearly in the system description.
• Subservice organisations (e.g., a colocation data-centre or an upstream IaaS) are handled by the inclusive method (carve-in, audited within scope) or the carve-out method (excluded, with reliance placed on the subservice provider's own attestation).
• The reporting period (Type 2) and reporting date (Type 1) must be stated; a typical Type 2 period is 6 or 12 months.

Structure of BSI C5

C5:2020 organises its criteria into 17 subject-area domains. Each domain contains a set of basic criteria (the mandatory baseline) and, for some, additional criteria for higher assurance. Every criterion carries an identifier (a two-to-four-letter domain prefix plus a number, e.g., OIS-01, IDM-08, PS-03). Surrounding the criteria are mandatory environment/transparency disclosures. The table lists the domains and their conventional prefixes.

In addition to the 17 domains, the CSP must supply mandatory supplementary information: (a) a System Description of the service; (b) Environment Parameters (Rahmenparameter) covering jurisdiction, availability, data location, disclosure of investigation requests, certifications and audits; and (c) Complementary Customer Controls (CCCs).

Master assessment checklist

This is the operational heart of the guide. Each h3 below corresponds to one C5 domain. For every domain, the table gives representative criterion identifiers, what the auditor must verify, and the typical evidence a CSP should present. Together these cover all 17 domains plus the mandatory environment and shared-responsibility disclosures. No control area is omitted.

OIS — Organisation of Information Security

SP — Security Policies and Instructions

HR — Personnel

AM — Asset Management

PS — Physical Security

OPS — Operations

IDM — Identity and Access Management

CRY — Cryptography and Key Management

COS — Communication Security

PI — Portability and Interoperability

DEV — Procurement, Development and Modification of Information Systems

SSO — Control and Monitoring of Service Providers and Suppliers

SIM — Security Incident Management

BCM — Business Continuity Management

COM — Compliance

INQ — Dealing with Investigation Requests from Government Agencies

PSS — Product Security

Environment parameters and complementary customer controls (mandatory disclosures)

Scoping and materiality / tiering

C5 scoping decisions determine both audit cost and the assurance value of the resulting report. The principal levers are: which service(s) are in scope, whether Basic or Basic-plus-Additional criteria are covered, whether the engagement is Type 1 or Type 2, and how subservice organisations are treated.

• Service scope — define the specific cloud service(s), service model (IaaS/PaaS/SaaS) and the supporting infrastructure and processes. Broader scope means broader assurance but more evidence.
• Criteria tier — Basic Criteria are mandatory for any C5 report. Additional Criteria are elective and target workloads with elevated confidentiality/integrity/availability needs; including them materially raises assurance and effort.
• Report type — Type 1 (design at a date) is faster and suits first-year readiness; Type 2 (operating effectiveness over a period) is what most enterprise and regulated customers ultimately require.
• Subservice method — carve-in (inclusive) audits the subservice within scope; carve-out excludes it and relies on the subservice provider's own attestation plus CCCs. The choice must be consistent and disclosed.
• Materiality — the auditor sets materiality for control deviations; a control with a deviation may still yield an unqualified opinion if compensating controls or immateriality are demonstrated, otherwise the opinion is qualified.

Implementation approach

A pragmatic C5 programme runs in five phases. Each phase lists key activities and the deliverables a CISO team should produce.

Phase 1 — Scoping and gap assessment

• Activities: define in-scope service and boundaries; choose Basic vs Additional and Type 1 vs Type 2; map existing ISO 27001 / SOC 2 controls to C5 domains; run a gap assessment across all 17 domains and environment parameters.
• Deliverables: scope statement, C5-to-existing-control mapping, gap register with owners and target dates, subservice inventory and method decision.

Phase 2 — Remediation and control build

• Activities: close gaps (policies, PAM/MFA, logging/SIEM, backup and DR testing, vulnerability-management SLAs, product/DevOps hardening, crypto/key management, supplier clauses); establish evidence-capture at source.
• Deliverables: updated policy library, hardened baselines, remediation-closure evidence, control-operation records begin accruing.

Phase 3 — System description and environment parameters

• Activities: author the system description; complete environment parameters (jurisdiction, data location, availability, investigation-request handling, certifications); define Complementary Customer Controls.
• Deliverables: signed system description, environment-parameter table, CCC list, customer-facing shared-responsibility matrix.

Phase 4 — Attestation engagement

• Activities: engage a qualified ISAE 3000 / IDW PS 951 auditor; support walkthroughs, design testing and (for Type 2) operating-effectiveness sampling across the period; remediate any exceptions where possible.
• Deliverables: auditor evidence packages, exception log with responses, draft attestation report.

Phase 5 — Report, publish and sustain

• Activities: finalise the report and opinion; distribute under NDA to customers; feed findings into continual improvement; schedule the next annual Type 2 period and monitor control health continuously.
• Deliverables: signed attestation report, distribution register, corrective-action plan, next-cycle audit calendar.

Maturity / capability model

Although C5 issues a binary attestation opinion rather than a maturity score, CSPs benefit from tracking control maturity internally to predict audit readiness and prioritise investment. The following five-level model is a practical lens for C5 readiness.

Assessment and audit approach

A C5 attestation follows the ISAE 3000 assurance methodology. The typical engagement steps are:

1. Engagement acceptance and scoping — agree the service scope, criteria tier (Basic / Additional), report type (Type 1 / Type 2), reporting period and subservice method.
2. Understand the system — review the system description and environment parameters; perform walkthroughs of each domain to understand control design.
3. Assess control design — evaluate whether controls, if operating, would meet each applicable criterion; identify design gaps.
4. Test operating effectiveness (Type 2 only) — select samples across the reporting period and test each control's operation using inspection, observation, inquiry and re-performance.
5. Evaluate deviations — assess exceptions for severity and pervasiveness against materiality; consider compensating controls.
6. Form the opinion — conclude unqualified, qualified, adverse or disclaimer; document the basis.
7. Report — issue the attestation report containing management's assertion, the system description, the control matrix with test results, and the auditor's opinion, plus CCCs and subservice reliance.
8. Distribute and monitor — release the report to customers under confidentiality; feed exceptions into remediation for the next cycle.

Evidence request list

Auditors typically request the following evidence categories. CSPs should assemble these in an evidence repository ahead of fieldwork.

• Governance and ISMS: ISMS scope, security policy, risk methodology and register, treatment plan, management-review minutes, org chart, ISO 27001 certificate.
• Policies and procedures: full policy library with version history, review dates and communication/acknowledgement records.
• Personnel: screening policy and confirmations, NDAs, training curriculum and completion reports, leaver/deprovisioning records.
• Asset and data: asset register/CMDB, classification scheme, media-handling and disposal certificates.
• Physical and environmental: data-centre access lists and reviews, visitor logs, UPS/generator and fire-suppression test records, DCIM dashboards.
• Operations: capacity plans, AV/EDR coverage, backup and restore-test reports, logging/SIEM configuration and retention, patch/vulnerability-scan reports, penetration-test reports, change-management records.
• Identity and access: JML workflow, MFA and PAM configuration, access-recertification records, secrets-management evidence.
• Cryptography: crypto policy, TLS/at-rest encryption configs, key-management and HSM records, rotation logs.
• Network and communication: architecture diagrams, segmentation and firewall configs, DDoS-mitigation and IDS/IPS logs.
• Development and product: SDLC policy, SAST/DAST/SCA reports, CI/CD approvals, image-scan and orchestration-hardening evidence.
• Suppliers: supplier inventory and risk assessments, contract security schedules, DPAs, subservice attestations (SOC 2 / C5).
• Incident and continuity: IR plan, incident tickets and post-incident reviews, customer-notification records, BIA, BC/DR plans and test reports.
• Compliance and legal: legal/regulatory register, GDPR/BDSG analysis, internal-audit reports, records-retention schedule.
• Transparency: system description, environment-parameter table, investigation-request procedure, CCC list.

Roles and responsibilities

KPIs and metrics to track

• Percentage of applicable C5 criteria with design implemented (readiness coverage).
• Number and severity of open control gaps versus target closure dates.
• MFA and privileged-access coverage across in-scope systems (target 100%).
• Mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.
• Percentage of critical/high vulnerabilities remediated within SLA.
• Patch compliance rate across in-scope infrastructure.
• Backup success rate and successful restore-test rate.
• DR test frequency and RTO/RPO achievement against objectives.
• Access-recertification completion rate and orphaned-account count.
• Security-awareness training completion and phishing-simulation failure rate.
• Number of audit exceptions per cycle and time to remediate them.
• Subservice-provider attestation coverage (percentage of material subservices with current C5/SOC 2).
• Customer-incident-notification adherence to the committed SLA.

Readiness checklist

• Service scope, criteria tier (Basic / Additional) and report type (Type 1 / Type 2) are defined and agreed.
• ISMS is established, documented and approved by management.
• All 17 C5 domains have documented policies and implemented controls.
• Risk register, treatment plan and residual-risk acceptance are current.
• MFA and privileged-access management are enforced across in-scope systems.
• Logging/SIEM captures security events with protected retention.
• Vulnerability scanning, penetration testing and patch SLAs are operating.
• Encryption at rest and in transit with documented key management is in place.
• Network segmentation isolates tenants and zones; boundary and DDoS controls operate.
• Secure SDLC, image scanning and orchestration hardening (PSS) are evidenced.
• Incident-response plan tested; customer-notification SLA defined.
• BIA, BC/DR plans and DR tests completed within the period.
• Supplier/subservice inventory, risk assessments and contracts (with DPAs) are current.
• System description, environment parameters and CCCs are authored and signed.
• Investigation-request handling and jurisdiction disclosure are documented.
• Evidence repository assembled and mapped to each C5 criterion.
• Qualified ISAE 3000 / IDW PS 951 auditor engaged.

Common gaps and findings

• Incomplete or inaccurate system description and environment parameters that do not match the actual environment.
• Complementary Customer Controls (CCCs) missing or not communicated to customers, blurring shared responsibility.
• MFA not enforced for all privileged and remote access; standing (non-time-bound) admin rights.
• Insufficient log retention or unprotected logs; gaps in admin-activity logging.
• Vulnerability and patch remediation without defined or met SLAs; growing exception backlog.
• Backups not restore-tested, or DR plans documented but never exercised within the period.
• Weak subservice governance: no current attestation from material subservice providers, or inconsistent carve-in/carve-out treatment.
• Product-security (PSS) gaps: unscanned container images, unhardened orchestration, insecure default configurations.
• Change management bypassed for emergency changes without retrospective approval.
• Investigation-request process undefined, or jurisdiction/data-location disclosure incomplete.
• Access recertification overdue; orphaned or shared accounts persisting.
• Evidence produced retrospectively for the audit rather than generated at source during the period (a common Type 2 failure).

BSI C5 mapped to other frameworks

C5 was deliberately aligned with mainstream frameworks to reduce duplicate audit effort. The mapping below is indicative; a formal crosswalk should be maintained per criterion.

Frequently asked questions

Need help with BSI C5?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.