↓ Skip to main content
Le Site de François
  1. Index/

BSI C5

Compliance Germany Cloud Bsi Audit
Table of Contents

The BSI C5 (Cloud Computing Compliance Criteria Catalogue) is a German federal standard published by the BSI that defines minimum security requirements for cloud service providers. First released in 2016, the catalogue has undergone two major revisions: C5:2020 and the current C5:2026 (published 7 April 2026, replacing C5:2020). C5:2026 contains 168 criteria (up from 121 in C5:2020, a 39 % increase) structured across 17 domains aligned with ISO/IEC 27001 Annex A. The new version introduces a sub-criteria structure aligned with the European EUCS scheme, and adds five major new requirement areas: Confidential Computing (OPS-32/33: documented policies for Trusted Execution Environments and technical implementation of Remote Attestation), Container Management (OPS-34/35: lifecycle security for containerized workloads), Post-Quantum Cryptography (inventory of cryptographic assets and migration plan to quantum-resistant algorithms), AI transparency (disclosure of AI use in internal control systems), and Supply Chain Security (SBOM requirements, documented sub-processor audits). The catalogue is published in machine-readable YAML format for the first time. C5 is designed as an attestation standard (not a certification): providers undergo a Type 2 audit by an independent auditing firm (under IDW PS 880 or ISAE 3000), which verifies both the design and operational effectiveness of security controls over a period of at least six months. C5 is now effectively mandatory in two key domains: since 1 July 2025, cloud providers processing healthcare data must hold a valid C5 Type 2 attestation under §393 SGB V (Social Code, Fifth Book), and the revised BSI-KritisV (2024) requires KRITIS operators to use C5-attested cloud services in security-relevant contexts. Public-sector procurement in Germany also increasingly demands C5 attestation. C5:2026 becomes mandatory on 1 June 2027 for all audit periods starting on or after that date. During the transition: C5:2020 audits remain valid without additional requirements until 28 February 2027; between 28 February and 31 May 2027, C5:2020 is still permitted but requires a transition roadmap to C5:2026 in the system description.

Red Hat enables cloud service providers and their customers to satisfy C5 requirements at the platform layer — and is particularly well-positioned for the new C5:2026 requirements. For the new Confidential Computing criteria (OPS-32/33): Red Hat OpenShift sandboxed containers with Trustee provide exactly the TEE and Remote Attestation capabilities C5:2026 demands, allowing CSPs to demonstrate hardware-enforced data-in-use protection with cryptographically verified execution environments. For Container Management (OPS-34/35): the OpenShift Compliance Operator, RHACS image scanning, and the Trusted Software Supply Chain portfolio address the full container lifecycle security requirements. For Post-Quantum Cryptography: RHEL’s crypto-agile architecture and system-wide cryptographic policies enable providers to inventory their cryptographic usage and plan migration paths. For the established C5 criteria, Red Hat covers cryptography (domain 10) with FIPS 140-3 validated modules; operations security (domain 12) with the Compliance Operator, Ansible for automated hardening, and RHACS for runtime threat detection; and supplier relationships (domain 15) with SBOMs, Sigstore artifact signing, and CSAF/VEX vulnerability feeds — directly satisfying C5:2026’s new SBOM mandate. C5’s corresponding criteria (Korrespondierende Kriterien), which define the cloud customer’s responsibilities at the interface with the provider, are also relevant: Red Hat’s documentation of shared responsibility models for OpenShift Dedicated and ROSA helps customers understand exactly which C5 controls they inherit from the provider versus those they must implement themselves. For German healthcare organizations subject to the §393 SGB V mandate, running workloads on a C5-attested cloud infrastructure built on RHEL and OpenShift provides a clear compliance path.

Additional Information
#

Related

BSI IT-Grundschutz

