BSI C5 Kubernetes: 6 Lehren zu Testat und Betrieb

Gastbeitrag aus der Praxis: Dieser Artikel stammt von Pexon Consulting, dem Betreiber dieser Seite und selbst Kubernetes-Dienstleister. Er beschreibt eigene Projekte und Erfahrungen und ist nicht Teil unserer neutralen Vergleiche.

TL;DR

BSI C5 und Kubernetes passen nur zusammen, wenn zwei Nachweise getrennt geführt werden: das C5-Testat des Cloud-Anbieters für seinen Dienst und der Nachweis Ihres eigenen Clusterbetriebs darauf. Wir bei Pexon sehen in regulierten Projekten immer wieder, dass das Testat des Anbieters für den ganzen Cluster gehalten wird. Das ist es nicht.

Warum reicht das C5-Testat des Anbieters für Ihren Cluster nicht?

Ein C5-Testat beschreibt das interne Kontrollsystem des Cloud-Anbieters für einen bestimmten Dienst in bestimmten Regionen. Was Sie im Cluster konfigurieren, also Rollen, Images, Netzregeln und Änderungen, liegt außerhalb dieses Prüfgegenstands. Der C5 selbst sieht dafür korrespondierende Kontrollen der Kunden vor, und die müssen Sie belegen.

Dieser Beitrag ist ein gekennzeichneter Praxisbericht von Pexon Consulting, dem Betreiber dieser Seite. Wir beschreiben, was wir in regulierten Kubernetes-Projekten gelernt haben, mit den Zahlen, die wir auf pexon-consulting.de veröffentlicht haben. Zu den Projekten gehört eine Kubernetes-Plattform auf Azure AKS für eine Genossenschaftsbank mit einem Projektvolumen von 102.700 EUR. Den regulatorischen Rahmen für Banken mit DORA und Informationsregister haben wir im Praxisbericht Kubernetes in Banken beschrieben. Hier geht es nur um C5.

Die Eckdaten, die wir in jedem Projekt zuerst klären:

Punkt	Stand Oktober 2026	Quelle
Kriterien C5:2020	121 Kriterien	BSI Einführung
Kriterien C5:2026	168 Kriterien in 17 Themengebieten, mit Unterkriterien	BSI Einführung
C5:2026 veröffentlicht	Version 1.0.0 am 07.04.2026, Version 1.1.0 am 11.08.2026	C5:2026 PDF
Übergang	C5:2026 empfohlen für Prüfzeiträume, die am oder nach dem 01.06.2027 enden	BSI C5:2020
Prüfmethodik	ISAE 3000, Testat nur durch Wirtschaftsprüfer	BSI FAQ
Pflicht	empfehlend; verbindlich für Bundesbehörden über den Mindeststandard, im Gesundheitswesen über § 393 SGB V seit 01.07.2024	BSI Einführung, BSI FAQ

Lehre 1: Das Testat gilt für Dienste und Regionen, nicht für den Anbieter

Das BSI sagt es ausdrücklich: Ein C5-Testat wird nie für einen Cloud-Anbieter als Ganzes erstellt, sondern für die geprüften Dienste in festgelegten Regionen. Die erste Frage im Projekt lautet deshalb nicht “Hat der Anbieter C5?”, sondern “Steht der Kubernetes-Dienst in der Region, die wir nutzen, im Scope?”.

In der Praxis ist diese Frage auf den öffentlichen Seiten unterschiedlich gut beantwortet. Unser Stand vom 22.10.2026 für die Anbieter, die uns in Projekten am häufigsten begegnen:

Anbieter	C5 laut eigener Seite	Kubernetes-Dienst öffentlich im Scope genannt?
AWS EKS	C5, Scope-Liste öffentlich	ja, EKS mit Fargate und EC2 sowie ECR (AWS)
Azure AKS	C5:2020, kombiniert mit SOC 2 Typ 2	Scope steht im SOC-2-Bericht im Service Trust Portal (Microsoft Learn)
Google GKE	C5:2020	ja, Google Kubernetes Engine in der Produktliste (Google Cloud)
IONOS	C5:2020 Typ 1 vom 28.05.2026, 33 Services in 10 Service-Clustern	nicht einzeln aufgeführt (IONOS)
STACKIT	C5 Typ 2	keine Dienstliste auf der C5-Seite
Exoscale	C5:2020 Typ 2	keine Dienstliste, Bericht im Compliance Center
T Cloud Public	C5 Typ II (ISAE 3000)	keine Dienstliste, Bericht auf Anfrage

