BSI C5:2026: Was Cloud-Kunden jetzt wissen müssen
Anfang April dieses Jahres kam eine Nachricht, die in den IT-Vorständen meiner Kunden weniger Beachtung fand, als sie verdient: Das BSI hat C5:2026 veröffentlicht. Wer die vergangenen Monate damit verbracht hat, C5:2025-Readiness aufzubauen, steht jetzt vor einem Neubeginn. 168 Kriterien statt 121. Sieben neue Pflichtbereiche. Und erstmals maschinenlesbar in YAML, XLSX und PDF.
Ich berate DACH-Unternehmen seit Jahren zu BSI-C5-Compliance. Ein Gespräch, das ich in diesem Kontext immer wieder führe, klingt ungefähr so: Der CIO zeigt auf zwei Zertifikate. ISO 27001, frisch rezertifiziert. Dazu die C5-Attestierung des Hyperscalers. "Wir sind C5-ready." Ich frage: "Wer von euch wertet die CloudTrail-Logs aus?" Stille. Dann: "Das macht doch AWS." Nein. Das macht AWS nicht.
Dieses Missverständnis ist nicht Naivität. Es ist eine strukturelle Wissenslücke, die ich seit der ersten Version von C5 beobachte und die mit C5:2026 eine neue Schärfe bekommt.
Was C5:2026 konkret ändert
Der Sprung von C5:2020 auf C5:2026 ist kein Update. Er ist ein Generationenwechsel. 121 Kriterien in 16 Themenbereichen wurden zu 168 Kriterien in 17 Themenbereichen. Drei Bereiche sind neu und verpflichtend:
Container-Management. Wer containerisierte Workloads auf AWS betreibt, etwa mit EKS oder ECS, muss jetzt nachweisen, dass Container-Images aus vertrauenswürdigen Quellen stammen, signiert sind und regelmäßig auf Schwachstellen geprüft werden. Image-Scanning in einer CI/CD-Pipeline ist nicht optional. Es ist C5.
Post-Quantum-Kryptographie. BSI und NIST arbeiten seit Jahren auf diesen Moment hin. C5:2026 schreibt jetzt vor, dass Migrationspläne für Post-Quantum-Algorithmen existieren müssen. Kein Mensch erwartet, dass alle TLS-Verbindungen bis morgen auf CRYSTALS-Kyber umgestellt sind. Aber ein Inventar der kritischen kryptographischen Abhängigkeiten und ein dokumentierter Migrationsplan: der muss her.
Confidential Computing. Dieser Bereich war in der Praxis vor zwei Jahren noch Randthema. AWS Nitro Enclaves, AMD SEV-SNP auf EC2-Instanzen, Intel TDX. C5:2026 signalisiert: Wer hochsensible Daten in der Cloud verarbeitet, muss begründen können, warum er nicht auf Hardware-isolierte Ausführungsumgebungen setzt.
Hinzu kommt die EUCS-Ausrichtung: C5:2026 wurde auf den European Cloud Security Scheme abgestimmt. Sovereignty-Kriterien kommen separat. Wer heute keine Sovereignty-Position hat, sollte damit beginnen, eine zu entwickeln.
Die Attestierungs-Logik, die viele falsch verstehen
C5 kennt zwei Attestierungstypen. Type 1 beschreibt, dass Kontrollen zum Stichtag existieren. Type 2 zeigt, dass sie über einen definierten Zeitraum wirksam betrieben wurden. Type 2 ist der anspruchsvollere, aber auch aussagekräftigere Nachweis.
AWS hat für seinen Cloud-Stack eine C5 Type 2-Attestierung. Das ist gut. Aber diese Attestierung deckt genau das ab, was AWS kontrolliert: die physische Infrastruktur, die Hypervisor-Schicht, das Netzwerk, die Managed Services in ihrem Betrieb.
Was sie nicht abdeckt: alles, was der Kunde konfiguriert, betreibt und verantwortet. Das BSI nennt das "Customer Unique Engagement Controls" (CUECs). Wer eine C5-Attestierung für seinen eigenen Cloud-Betrieb anstrebt, muss diese CUECs eigenständig nachweisen. Und C5:2026 hat ihren Umfang erheblich erweitert.
Konkret fragt C5:2026 jetzt: Wie verwaltet ihr Container-Images und die Software Supply Chain? Welche Sub-Prozessoren habt ihr, und welche davon können auf eure Daten zugreifen? Wer hat unter welchen Umständen rechtlichen Zugriff auf die Daten? IAM-Prozesse, Log-Auswertung, Supplier Risk Management: das sind keine AWS-Aufgaben. Das sind eure Aufgaben.
Drei Schritte, die ich meinen Kunden empfehle
1. Gap-Analyse auf die neuen Themenbereiche
Der erste Schritt ist kein Audit-Projekt. Er ist ein Mapping. Nehmt euer bestehendes ISMS und euer NIS2-Programm und legt die neuen C5:2026-Bereiche daneben. Container-Management, Software Supply Chain, Post-Quantum, Confidential Computing, Cloud Sovereignty. Für jeden Bereich: Haben wir bereits ein Control? Passt es zu den C5-Anforderungen? Oder gibt es eine Lücke?
Wer NIS2 bereits operativ umsetzt, hat oft einen Vorsprung im Bereich Supply-Chain-Risikomanagement. ISO-27001-Zertifizierungen decken häufig Teile der Asset- und Access-Management-Anforderungen ab. Synergien nutzen, Doppelarbeit vermeiden: das ist das Ziel dieser Phase.
Ein praktischer Hinweis: C5:2026 ist erstmals maschinenlesbar. Der Download als YAML-Datei vom BSI macht es möglich, die Kriterien direkt in ein GRC-Tool zu importieren, statt sie manuell nachzupflegen. Das ist ein echter Fortschritt.
2. Compliance-as-Code statt Tabellen
Wer C5-Compliance mit Excel-Tabellen und manuellen Checklisten betreibt, hat ein Skalierungsproblem. Mit 168 Kriterien über 17 Themenbereiche wird das zur Vollzeitaufgabe, die in der nächsten Auditperiode bereits veraltet ist.
Der Ansatz, den ich empfehle, basiert auf drei AWS-Diensten:
AWS Control Tower liefert die Grundstruktur für eine Multi-Account-Landing-Zone mit zentralem Logging-Account, präventiven Service Control Policies (SCPs) als Leitplanken und detektivischen Config Rules. Bestandskonten können nachträglich in Control Tower eingebunden werden.
AWS Config mit C5 Conformance Pack. Das "Operational Best Practices for Germany Cloud Computing Compliance Criteria Catalog (C5)"-Conformance Pack ist verfügbar und prüft automatisiert gegen einen definierten Satz von C5-Anforderungen. Es ist kein vollständiger Ersatz für ein Audit, aber es macht viele technische Kontrollen kontinuierlich sichtbar.
AWS Security Hub als CSPM-Schicht konsolidiert Findings aus Config, GuardDuty und Firewall Manager in einer Ansicht. Wer Security Hub Standards aktiviert hat, sieht sofort, wo technische Abweichungen vom erwarteten Baseline-Zustand entstehen.
Ein Hinweis für alle, die noch auf AWS Audit Manager setzen: AWS hat Audit Manager eingestellt. Er steht nicht mehr als aktiv weiterentwickelte Lösung zur Verfügung. Evidence-Management läuft jetzt über AWS Config Rules, Security Hub Findings, CloudTrail und manuelle Evidence-Sammlungen (Policies, Verträge, Supplier-Risikoanalysen).
3. Evidence-Sammlung ohne Audit Manager
Das Ziel einer C5-Attestierung ist, nachweisen zu können, dass definierte Kontrollen wirksam betrieben werden. Der Nachweis braucht Belege: technische Findings, Prozessdokumente, Verträge.
Für den technischen Teil: AWS Config Rules liefern kontinuierliche Compliance-Checks, deren Ergebnisse in S3 archiviert werden können. Security Hub Findings exportiert ihr über EventBridge in eine S3-basierte Evidence-Ablage. CloudTrail-Logs sind die unveränderliche Aufzeichnung aller API-Calls und damit das Rückgrat des Nachweises für Access-Management-Kontrollen.
Für den manuellen Teil: Policies, Betriebshandbücher, Datenschutzverträge, Ergebnisse von Supplier-Risikoanalysen. Diese Dokumente müssen revisionssicher abgelegt und auf den C5-Kontext referenzierbar sein. Wer ein GRC-Tool nutzt, pflegt hier die Verbindung zwischen Kriterienkatalog und Evidenzsammlung.
Was das für die Praxis bedeutet
Ich habe mit dem Cloud Governance Accelerator (CGA) ein Werkzeug entwickelt, das diese Baseline auf historisch gewachsene AWS-Umgebungen anwendet: Brownfield-Konten, die über Jahre entstanden sind, ohne dass eine strukturierte Governance-Grundlage gelegt wurde. Ziel ist C5- und NIS2-Readiness ohne kostspielige Komplettmigration. Wer mit mir darüber sprechen möchte, findet mich auf LinkedIn oder am AWS Summit Hamburg im Mai.
Der wichtigere Punkt ist aber dieser: C5:2026 ist kein Compliance-Projekt, das man einmal abarbeitet. Es ist ein Betriebszustand. Die Herausforderung besteht nicht darin, 168 Kriterien einmalig zu erfüllen. Sie besteht darin, eine Organisation so aufzustellen, dass sie diesen Zustand dauerhaft halten und nachweisen kann.
Wer jetzt anfängt, hat einen Vorteil gegenüber denen, die auf den nächsten Auditoren warten.
Fragen zu BSI C5:2026, eurem Compliance-Programm oder dem Cloud Governance Accelerator? Kommentar unten oder direkt vernetzen.