BSI C5 Explained: Attestation, Type 1 and Type 2

If you buy cloud services for a regulated organisation, sooner or later someone will ask whether the provider holds a C5 attestation. The BSI C5 is neither a law nor a certificate in the usual sense — it is an audit scheme that makes the security of a cloud service verifiable by an independent third party. This guide explains what a C5 report contains, who asks for one, and what separates a Type 1 from a Type 2 attestation.

What is the BSI C5?

The BSI C5 (Cloud Computing Compliance Criteria Catalogue) is a catalogue of security requirements published by the German Federal Office for Information Security (BSI), against which a cloud provider has a specific service audited by an independent auditor.

The current edition is C5:2020, which replaced the original 2016 catalogue. The audit itself is not performed by the BSI. It is carried out by an auditor under the international assurance standard ISAE 3000 (Revised); German audit firms may additionally reference national auditing standards in the report.

What comes out at the end is not a certificate with a seal, but an attestation report — in German, a Testat. The report contains three things a reader can work with: a system description written by the provider, the auditor's opinion on the criteria examined, and a list of any deviations found. That readability is the point of the scheme. C5 is designed so that a customer reads the report and forms their own judgement, rather than trusting a logo on a website.

Who needs a BSI C5 attestation?

No law requires a BSI C5 attestation. C5 is voluntary and is demanded contractually — most often by public-sector buyers, organisations in regulated sectors, and large enterprises that run a formal supplier assurance process.

Whether it matters for your own procurement usually comes down to three questions:

• Your regulatory frame: does your own supervisory regime, sector rulebook or internal audit require documented evidence about outsourced IT services? If so, an existing attestation is the cheapest way to produce that evidence.
• The data involved: the more sensitive the data you place in the service, the higher the burden of justification for choosing one provider over another.
• Contractual pressure downstream: many enterprise and public tenders name C5 explicitly in the requirements catalogue, which turns a voluntary scheme into a hard gate for the bidder.

graph TD
    A["You are selecting or reviewing a cloud service"] --> B{"Does your own regulatory frame require evidence about service providers?"}
    B -- yes --> C["A C5 report is the most common way to supply that evidence"]
    B -- no --> D{"Does a tender, customer or internal audit ask for C5 by name?"}
    D -- yes --> C
    D -- no --> E["C5 is optional here; ISO/IEC 27001 or a SOC 2 report may be sufficient"]
    C --> F["Read the report: scope, period, deviations, customer duties"]

This page does not tell you whether you are obliged to demand C5 — that depends on your sector and your own legal advice. It gives you the criteria to apply to your situation.

What does the C5 catalogue require?

The C5:2020 catalogue groups its security criteria into seventeen subject areas covering the full lifecycle of a cloud service, and each criterion carries a basic requirement plus, in many cases, an additional requirement for higher protection needs.

Rather than reading it article by article, it helps to see the catalogue in themes:

Two features distinguish C5 from a generic security standard.

The first is the environment parameters. The provider must disclose contextual facts about the service — such as the jurisdiction it operates under, the locations at which data is processed and stored, and the subcontractors involved. These are not security controls; they are disclosures that let a customer assess legal and geographic risk. ISO/IEC 27001 has no direct equivalent.

The second is the set of complementary customer controls. C5 recognises that a cloud service is only secure in combination with how the customer uses it. The report states which controls remain the customer's responsibility — key management, access rights, backup strategy, configuration. A provider's attestation therefore never covers your side of the shared-responsibility line.

Type 1 or Type 2: what is the difference?

A Type 1 attestation confirms that the described controls were suitably designed and in place at a single reporting date, while a Type 2 attestation additionally confirms that those controls operated effectively throughout a defined observation period.

For supplier evaluation, Type 2 is the stronger statement. That does not make Type 1 empty. A Type 1 attestation is the normal first step: a provider establishes and documents the control set, has its design confirmed, and then extends the scope to an observation period for a subsequent Type 2 report. What matters when you read a Type 1 report is that its scope is unrestricted and current — an unrestricted opinion with no qualifications says the auditor found the design of the examined controls appropriate.

What does a C5 attestation cost and how long does it take?