“Nicht aufgeführt” heißt nicht “nicht geprüft”. Es heißt, dass Sie den Bericht anfordern und die Systembeschreibung lesen müssen. Microsoft kündigt auf der Learn-Seite (Stand 12.11.2025) für Juli 2026 erstmals einen eigenständigen C5-Bericht an; ob er für Ihren Prüfzeitraum vorliegt, klären Sie im Service Trust Portal. Einen Anspruch auf den vollständigen Prüfbericht haben Kunden nach dem BSI übrigens nicht, er gehört dem Anbieter.

Lehre 2: Typ 1 ist ein Stichtag, Typ 2 ein Zeitraum

Ein Bericht vom Typ 1 bestätigt, dass Kontrollen zum Prüfzeitpunkt angemessen ausgestaltet sind. Typ 2 bestätigt zusätzlich, dass sie über einen Prüfzeitraum wirksam waren, typischerweise 6 oder 12 Monate. Das BSI hält Typ 2 für erforderlich und Typ 1 nur bei der Erstprüfung für vertretbar.

Für Ihre Revision ist das mehr als eine Formalie. Wir lesen in Projekten zuerst drei Angaben aus dem Bericht:

1. Typ und Prüfzeitraum: Liegt das Ende des Zeitraums mehr als zwölf Monate zurück, fragen wir nach einer Bridge Letter oder dem Folgebericht.
2. Dienste und Regionen im Scope: Steht der Kubernetes-Dienst und die genutzte Region im Bericht, oder nur die darunterliegende Compute-Plattform?
3. Abweichungen und Stellungnahmen: Der Abschnitt mit sonstigen Informationen des Anbieters ist ausdrücklich nicht vom Prüfungsurteil abgedeckt.

Das BSI empfiehlt Kunden, den Anbieter direkt anzusprechen, wenn wiederholt ein Bericht vom Typ 1 vorgelegt wird. Wir halten das für eine sinnvolle Regel in jeder Ausschreibung.

Lehre 3: Die korrespondierenden Kontrollen sind Ihre Arbeit

Der C5 kennt “korrespondierende Kontrollen der Cloud-Kunden” (Complementary User Entity Controls, CUEC). Der Anbieter geht bei seinem Kontrollsystem davon aus, dass Sie diese umsetzen. Erst beide zusammen erfüllen das Kriterium. Für einen Kubernetes-Dienst heißt das: Ein großer Teil des Nachweises entsteht in Ihrer Clusterkonfiguration.

Wie das konkret aussieht, zeigt das Kriterium PSS-11 zu Images für virtuelle Maschinen und Container im C5:2026. Der Anbieter muss ermöglichen, dass Sie den Start auf freigegebene Images einschränken. Die korrespondierende Kundenpflicht lautet, mit geeigneten Kontrollen sicherzustellen, dass die betriebenen Container Ihren Anforderungen an das Informationssicherheitsmanagement entsprechen. Wir übersetzen das in jedem Projekt in eine Aufteilung:

C5-Thema	Anbieter liefert (Testat)	Clusterbetreiber liefert (Ihr Nachweis)
Images (PSS-11)	Funktion zur Einschränkung, gehärtete Basis-Images	Admission-Regel auf freigegebene Registries, Scan-Ergebnisse
Region (PSS-12)	Verarbeitung nur in vertraglich festgelegter Region	Nachweis, dass Cluster, Backups und Registry in dieser Region liegen
Zugriff (IAM)	Rollenmodell für eigenes Personal	RBAC-Export, Liste der cluster-admin-Bindungen, Review-Protokoll
Änderungen	Change-Prozess der Plattform	Änderungshistorie mit Zeitstempel und Verantwortlichen
Protokollierung	Logs der Plattform	Audit-Log des API-Servers, Aufbewahrung, Auswertung

