BSI C5:2026 – warum der Cloud-Standard ein Branchenthema wird, kein Banken-Thema

Wer den BSI C5 immer noch als Spezialthema für Bank-IT abtut, hat die letzten zwei Jahre nicht verfolgt. Seit Juli 2024 ist ein C5-Testat über § 393 SGB V im Gesundheitswesen gesetzliche Pflicht. Bundesbehörden dürfen seit Jahren ohne C5 keine externen Cloud-Dienste mehr beauftragen. Und seit Ende März 2026 liegt der Katalog in einer grundsanierten Fassung vor – C5:2026, mit 168 statt 121 Kriterien, neuer Unterkriterien-Struktur und expliziten Anforderungen an Container-Management, Confidential Computing und Post-Quanten-Kryptografie.

Das ist kein inkrementelles Update. Es ist ein Generationswechsel, und er trifft eine Anwenderbasis, die sich vom Bundes-Rechenzentrum bis zum SaaS-Startup im Gesundheits-Tooling erstreckt. Dieser Beitrag erklärt, was wirklich neu ist, wer ab wann betroffen ist – und warum der 1. Juni 2027 die einzige Datumsangabe ist, die in der Praxis zählt.

1. Was der C5 ist – kurz und ehrlich

Der Cloud Computing Compliance Criteria Catalogue (C5) ist ein Prüfkatalog des BSI, der Mindestanforderungen an die Informationssicherheit von Cloud-Diensten definiert. Erstveröffentlichung: 2016. Erste größere Revision: 2020. Aktuelle Fassung: C5:2026, finalisiert Ende März 2026.

Das Besondere am C5 gegenüber gefühlt vergleichbaren Standards wie ISO 27001:

• Prüf-, kein Managementsystem-Standard. Geprüft werden Kontrollen am Cloud-Dienst, nicht ein Managementsystem.
• Wirtschaftsprüfer-Testat statt Zertifikat. Die Prüfung erfolgt nach ISAE 3000 (Revised) bzw. IDW PS 860 durch einen unabhängigen Wirtschaftsprüfer. Das Ergebnis ist ein Bericht, kein Logo.
• Typ 1 vs. Typ 2. Typ 1 prüft die Angemessenheit der Kontrollen zu einem Stichtag. Typ 2 prüft zusätzlich deren Wirksamkeit über typischerweise sechs bis zwölf Monate. Praktisch relevant ist fast immer Typ 2; das BSI selbst empfiehlt, mehrfach hintereinander vorgelegte Typ-1-Berichte beim Anbieter zu hinterfragen.
• Detailtiefe im Bericht. Der C5-Bericht ist kein einseitiges Zertifikat, sondern dokumentiert Kontroll für Kontrolle, was der Wirtschaftsprüfer geprüft hat – inklusive Ausnahmen, Einschränkungen und Sub-Service-Organizations.

Das ist der Grund, warum C5 in regulierten Branchen als belastbarer angesehen wird als ein bloßes ISO-27001-Zertifikat: Man bekommt einen Prüfbericht in der Hand, der eigene Risikoanalysen erst möglich macht – nicht nur eine Bestätigung, dass eine Norm „erfüllt" ist.

2. Was 2026 wirklich neu ist – nicht das Marketing, sondern die Substanz

Die offizielle BSI-Sprachregelung („nächste Generation", „Generationswechsel") lässt offen, was sich substanziell ändert. Die folgende Tabelle gibt die nüchterne Sicht.

Drei Punkte aus dieser Tabelle verdienen mehr als eine Zeile:

Unterkriterien als ernstzunehmende Strukturentscheidung. Bisher konnte ein Cloud-Anbieter eines breit formulierten Kriteriums entweder „erfüllt" oder „nicht erfüllt" haben – mit allen Auseinandersetzungen über Teilerfüllungen, die das im Audit auslöste. Der C5:2026 zerlegt jedes Kriterium in inhaltlich abgegrenzte Unterkriterien. Das vereinfacht die Zuordnung zu internen Kontrollen, schafft präzisere Audit-Befunde und macht Berichte über Anbieter hinweg vergleichbar. Wer parallel auf EUCS oder ISO 27001:2022 hinarbeitet, erspart sich redundantes Mapping.

Maschinenlesbares Format. Die YAML-Variante ist nicht nur ein Format-Gimmick. Sie ist die Grundlage dafür, Kontrolldokumentation in GRC-Plattformen, Audit-Tools und kontinuierliche Compliance-Pipelines zu integrieren. Wer 2026 einen neuen GRC-Stack aufsetzt und das nicht nutzt, lässt produktiv ein Werkzeug liegen.