There is no published price for a C5 attestation, because the cost is driven by scope and existing maturity rather than by a fee schedule, and it is negotiated with the audit firm for each engagement.

The main drivers are worth understanding even as a buyer, because they explain why some providers hold an attestation for one product only:

• Scope: how many services, sites and data centres fall inside the audited boundary. A narrow scope is cheaper and says less.
• Existing management system: an organisation already running a certified ISMS has much of the evidence base in place.
• Type: a Type 2 report requires an observation period before the audit can even conclude, so the calendar cost is at minimum that period plus fieldwork and reporting.
• Recurrence: attestations age. Reports are renewed on a cycle, so the cost is annual, not one-off.

How do you read a C5 report?

A C5 report is only useful if you actually open it, because the cover page tells you nothing about scope, period or exceptions — the four facts that determine whether the attestation covers what you are buying.

• Scope: which services, product tiers and locations are named? An attestation for one platform does not extend to a provider's whole portfolio.
• Period and date: for Type 2, which observation window? For Type 1, which reporting date? A report from three years ago describes a system that no longer exists.
• Deviations and qualifications: does the auditor's opinion carry restrictions, and how were findings remediated? An unrestricted opinion is the relevant marker.
• Complementary customer controls: which duties does the report hand back to you? These become work items in your own security concept.
• Additional criteria: were only the basic requirements audited, or also the additional requirements for higher protection needs?

Providers usually release the full report under NDA rather than publicly. If a provider will not share the report at all, you have a marketing claim, not evidence.

How does C5 relate to ISO 27001, SOC 2 and NIS2?

BSI C5 examines the controls of a specific cloud service and produces an auditor's report, whereas ISO/IEC 27001 certifies a management system, SOC 2 follows a comparable report mechanic under US criteria, and NIS2 is binding law rather than an audit scheme.

In practice these overlap heavily. An organisation running ISO/IEC 27001:2022 has already built much of what C5 asks for, and the BSI publishes mappings to help reuse existing evidence — but the catalogues do not coincide, and the C5 transparency criteria have no ISO counterpart at all.

Two caveats on the moving parts. NIS2 obliges in-scope entities to manage supply-chain risk, and a provider attestation is a practical way to discharge that duty — but NIS2 does not name C5, and the German transposition (the NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) has had a long legislative path; check the current status and the resulting scope thresholds with the BSI rather than relying on a summary. Separately, the planned EU-wide cloud certification scheme (EUCS) under the Cybersecurity Act has been in preparation at ENISA for years and has not replaced national schemes; treat its status as open until ENISA says otherwise.

What happens if a provider has no C5 attestation?

Nothing happens legally: C5 carries no sanctions, no fines and no supervisory consequence, because it is a voluntary audit scheme rather than a legal obligation. The consequences are commercial and administrative.

Without a report, the evidence burden moves to you. You either exercise contractual audit rights yourself, work from an ISO/IEC 27001 certificate plus a Statement of Applicability, accept a SOC 2 report as a substitute, or run a questionnaire-based assessment. All of those are legitimate; all of them cost more of your own time than reading an existing attestation. And in tenders that name C5 as a requirement, the absence of a report is simply disqualifying.

Where do the binding statements come from?

The only authoritative source for the criteria is the C5 catalogue itself, published by the BSI in its currently valid edition and available from the BSI website; the audit mechanics come from ISAE 3000 (Revised), issued by the IAASB.

For the question of whether a particular provider holds an attestation, and for what, the report is the only reliable source. Scope statements in a datasheet are not a substitute, and no summary — including this one — can tell you whether a given attestation covers your use case. Where a threshold or deadline in a neighbouring regime matters to your decision, verify it against the regulation or the BSI rather than a secondary description, and take legal advice on your own obligations.

centron holds a BSI C5:2020 Type 1 attestation with an unrestricted opinion for ccloud³ / Managed Cloud, alongside ISO/IEC 27001, ISO 9001 and ISO 14001. The underlying documents for your own supplier assessment are available in the Trust Center.

More on compliance

• The CLOUD Act and Its Impact on European Companies
• DORA: What the Regulation Means for IT Providers
• ISO 27001: Requirements, Process and Effort
• NIS2: Who Is Affected and What Must Be Done?