Definition: BSI C5
BSI C5 is an audit-based criteria catalogue from Germany’s Federal Office for Information Security that sets minimum security requirements a cloud provider must prove through an independent auditor’s attestation report.
Core characteristics of BSI C5
C5 is proven through an attestation from a qualified external auditor, not a certificate issued by BSI itself, and it covers the specific cloud service in scope, not the provider’s whole organization. It should not be confused with BSI IT-Grundschutz, BSI’s broader security methodology for organizations in general rather than cloud services specifically.
- Structured around 17 subject areas, from organization of information security to procurement and incident management
- Requires an independent auditor’s report rather than a BSI-issued certificate
- Distinguishes Typ 1 (control design at one point in time) from Typ 2 (effectiveness over six months)
- Covers only the specific in-scope services named in the report
BSI C5 vs. ISO 27001
ISO 27001 certifies that an organization runs a structured security management system across its whole business, using controls it selects itself. C5 instead prescribes a fixed, cloud-specific criteria set, proven through an auditor’s report rather than a certificate, similar to SOC 2 in the US market. The two are complementary: a provider can hold an ISO 27001 certificate for its ISMS and a C5 Typ 2 report for one service, and BSI has published a mapping between C5 and SOC 2. For Mittelstand buyers, ISO 27001 says a vendor runs security well in general; C5 says the specific cloud service meets Germany’s cloud expectations.
Importance of BSI C5 in enterprise AI
C5 matters for AI-enabled organizations because most enterprise AI runs on hyperscaler infrastructure, making the provider’s attestation the first checkpoint in an AI deployment review. A 2025 Bitkom Cloud-Report found 97 percent of German companies say provider trustworthiness matters in vendor selection, with security and compliance ranked the top criterion. Teams running AI vendor risk management increasingly request a current C5 report before approving a cloud AI platform for production.
Methods and procedures for BSI C5
Achieving a C5 attestation follows a defined audit path, not a self-declared checklist.
Choosing between Typ 1 and Typ 2
A provider’s first C5 engagement is typically Typ 1, confirming controls are appropriately designed at one point in time. BSI recommends against repeating Typ 1 and expects providers to move to Typ 2 for ongoing assurance.
- Typ 1 verifies control design at a fixed reference date, suitable only for an initial engagement
- Typ 2 additionally tests operational effectiveness over a minimum six-month period
- Most hyperscalers and German cloud providers now maintain Typ 2 reports on a rolling annual cycle
Scoping the criteria catalogue
C5:2020 defines 121 criteria across 17 subject areas, each broken into sub-criteria mapped to a provider’s internal controls. C5:2026 expands this to 168 criteria and adds new areas for container management, confidential computing, and post-quantum cryptography.
Engaging a qualified auditor
The audit must be performed by an auditor with recognized IT specialization under the ISAE 3000 standard, the same framework underlying SOC 2 examinations. Reports are usually shared with customers under NDA rather than published, so buyers request them directly from procurement or account teams.
Important KPIs for BSI C5
Providers and buyers track a small set of measures around C5 readiness.
Attestation coverage and status
- Attestation type: Typ 1 or Typ 2
- Report age: months elapsed since the covered period ended
- Criteria coverage: subject areas addressed without noted exceptions
- Bridge letter availability: confirms continuity between report periods
Vendor due diligence depth
Procurement and security teams increasingly build C5 review into standard vendor onboarding rather than a one-off request. Bitkom’s 2025 Cloud-Report found 67 percent of German companies now make trustworthy provider origin mandatory, up from 58 percent the year before.
Exception and finding closure
Auditors document control exceptions found during the Typ 2 observation period, and how quickly a provider closes them signals operational maturity beyond the headline attestation type.
Risk factors and controls for BSI C5
C5 carries specific risks when treated as a formality rather than an ongoing process.
Treating C5 as a one-time checkbox
A report obtained once and never revisited drifts out of scope as a provider launches new services or regions that were never audited.
- Missing scope changes when new services or regions launch
- Letting the report expire without requesting a renewal or bridge letter
- No internal owner tracking the vendor’s attestation calendar
Confusing attestation with certification
Because C5 produces an auditor’s report rather than a BSI-issued certificate, some buyers expect a public registry to verify status, when the report itself, requested directly from the provider, is the only reliable evidence.
Underestimating AI workload scope in the report
Companies combining cloud AI with on-premise AI or sovereign AI deployments often assume the whole provider is covered, when a C5 report lists specific in-scope services only. A newly launched AI inference service can sit outside an existing attestation until the next audit cycle.
Practical example
A 140-employee industrial parts wholesaler in North Rhine-Westphalia was migrating its ERP and an AI-based invoice processing tool to a public cloud platform. Its supervisory board required proof the provider met German security expectations before approving the migration, since several customers were public-sector buyers requiring supply chain assurance. The IT lead requested the provider’s current C5 Typ 2 report and mapped its subject areas against the company’s existing supplier risk checklist instead of starting from scratch. The review closed within three weeks, well inside the project timeline, and the report became a standing reference for future vendor checks.
- Requested and reviewed the provider’s current C5 Typ 2 attestation report
- Mapped C5 subject areas against the existing supplier risk questionnaire
- Documented the bridge letter process to track continuity at renewal
- Set an annual review cadence tied to the provider’s audit cycle
Current developments and effects
C5 is entering a transition as the catalogue itself expands.
C5:2026 rollout
Published in April 2026, C5:2026 adds subject areas that did not exist before and raises the criteria count substantially.
- Criteria count rises from 121 to 168 across 17 subject areas
- New coverage for container management, confidential computing, and post-quantum cryptography
- Mandatory for audit periods starting June 1, 2027, with early adoption encouraged
Rising provider-origin scrutiny
Bitkom’s 2025 Cloud-Report found 78 percent of German companies consider the country too dependent on US cloud providers, and 67 percent now make trustworthy provider origin mandatory. Gartner forecasts worldwide sovereign cloud infrastructure spending will reach 80 billion US dollars in 2026, a trend pushing more buyers to request C5 reports earlier in the sales cycle.
C5 as a building block for sector rules
Operators subject to KRITIS obligations increasingly reference a supplier’s C5 attestation as documented evidence in their own supply chain risk assessments, reducing duplicate due diligence across overlapping frameworks.
Conclusion
BSI C5 has moved from a niche German requirement to a standard checkpoint in cloud and AI vendor selection, and the shift to C5:2026 makes the catalogue broader rather than less relevant. For Mittelstand buyers, the practical task is building a repeatable process for requesting, reviewing, and renewing vendor attestation reports rather than treating C5 as a one-time procurement question. Because C5 overlaps with ISO 27001 and increasingly with KRITIS supplier requirements, the review work invested here compounds across future vendor obligations. Companies that track attestation currency alongside their cloud AI rollout avoid the coverage gaps that most often surface when a new service enters production unreviewed.
Frequently Asked Questions
What is the difference between BSI C5 and ISO 27001?
ISO 27001 certifies that an organization runs a structured security management system across its business, with controls it chooses itself. BSI C5 prescribes a fixed, cloud-specific criteria set proven through an auditor’s report, and the two are typically held together rather than as alternatives.
Is checking for a C5 attestation worth it for a company with fewer than 200 employees?
Yes, especially before moving core systems like ERP to a new cloud or AI vendor, since a current C5 report takes little effort to request but meaningfully reduces vendor risk. It matters most for companies selling to public-sector or KRITIS customers who expect this due diligence themselves.
What does reviewing a vendor’s C5 report cost a Mittelstand company?
Requesting and reviewing an existing provider’s report typically costs nothing beyond internal staff time, since it is provided under NDA rather than commissioned by the buyer. Costs only arise if a company itself operates cloud infrastructure requiring its own C5 audit.
How does BSI C5 relate to DSGVO and the EU AI Act?
C5 does not replace DSGVO obligations, but its criteria on access control and incident management support a DSGVO-required processor assessment. Under the EU AI Act, providers of high-risk AI systems on cloud infrastructure can cite a supplier’s C5 attestation in their own risk documentation.
How long does a C5 Typ 2 attestation take a provider to obtain?
A Typ 2 report requires a minimum six-month observation period after controls are implemented, plus several weeks for the auditor to complete testing. Buyers reviewing an existing report typically finish their assessment within a few weeks.
Do we need our own IT security team to evaluate a vendor’s C5 report?
Not necessarily. Many Mittelstand companies have their IT lead or an external advisor map the report’s subject areas against their own risk checklist, a task that does not require a dedicated security function.