Sharpen vs. Complement. Diese Unterscheidung wirkt akademisch, hat aber operative Folgen: Verschärfende Zusatzunterkriterien ersetzen Basisunterkriterien (und werden im Bericht entsprechend markiert), während ergänzende Zusatzunterkriterien zusätzlich geprüft werden. Für Cloud-Kunden mit hohem Schutzbedarf ist das die saubere Vorlage, um eigene Anforderungen anschlussfähig zu formulieren – statt eigene, nicht-anschlussfähige Kriterien zu definieren.

3. Die fünf technischen Schwerpunkte im Detail

3.1 Container-Management (OPS-34 / OPS-35)

Container-Workloads sind in produktiven Cloud-Umgebungen seit Jahren Standard. Der C5:2020 hat sie schlicht nicht adressiert – eine Lücke, die in Audits regelmäßig zu Auseinandersetzungen führte, was als „verteilte Anwendung" oder „virtuelle Maschine" zählt. C5:2026 schließt diese Lücke explizit.

OPS-34 verlangt dokumentierte Richtlinien und Verfahren für den gesamten Container-Lebenszyklus: Image-Erstellung, -Speicherung, Deployment, Betrieb, Dekommissionierung. Inhaltlich abgedeckt sind Inventarisierung, Malware-Schutz, Logging, Mandantentrennung, Zugriffskontrolle, Verschlüsselung und Netzwerksicherheit.

OPS-35 prüft die technische Implementierung dieser Richtlinien. Anbieter, die Kubernetes-Cluster betreiben, müssen also nicht nur Policies vorzeigen, sondern auch technisch belegen, dass diese Policies in Pod-Security-Standards, Network Policies, Image-Signierung und Runtime-Schutz operativ umgesetzt sind.

Praktisch heißt das: Wer als SaaS-Anbieter ein eigenes Kubernetes betreibt, muss seine Container-Security-Tooling-Landschaft inventarisieren – Image-Scanner, Admission Controller, Runtime-Security-Sensoren, Cluster-Hardening-Baselines. Das ist nicht trivial, lässt sich aber strukturieren.

3.2 Confidential Computing (OPS-32 / OPS-33)

Confidential Computing – die Verschlüsselung von Daten während der Verarbeitung mittels Trusted Execution Environments (TEEs) – ist die Antwort auf eine Klasse von Bedrohungsszenarien, die mit klassischer Transport- und At-Rest-Verschlüsselung nicht adressierbar war: kompromittierte Hypervisoren, Insider-Zugriffe auf Speicher-Dumps, Cloud-Provider als Bedrohungsmodell.

C5:2026 macht dazu konditionale Aussagen: Diese Kriterien gelten nur, wenn der Cloud-Dienst Confidential-Computing-Fähigkeiten anbietet. OPS-32 verlangt dokumentierte Richtlinien für TEE-Einsatz und Remote-Attestation; OPS-33 die technische Umsetzung der Remote-Attestation. Das ist die saubere konditionale Konstruktion: Anbieter, die kein Confidential Computing anbieten, müssen es nicht implementieren, aber Anbieter, die es vermarkten, müssen es prüfbar belegen.

Für Kunden, die etwa AMD SEV-SNP oder Intel TDX in ihrer Cloud-Architektur nutzen wollen, ist das die erste belastbare Audit-Grundlage am Markt.

3.3 Post-Quanten-Kryptografie

Der CRY-Bereich des C5:2026 ist die unspektakulärste, aber strategisch weitreichendste Neuerung. Cloud-Anbieter müssen einen dokumentierten Migrationsplan für den Übergang zu quantenresistenten Algorithmen vorweisen können. Das ist keine Implementierungspflicht zum Stichtag – es ist die Pflicht zur Inventur, Roadmap und Steuerung.

Wer die NIST-Standards aus FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) sowie die BSI-Migrationsfristen (KRITIS bis 2030, übrige Organisationen bis 2032) als „klingt nach 2030er-Thema" abgehakt hat, bekommt mit C5:2026 die erste Aufsichts-Erinnerung: Wo wird in deiner Cloud-Architektur RSA-2048 oder ECDSA eingesetzt – und wie sieht dein Migrationspfad aus?

Diese Anforderung wirkt zunächst sanft. Sie ist es nicht. Ein vollständiges kryptografisches Inventar zu erstellen, ist – gerade in gewachsenen SaaS-Architekturen mit Bibliotheken, Frameworks, Drittkomponenten und HSM-Integrationen – ein mehrmonatiges Projekt. Wer das im 2026er Audit-Zyklus zum ersten Mal sehen will, plant zu spät.