Der Plattformanbieter liefert Belege für seine Infrastruktur, nicht für Ihre Konfiguration darauf. Genau an dieser Lücke setzen unsere Projekte an.

Lehre 4: “C5-konform” ist kein Testat, und von uns gibt es keines

Für den C5 gibt es kein Zertifizierungsverfahren und damit keine C5-Zertifikate, sondern nur Testate nach ISAE 3000, die ausschließlich Wirtschaftsprüfer ausstellen dürfen. Ein Betriebsdienstleister, der “C5-zertifiziert” verspricht, verspricht etwas, das es nicht gibt. Wir arbeiten nach C5-Kriterien und liefern Belege.

Das BSI weist auf eine zweite Schwäche hin: Beim Testat gibt es nur zwei Parteien, den geprüften Anbieter und den von ihm bezahlten Prüfer. Die kritische Auswertung des Berichts liegt deshalb beim Kunden. In unseren Projekten heißt das, dass Ihre Revision den Bericht des Anbieters tatsächlich liest und gegen den eigenen Schutzbedarf hält, statt das Logo abzuheften.

Falls Ihre Branche kein Testat vorschreibt, lässt das BSI auch andere Nachweise zu, etwa IT-Revisionsberichte oder Selbstauskünfte. Für Banken und Versicherer reicht eine Selbstauskunft des Dienstleisters in unserer Erfahrung selten, weil der Finanzkunde die Belege selbst gegenüber seiner Aufsicht vertreten muss.

Lehre 5: Der CIS-Benchmark ist die prüfbare Baseline

C5 schreibt keine Maßnahmen vor, nur prüfbare Kriterien. Für die Härtung nennt der C5:2026 in den ergänzenden Informationen zu PSS-11 ausdrücklich den Security Configuration Benchmark des Center for Internet Security als allgemein akzeptierten Branchenstandard. Deshalb messen wir jeden Cluster zuerst gegen den CIS-Benchmark und dokumentieren die Abweichungen.

Für Managed-Cluster gibt es eigene Benchmark-Profile, weil die Control Plane beim Anbieter liegt. Das Open-Source-Werkzeug kube-bench bildet sie ab (Plattform-Tabelle):

Umgebung	CIS-Benchmark	kube-bench-Profil
Kubernetes 1.34 bis 1.35	CIS 2.0	cis-2.0
Kubernetes 1.32 bis 1.33	CIS 1.12	cis-1.12
Azure AKS	CIS AKS 1.7.0	aks-1.7
Amazon EKS	CIS EKS 1.5.0	eks-1.5.0
Google GKE	CIS GKE 1.6.0	gke-1.6.0

Ein erster Lauf auf einem AKS-Cluster sieht so aus:

# Job-Manifest für AKS aus dem kube-bench-Repository anwenden
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-aks.yaml

# Ergebnis aus dem Pod-Log sichern, mit Datum für die Nachweisablage
kubectl logs job/kube-bench > kube-bench-$(date +%F).txt
kubectl delete job kube-bench

Das AKS-Manifest startet kube-bench mit --targets node und dem Profil aks-1.7, prüft also nur die Worker Nodes, weil die Control Plane beim Anbieter liegt. Der Rohlauf ist noch kein Nachweis. Prüfer wollen sehen, welche Befunde bewertet, welche behoben und welche begründet akzeptiert wurden. Deshalb übersetzen wir die Ausgabe in einen Report mit Ampel und Prioritäten und wiederholen ihn nach jedem Upgrade. Welche Kubernetes-Versionen Ihr Anbieter wie lange unterstützt, und damit welches Benchmark-Profil gilt, zeigt der Vergleich Kubernetes Version Support.

Lehre 6: C5:2026 bringt eigene Container-Kriterien

C5:2026 enthält mit OPS-34 und OPS-35 erstmals eigene Kriterien für Container-Management. Sie verlangen Richtlinien über den gesamten Lebenszyklus, von der Image-Erstellung bis zur Außerbetriebnahme. Ab Prüfzeiträumen, die am oder nach dem 01.06.2027 enden, empfiehlt das BSI die neue Version. Ihr Anbieter wird danach fragen, was Sie im Cluster tun.