Compliance Germany Isms Bsi Iso-27001
BSI IT-Grundschutz is Germany’s national framework for establishing, implementing, and certifying an Information Security Management System (ISMS). It is developed and maintained by the BSI (Bundesamt für Sicherheit in der Informationstechnik) and stands out from generic standards like ISO/IEC 27001 by its extreme level of prescriptive detail — the IT-Grundschutz Compendium contains hundreds of specific security building blocks (“Bausteine”) covering technical, organizational, infrastructure, and personnel aspects. The framework is defined across four BSI Standards: 200-1 (ISMS requirements), 200-2 (methodology with three approaches: Basis-Absicherung, Standard-Absicherung, Kern-Absicherung), 200-3 (risk analysis), and 200-4 (business continuity management). Organizations can pursue ISO 27001 certification based on IT-Grundschutz, which is recognized as equivalent to standalone ISO 27001 but with the added rigor of the BSI’s detailed control catalog. Compliance is mandatory for German federal agencies (Bundesbehörden) under the UP Bund framework and is strongly recommended — often contractually required — for KRITIS operators and public-sector contractors. A major modernization is underway: Grundschutz++, introduced in 2025–2026, replaces the traditional PDF-based building blocks with OSCAL/JSON machine-readable catalogs, aligning with the NIS2 implementation requirement for a BSI-defined “state of the art.” The classic IT-Grundschutz remains valid for audits until end of 2028.

KRITIS (German Critical Infrastructure)

Compliance Germany Critical-Infrastructure Nis2 Bsi
KRITIS (Kritische Infrastrukturen) is Germany’s national regulatory framework for the security and resilience of critical infrastructure. It is enforced by the BSI (Bundesamt für Sicherheit in der Informationstechnik — Federal Office for Information Security) and, for physical resilience, by the BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe — Federal Office of Civil Protection). The framework is now governed by two primary laws: the NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), which rewrote the BSI-Gesetz and entered into force on 6 December 2025, and the KRITIS-Dachgesetz (KRITISDachG) for physical resilience, in force since 17 March 2026. Together they transpose the EU NIS2 Directive and CER Directive into German law. The scope expanded dramatically: from approximately 4,000 regulated entities under the previous IT-Sicherheitsgesetz 2.0 to around 30,000 entities now classified as either “besonders wichtige Einrichtungen” (particularly important, equivalent to NIS2 essential) or “wichtige Einrichtungen” (important). KRITIS applies to organizations in 18 sectors (energy, water, health, finance, transport, digital infrastructure, space, public administration, manufacturing, etc.) meeting defined size thresholds. Compliance is mandatory with no transitional period: entities must register with the BSI, implement risk management (§30 BSIG), report security incidents within 24 hours (§32), and management is personally liable (§38) for overseeing cybersecurity measures. Penalties reach up to €10M or 2 % of global turnover for particularly important entities.

SOC 2

Compliance Usa International Audit Cloud
SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants). It is not government legislation or a certification scheme but a voluntary attestation standard — however, it has become a de facto market requirement for any technology company, cloud service provider, or SaaS vendor serving enterprise customers, particularly in the US. A SOC 2 report is produced by an independent CPA firm that evaluates an organization’s controls against the AICPA’s Trust Services Criteria (TSC), organized in five categories: Security (mandatory for all SOC 2 reports, covering Common Criteria CC1–CC9), Availability, Processing Integrity, Confidentiality, and Privacy (each optional depending on the organization’s services and customer commitments). The Common Criteria (CC1–CC9) are derived from the COSO Internal Control Framework and cover control environment, risk assessment, monitoring, logical/physical access, system operations, change management, and risk mitigation. There are two report types: Type I (evaluates control design at a point in time) and Type II (evaluates both design and operating effectiveness over 6–12 months — the standard enterprise customers demand). SOC 2 reports are restricted-use documents shared with customers under NDA. While not legally mandatory, major enterprises, financial institutions, and regulated industries routinely require SOC 2 Type II reports from their vendors before signing contracts, making it an essential market-access requirement for technology service providers.