3.4 Supply Chain Management (SSO)

Die Anforderungen an die Lieferkettensteuerung wurden gegenüber C5:2020 erheblich ausgebaut. Drei Punkte stehen im Vordergrund:

• Software Bill of Materials (SBOM) für kritische Softwarekomponenten – also strukturierte Auflistung der eingesetzten Open-Source- und kommerziellen Komponenten samt Versionen.
• Regelmäßige Auditierung von Subdienstleistern und Dokumentation deren Sicherheitsnachweise (C5, ISO 27001, SOC 2).
• Verzeichnis der Service-Organisationen mit definierten Datenflüssen und Verantwortlichkeiten.

Das ist keine reine C5-Erfindung – die NIS2-Richtlinie und der Cyber Resilience Act marschieren in dieselbe Richtung. C5:2026 macht es nur konkreter. Für SaaS-Anbieter, die ihrerseits auf IaaS aufbauen, heißt das: Die eigene Lieferkettendokumentation wird zum festen Bestandteil des Kontroll-Inventars.

3.5 Multi-Tenancy und technische Souveränität

C5:2020 hat Mandantentrennung eher prozessual betrachtet. C5:2026 zerlegt sie in technische Detailanforderungen: Isolation auf Storage-, Netzwerk-, Compute- und Identity-Ebene; Schlüsselmanagement pro Mandant; Logging und Monitoring pro Mandant; Reporting an den jeweiligen Kunden.

Parallel werden Anforderungen an die technische Umsetzung von Souveränität präzisiert. Damit ist der Unterschied zwischen einem deutschen Unternehmen, das Workloads in einer „europäischen" Cloud betreibt (deren Betreiber aber außereuropäischer Jurisdiktion unterliegt), und einer tatsächlich souveränitätsfähigen Architektur prüfbar gemacht. Das ist keine Trivialität – die AWS European Sovereign Cloud (seit Januar 2026 GA) ist genau für diese Anforderungslage entstanden.

Begleitend wird das BSI in Kürze allgemeine Souveränitätskriterien veröffentlichen, die das C5-Set ergänzen sollen. Wer also heute eine Cloud-Souveränitäts-Strategie definiert, sollte den C5:2026 als technische Untergrenze verstehen, nicht als finalen Maßstab.

4. EUCS Substantial – warum die Verzahnung strategisch ist

Die Beziehung zwischen C5 und EUCS ist eine wechselseitige: Der C5:2020 diente als inhaltliche Vorlage für das geplante European Cybersecurity Certification Scheme for Cloud Services (EUCS) auf Substantial-Level. Aus dieser Arbeit entstand bei CEN/CENELEC die Technical Specification CEN/TS 18026:2024 – und diese wiederum bildete die Grundlage für den C5:2026.

Das hat zwei sehr praktische Folgen:

• Wer C5:2026 erfüllt, ist faktisch EUCS-Substantial-fähig. Sobald EUCS final wird (politisch immer noch zäh, technisch fortgeschritten), reduzieren sich Mehraufwände bei Parallelzertifizierung erheblich.
• Der C5 ist damit nicht mehr ein deutscher Sonderweg, sondern die operative Vorab-Implementierung der europäischen Cloud-Regulierung. Für international tätige Anbieter wird die Kompatibilitäts-Frage zwischen nationalen und europäischen Schemata damit deutlich weniger schmerzhaft als noch vor zwei Jahren befürchtet.

Strategisch ist der C5:2026 also weniger ein deutsches Update als die nationale Vor-Implementierung eines europäischen Standards.

5. Die Branchenrealität: Wer C5:2026 ab wann wirklich braucht

Der Kerngedanke des Beitrags – C5 ist kein Banken-Thema – wird in der folgenden Tabelle unmittelbar anschaulich.

Drei Beobachtungen dazu:

Das Gesundheitswesen ist 2025 zum zweiten Großanwender geworden. § 393 SGB V verlangt für Cloud-Dienste, die Sozial- oder Patientendaten verarbeiten, ein C5-Testat des Cloud-Anbieters. Seit 1. Juli 2025 muss es ein Typ-2-Bericht sein. Eine Übergangsmöglichkeit existiert – aber sie verlangt Gap-Analyse gegen die C5-Basiskriterien plus verbindlichen Maßnahmenplan, typischerweise mit zwölfmonatiger Umsetzungsfrist. Praktisch heißt das: Krankenhäuser, Krankenkassen, Apotheken und ihre IT-Dienstleister sind seit über einem Jahr in der Beweislage.