OPS-34.02B nennt neun Aspekte, darunter die Inventarisierung von Containern, Protokollierung entlang des Lebenszyklus, Zugriff auf Container-Hosts über ein Rollenmodell, geregelte Änderungen an Containern und Images sowie Härtung nach Branchenstandards. Das erweiternde Zusatzkriterium OPS-34.01AC geht weiter: kryptographisch signierte Images, Laufzeitkontrollen für das Containerverhalten und regelmäßige Schwachstellenscans.

Unser Vorgehen, um vor dem ersten Prüfzeitraum nach C5:2026 bereit zu sein:

1. Image-Inventar aufbauen: Welche Images laufen in welchem Namespace, aus welcher Registry, mit welchem Stand.
2. Registries einschränken: Nur freigegebene Registries per Admission-Regel zulassen.
3. Signaturen einführen: Images im Build signieren und die Signatur beim Deployment prüfen.
4. Änderungen über die Pipeline führen: Keine manuellen Änderungen an Deployments ohne Freigabe.
5. Benchmark wiederholen: Nach jedem Upgrade einen neuen CIS-Lauf ablegen.

Wer heute einen Cluster bei einem Anbieter mit C5-Testat betreibt, hat die Zeit bis zum Sommer 2027. Wir empfehlen, die Punkte 1 bis 3 in den nächsten Upgrade-Zyklus zu legen, statt sie kurz vor dem Audit nachzuziehen.

Was kostet ein C5-orientierter Kubernetes-Betrieb bei Pexon?

Wir arbeiten in Bausteinen auf einem laufenden Betrieb. Der Einstieg ist eine kostenlose SLA-Gap-Analyse von 60 Minuten. Ein einmaliger Abgleich gegen den CIS-Benchmark kostet ab 850 EUR, der laufende Nachweis-Betrieb nach C5-Kriterien 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung. Compute zahlen Sie getrennt an Ihren Anbieter.

Baustein	Preis (netto)	Inhalt
SLA-Gap-Analyse	kostenlos, 60 Minuten	Ist-Aufnahme, Abgleich mit Prüf- und Kundenanforderungen
Angriffsflächen-Check	ab 850 EUR einmalig, 2 bis 5 Werktage	RBAC, Network Policies, Pod Security, CVE-Scan gegen CIS-Benchmark, Report mit Ampel
Compliance-Snapshot	1.250 EUR einmalig, 3 bis 5 Werktage	derselbe Abgleich, dokumentiert zur Weitergabe an Revision oder Kunden
NIS2-/C5-Modul	1.500 bis 3.000 EUR pro Monat	monatlicher Audit-Trail, Konfiguration gegen C5-Kriterien, Audit-Support
DR-Übung	2.000 bis 4.000 EUR je Übung	Szenario, Übung im echten Cluster, Protokoll

Quellen sind unsere Seiten zu Kubernetes-Compliance (Stand 19.08.2026) und Kubernetes Security. Die Servicezeit ist Montag bis Freitag, 08:00 bis 18:00 Uhr MEZ.

Offen benannt, was bei uns noch nicht fertig ist: Das Nachweis-Paket mit Konfigurations-Report, Änderungshistorie und Zugriffsnachweisen entsteht gerade, ein Muster zeigen wir erst nach Abnahme. Abgenommen ist es erst, wenn Ihre Compliance-Verantwortlichen eine Prüferfrage zum Cluster aus den Unterlagen beantworten können, ohne bei uns anzurufen. Welche Anbieter in Deutschland überhaupt ein C5-Testat vorweisen, vergleicht die Redaktion neutral unter Managed Kubernetes Deutschland und souveräne Cloud Anbieter.

FAQ

Ist ein Kubernetes-Cluster automatisch C5-konform, wenn der Anbieter ein C5-Testat hat?

Nein. Das Testat deckt den geprüften Dienst des Anbieters in festgelegten Regionen ab. Ihre Konfiguration im Cluster, also Rollen, Images, Netzregeln und Änderungen, gehört zu den korrespondierenden Kontrollen der Kunden. Diese müssen Sie selbst umsetzen und belegen, sonst ist das C5-Kriterium insgesamt nicht erfüllt.