Versicherungen sind nicht mehr Banken-light. Die früher geltenden aufsichtsrechtlichen Detail-Frameworks für Versicherungs-IT (vormals VAIT) sind als eigenständige Aufsichtspraxis nicht mehr aktiv. Maßgeblich sind heute europäische Aufsichtsanforderungen, NIS2-Umsetzung und – für die Cloud-Beschaffung – belastbare Anbieter-Nachweise. C5 ist genau das. Wer als Versicherer Cloud-Workloads betreibt, erwartet von seinem Anbieter ein C5-Testat – nicht weil eine spezifische Norm es ausdrücklich verlangt, sondern weil die Aufsichtspraxis zur Anbieter-Steuerung diesen Nachweis als Best Practice etabliert hat.

Der Mittelstand wird mitgezogen, ohne es zu wollen. Wer als Mittelstandsunternehmen Lieferant eines NIS2-pflichtigen Kunden ist, bekommt Anforderungen an die eigene Cloud-Lieferkette weitergereicht. Der Cloud-Anbieter, der heute noch ohne C5 auskommt, weil er keine Bundesbehörden bedient, sieht im B2B-Vertrieb 2027 den ersten Ausschreibungsausschluss – nicht wegen einer Norm, sondern wegen der Lieferkettenanforderung seines Kunden.

6. C5 als Beschaffungswerkzeug – was im Prüfbericht zählt

Der unterschätzte Wert eines C5-Berichts ist nicht die Existenz, sondern der Inhalt. Anders als ein ISO-27001-Zertifikat dokumentiert ein C5-Bericht für jede Kontrolle, was geprüft wurde, was der Wirtschaftsprüfer beobachtet hat und ob es Ausnahmen oder Einschränkungen gibt.

Wer C5-Berichte in der Cloud-Beschaffung wirklich nutzen will, prüft mindestens diese Punkte:

• Scope-Definition. Welche Cloud-Dienste sind genau im Scope? Häufiger Fehler: Ein Anbieter wirbt mit „C5-Testat", geprüft wurde aber nur ein Teilservice. Wer einen anderen Service desselben Anbieters einkauft, hat keinen Nachweis.
• Berichtszeitraum. Bei Typ 2 sollte der Berichtszeitraum nicht älter als zwölf Monate sein. Mehrere aufeinanderfolgende Typ-1-Berichte sind ein Warnsignal.
• Sub-Service-Organizations. Welche externen Dienstleister sind im Bericht referenziert (Carve-out vs. Inclusive Method)? Wo liegen Verantwortungs-Übergänge?
• Ausnahmen und Einschränkungen. Fast jeder Bericht enthält welche. Die Frage ist, ob sie für deinen Anwendungsfall relevant sind.
• Korrespondierende Kundenkriterien. Der C5-Bericht definiert, was der Anbieter tut – aber auch, was der Kunde selbst tun muss (Zugriffsverwaltung, Verschlüsselung, Risikomanagement). Diese Pflichten lassen sich nicht delegieren.

Ein C5-Bericht ist kein Stempel. Er ist ein Prüfgutachten, das gelesen werden muss. Wer ihn als Stempel behandelt, verfehlt seinen Zweck.

7. Übergangsfristen: Der 1. Juni 2027 ist die einzige Zahl, die zählt

Die offiziellen Fristen sind eindeutig, aber für Anbieter und Kunden unterschiedlich relevant.

Die Kreuzreferenztabelle des C5:2026 (für Mapping zu ISO 27001:2022, CSA CCM v4 u. a.) erscheint laut BSI bis Ende Q2 2026. Wer parallele Audits plant, sollte die Veröffentlichung in seinen Projektplan einarbeiten.

Pragmatische Lesart der Fristen: Cloud-Anbieter haben effektiv 12 Monate, um Gap-Analyse, Implementierung neuer Kontrollen (insbesondere Container, Confidential Computing, PQC-Migrationsplan, SBOM, Subdienstleister-Auditierung) und einen ausreichenden Beobachtungszeitraum für Typ 2 zu durchlaufen. Wer das Audit-Engagement nicht spätestens Q3 2026 startet, riskiert, ohne gültiges Testat in das Quartal nach dem 1. Juni 2027 zu rutschen.

8. Was das praktisch bedeutet – kompakt

Für Cloud-Anbieter:

• Gap-Analyse gegen C5:2026 jetzt beginnen, nicht 2027.
• Container-Security-Stack (Image-Scan, Admission Control, Runtime-Sensoren) inventarisieren und dokumentieren.
• Kryptografisches Inventar erstellen – das ist die Voraussetzung für jeden PQC-Migrationsplan und gleichzeitig ein Selbstzweck.
• SBOM-Generierung in CI/CD-Pipelines integrieren, nicht als Reporting-Artefakt am Quartalsende.
• Sub-Service-Organizations dokumentieren und Auditierungs-Rhythmen festlegen.
• Mit Wirtschaftsprüfer Audit-Engagement spätestens Q3 2026 starten, um genug Beobachtungszeitraum für Typ 2 nach C5:2026 zu haben.

Für Cloud-Kunden:

• Aktuelle Anbieter-Testate einsammeln und auf Scope, Berichtszeitraum und Ausnahmen prüfen.
• Neue Anbieter-Verträge mit der Verpflichtung zu einem C5:2026-Typ-2-Testat versehen.
• Korrespondierende Kundenkriterien aus den Berichten extrahieren und in eigene Sicherheitsrichtlinien übersetzen.
• Beschaffungsprozesse so anpassen, dass C5-Konformität als Mindestkriterium aufgenommen wird – nicht als Wunschkriterium.
• Wer Patientendaten verarbeitet: § 393-SGB-V-Compliance-Status der Cloud-Dienste dokumentieren, einschließlich Übergangsmechanismus, falls genutzt.

Für IT-Verantwortung mit branchenübergreifendem Cloud-Footprint:

• C5:2026 als gemeinsamen Mindeststandard im Lieferantenmanagement etablieren.
• Mapping zwischen C5:2026, NIS2, DORA und ISO 27001:2022 vorbereiten – die Referenztabellen kommen, aber das eigene Mapping zur Anwendung im eigenen Portfolio kommt nicht von alleine.
• Cloud-Souveränitäts-Strategie nicht ohne Bezug auf C5 formulieren – die kommenden BSI-Souveränitätskriterien werden ergänzen, nicht ersetzen.

Werkzeuge auf it-governance.dev

Brauchen Sie einen Überblick, welche regulatorischen Stichtage – C5:2026, NIS2, DORA, EU AI Act – auf Sie zukommen? Der Regulatorische Fristenkalender zeigt die relevanten Termine in einer Übersicht.

Setzen Sie KI-Komponenten in Cloud-Diensten ein? Die Tools-Sammlung ordnet Use Cases nach EU-AI-Act-Kategorien ein – kostenlos und ohne Registrierung.

Fazit

Der C5:2026 ist nicht das, als was er sich selbst etikettiert. Er ist nicht die nächste Generation eines deutschen Standards. Er ist die nationale Vor-Implementierung eines europäischen Standards mit branchenübergreifender Reichweite – getragen vom Vergaberecht der öffentlichen Hand, vom Sozialgesetzbuch im Gesundheitswesen, von der NIS2-Lieferkettenpraxis und von der schlichten Marktrealität, dass professionelle Cloud-Beschaffung 2026 ohne strukturierten Prüfbericht nicht mehr stattfindet.

Wer C5 weiterhin als Banken-Thema einordnet, hat damit recht – im Sinne von 2018. In der Lage 2026 ist diese Einordnung nicht falsch, sondern obsolet. Der Standard ist erwachsen geworden, und seine Anwendungsbreite hat ihn überholt.

Die einzige Frist, die in der Diskussion zählt, ist der 1. Juni 2027. Was zwischen heute und diesem Datum passiert, entscheidet darüber, ob ein Cloud-Anbieter 2027 noch im Vergabeverfahren auftauchen darf – und ob ein Cloud-Kunde seinem Aufsichtsorgan, seinem Patienten oder seinem Lieferanten einen belastbaren Nachweis vorlegen kann.

Quellen

• BSI: Pressemitteilung vom 7. April 2026 zur Veröffentlichung C5:2026, www.bsi.bund.de
• BSI: Cloud Computing Compliance Criteria Catalogue (C5:2026), CC BY-ND 4.0
• BSI: C5-Einführung und FAQ (Übergangsfristen, Typ 1 vs. Typ 2)
• § 393 SGB V (DigiG) und C5-Gleichwertigkeitsverordnung (BMG, 2025)
• § 44 BSIG i. V. m. BSI-Mindeststandard zur Nutzung externer Cloud-Dienste
• § 8a BSIG (KRITIS, „Stand der Technik")
• CEN/TS 18026:2024 als Grundlage für C5:2026
• ENISA: EUCS Substantial Level (Stand 2026)
• AWS European Sovereign Cloud, GA-Ankündigung Januar 2026
• NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
• BSI: PQC-Migrationsfristen (KRITIS 2030, übrige 2032)