Was kostet ein C5-Nachweis für den eigenen Kubernetes-Betrieb?

Bei Pexon kostet ein einmaliger Abgleich gegen den CIS-Benchmark ab 850 EUR, die weitergabefähige Variante 1.250 EUR. Der laufende Nachweis-Betrieb nach C5-Kriterien liegt bei 1.500 bis 3.000 EUR im Monat je Cluster-Umgebung, netto. Ein eigenes C5-Testat für Ihren Dienst kostet zusätzlich den Wirtschaftsprüfer, dessen Preis wir nicht kennen.

C5 Typ 1 vs. Typ 2: Welcher Bericht reicht für eine Bank?

Typ 1 bestätigt die Angemessenheit der Kontrollen zu einem Stichtag, Typ 2 zusätzlich deren Wirksamkeit über einen Zeitraum von typischerweise 6 oder 12 Monaten. Das BSI hält Typ 2 für erforderlich und Typ 1 nur bei Erstprüfungen für vertretbar. Für regulierte Häuser empfehlen wir, Typ 2 als Kriterium in die Ausschreibung zu schreiben.

Was ändert sich mit C5:2026 für Kubernetes?

C5:2026 hat 168 statt 121 Kriterien und führt mit OPS-34 und OPS-35 eigene Kriterien für Container-Management ein: Inventar, Protokollierung, Zugriff auf Container-Hosts, geregelte Änderungen an Images, Härtung. Das BSI empfiehlt die neue Version für Prüfzeiträume, die am oder nach dem 1. Juni 2027 enden.

Kann Pexon ein C5-Testat ausstellen?

Nein. C5-Testate stellen nur Wirtschaftsprüfer nach ISAE 3000 aus, ein Zertifizierungsverfahren für C5 gibt es nicht. Wir betreiben Cluster nach C5-Kriterien und liefern die Belege, mit denen Ihre Revision oder Ihr Prüfer arbeitet. Ob C5 für Ihr Haus verpflichtend ist, klärt Ihre Rechtsberatung.

Welche Managed-Kubernetes-Dienste stehen öffentlich im C5-Scope?

Ausdrücklich genannt sind auf den Anbieterseiten Amazon EKS und Google Kubernetes Engine. Bei Azure steht der Scope im SOC-2-Bericht. IONOS, STACKIT, Exoscale und T Cloud Public nennen ein C5-Testat, listen den Kubernetes-Dienst aber nicht einzeln. Fordern Sie dort den Bericht an und prüfen Sie die Systembeschreibung.

Quellen

1. BSI: Kriterienkatalog C5 (abgerufen 22. Oktober 2026)
2. BSI: C5 Einführung (abgerufen 22. Oktober 2026)
3. BSI: C5 FAQ (abgerufen 22. Oktober 2026)
4. BSI: C5:2026 (abgerufen 22. Oktober 2026)
5. BSI: Kriterienkatalog C5:2026 (PDF, Version 1.1.0) (abgerufen 22. Oktober 2026)
6. BSI: C5:2020 und Übergang zu C5:2026 (abgerufen 22. Oktober 2026)
7. AWS: Services in Scope C5 (abgerufen 22. Oktober 2026)
8. Microsoft Learn: Germany C5 (Azure) (abgerufen 22. Oktober 2026)
9. Google Cloud: BSI C5:2020 (abgerufen 22. Oktober 2026)
10. IONOS Cloud: Zertifikate (abgerufen 22. Oktober 2026)
11. STACKIT: C5-Testat (abgerufen 22. Oktober 2026)
12. Exoscale: BSI C5 (abgerufen 22. Oktober 2026)
13. T Cloud Public: Zertifikate (abgerufen 22. Oktober 2026)
14. kube-bench: CIS Kubernetes Benchmark support (abgerufen 22. Oktober 2026)
15. Pexon: Kubernetes-Compliance NIS2, DORA, C5 (abgerufen 22. Oktober 2026)
16. Pexon: Kubernetes Security (abgerufen 22. Oktober 2026)