C5-Kriterien praktisch erklärt: Was fordert der Kriterienkatalog?

Sie öffnen den C5:2026-Katalog, scrollen zum Inhaltsverzeichnis und sehen 17 Bereiche. Darunter stehen sehr viele einzelne Kriterien, Unterkriterien, Basisanforderungen und zusätzliche Anforderungen. Nebenbei möchte das Tagesgeschäft auch noch bedient werden. Ein ausgesprochen gemütlicher Start in den Arbeitstag.

Die gute Nachricht: Hinter der Menge steckt eine klare Logik. C5 sortiert die Sicherheit eines Cloud-Dienstes vom Management bis zum Quellcode, vom Rechenzentrum bis zum Unterauftragnehmer und vom normalen Betrieb bis zum ernsten Sicherheitsvorfall. Wer diese Logik versteht, kann aus dem dicken Katalog ein brauchbares Umsetzungsprogramm machen.

Die kurze Antwort

C5:2026 verlangt kein bestimmtes Sicherheitsprodukt und keine magische Sammlung von Vorlagen. Der Katalog verlangt ein nachweisbares Kontrollsystem für die Entwicklung und den Betrieb eines konkreten Cloud-Dienstes.

Das heißt: Der Cloudanbieter muss festlegen, wie er die C5-Kriterien erfüllt, passende organisatorische und technische Kontrollen einrichten, sie im Alltag betreiben und dafür belastbare Nachweise erzeugen. Eine Richtlinie allein reicht also ebenso wenig wie eine Firewall allein. Entscheidend ist die nachvollziehbare Kette aus Anforderung, Kontrolle, Verantwortlichem, Durchführung und Nachweis.

Der offizielle C5:2026-Kriterienkatalog des BSI gliedert diese Arbeit in 17 Kriterienbereiche. Sie betrachten nicht das Unternehmen im luftleeren Raum, sondern die Informationssicherheit des beschriebenen Cloud-Dienstes. Welche Systeme, Standorte, Regionen und Unterauftragnehmer tatsächlich dazugehören, ist eine eigene Frage. Genau darum geht es in unserem Artikel zum C5-Scope und den Grenzen des Testats.

Wie C5:2026 aufgebaut ist

Die 17 Bereiche enthalten Basiskriterien und zusätzliche Kriterien. Basiskriterien bilden das allgemeine Sicherheitsniveau, das ein Cloudanbieter für den betrachteten Dienst abdecken soll. Die zusätzlichen Kriterien können dieses Niveau verschärfen oder um weitere Anforderungen ergänzen. C5:2026 unterscheidet deshalb zwischen schärfenden und ergänzenden Zusatzkriterien.

Außerdem verlangt der Katalog transparente Angaben zu den Rahmenbedingungen des Cloud-Dienstes. Dazu gehören beispielsweise Rechtsraum, Verarbeitungsorte, Verfügbarkeit, Wiederanlaufparameter, der Umgang mit Behördenanfragen und vorhandene Testate. Diese „General Conditions“ sind wichtig, aber kein achtzehnter Sicherheitsbereich.

Für die praktische Umsetzung sind zunächst die folgenden 17 Bereiche entscheidend:

Die Tabelle ist eine Landkarte, keine Umsetzungscheckliste. Unter einer Zeile wie OPS stecken zahlreiche unterschiedliche Kontrollen. Wer dort nur „Monitoring vorhanden“ einträgt, hat zwar drei Wörter produziert, aber noch kein prüfbares Kontrollsystem.

Fünf Arbeitspakete statt 17 einzelner Baustellen

In der Praxis sollten Sie die Bereiche nicht als 17 voneinander isolierte Projekte behandeln. Viele Kontrollen hängen eng zusammen und erzeugen gemeinsam Nachweise. Sinnvoller sind fünf größere Arbeitspakete, in denen Fachbereiche zusammenarbeiten.

Organisation, Richtlinien, Personal und Assets

Der erste Block verbindet OIS, SP, HR und AM. Hier entsteht das organisatorische Rückgrat: Das Management gibt Richtung und Sicherheitsziele vor, Verantwortlichkeiten werden verteilt, Risiken bewertet, Richtlinien freigegeben und Assets erfasst. Personalprozesse sorgen dafür, dass geeignete Leute ihre Aufgaben kennen und Rechte bei einem Rollenwechsel nicht auf wundersame Weise für immer behalten.

C5:2026 fordert in OIS ein ISO 27001-konformes ISMS, dessen Anwendungsbereich die für Entwicklung und Betrieb des Cloud-Dienstes relevanten Einheiten, Standorte und Abläufe abdeckt. Eine vorhandene Zertifizierung kann hier stark helfen. Sie ersetzt aber nicht die dienstbezogene Arbeit: Verantwortungsgrenzen, Cloud-Risiken, Shared Responsibility und die Verbindung zwischen ISMS und konkretem Dienst müssen nachvollziehbar sein.

Praktisch braucht dieser Block unter anderem eine klare Sicherheitsorganisation, einen belastbaren Risikoprozess, gesteuerte Richtlinien, Rollenbeschreibungen, Schulungsnachweise sowie brauchbare Hardware- und Softwareinventare. „Steht alles irgendwo im Ticketsystem“ ist nur dann eine Lösung, wenn auch Zuständigkeit, Aktualität und Auswertung funktionieren.

Physischer und technischer Betrieb

PS, OPS, IAM, CRY und COS bilden den größten Maschinenraum. Hier geht es um Gebäude und Stromversorgung ebenso wie um Backups, Protokolle, Schwachstellen, privilegierte Konten, Netzsegmentierung, Verschlüsselung und Schlüssel. C5:2026 greift außerdem moderne Betriebsformen deutlicher auf, darunter Container-Management und Confidential Computing.

Der entscheidende Punkt lautet: Kontrollen müssen nicht nur technisch vorhanden, sondern gesteuert sein. Ein Backup-Job ist gut. Zusätzlich müssen Umfang, Frequenz, Schutz, Überwachung und Wiederherstellungstests geregelt sein. Ein SIEM ist nützlich. Es muss aber relevante Quellen erhalten, Alarmierungen auslösen und in einen bearbeiteten Prozess münden. Ein Vulnerability-Scanner produziert sonst vor allem sehr viele bunte Befunde.

Für jeden wichtigen Betriebsprozess sollten Sie deshalb vier Fragen beantworten können:

1. Was soll die Kontrolle erreichen?
2. Wer ist für Betrieb und Überwachung verantwortlich?
3. Wie oft oder bei welchem Ereignis wird sie ausgeführt?
4. Welcher Nachweis zeigt, dass sie tatsächlich funktioniert hat?

Diese Fragen machen aus Technik eine prüfbare Kontrolle. Das ist auch der Grund, warum C5 nicht durch den Einkauf eines Compliance-Tools erledigt ist. Das Tool kann Nachweise sammeln. Denken, entscheiden und sauber betreiben muss das Unternehmen weiterhin selbst.

Entwicklung, Produktsicherheit und Änderungen

DEV und PSS greifen ineinander. DEV betrachtet den Weg von der Sicherheitsanforderung über Beschaffung, Architektur, Entwicklung, Test und Versionskontrolle bis zur Produktionsfreigabe. PSS schaut stärker auf die Sicherheitseigenschaften des angebotenen Cloud-Dienstes: sichere Konfiguration, Authentisierung, Sitzungen, Rollen, Schwachstelleninformationen und kundenverständliche Empfehlungen.

Für SaaS-Anbieter ist das besonders wichtig. Der Entwicklungsprozess ist nicht bloß eine interne Werkstatt hinter dem eigentlichen Dienst. Er ist Teil der Sicherheitsleistung. Pull Requests, automatisierte Tests, Freigaben, geschützte Entwicklungsumgebungen, Softwarekomponenten und Änderungen an der Produktion müssen deshalb in einer belastbaren Kette zusammenpassen.

Ein typischer Fehler ist die Trennung zwischen dem ISMS und den echten Engineering-Abläufen. Im ISMS steht ein sauberer Change-Prozess, während Deployments in der Praxis über einen anderen Weg laufen. C5 interessiert sich für den wirklichen Weg. Eine schlanke Regelung, die zu Git, CI/CD und Betrieb passt, ist besser als ein feierliches Prozessbild, das niemand benutzt.

Lieferanten, Portabilität und Kundenabhängigkeiten

PI und SSO zwingen den Cloudanbieter, über die eigene Organisation hinauszusehen. Kundendaten müssen sicher hinein- und wieder herauskommen. Verträge müssen Übergabe und Löschung nach Vertragsende abbilden. Gleichzeitig sind Rechenzentren, Hyperscaler, Supportanbieter und weitere Lieferanten so zu steuern, dass ihre Leistungen das Kontrollsystem nicht an einer unsichtbaren Naht aufreißen.

Dafür brauchen Sie ein aktuelles Verzeichnis relevanter Dienstleister, Risikobewertungen, klare Sicherheitsanforderungen, Informationen zu Datenflüssen und eine laufende Überwachung. Ein Testat des Hyperscalers ist dabei ein wichtiger Nachweis, aber kein Freifahrtschein. Sie müssen verstehen, welche Kontrollen der Dienstleister übernimmt und welche bei Ihnen verbleiben.

Auch die Kunden haben Aufgaben. C5 nennt dazu korrespondierende Kundenkriterien. Sie beschreiben Stellen, an denen der Dienst nur dann sicher funktioniert, wenn der Kunde seinen Anteil erfüllt – etwa bei Benutzerrechten oder Konfigurationen. Das erklären wir ausführlich im Beitrag über die korrespondierenden C5-Kriterien für Kunden. Für Ihren Anbieter-Scope bleibt entscheidend, diese Abhängigkeiten eindeutig zu beschreiben und verständlich zu kommunizieren.

Vorfälle, Notfälle, Compliance und Behördenanfragen

SIM, BCM, COM und INQ bilden den Block für Situationen, in denen Normalbetrieb allein nicht reicht. Sicherheitsvorfälle brauchen Meldewege, Bewertung, Reaktion, Kommunikation und Nachbereitung. Notfälle brauchen eine Business Impact Analysis, realistische Wiederanlaufziele und getestete Pläne. Compliance braucht ein gepflegtes Verzeichnis relevanter Anforderungen sowie Interne Audits und Managementbewertung.

INQ ergänzt eine cloudtypische Transparenzfrage: Wie geht der Anbieter mit Ermittlungsanfragen staatlicher Stellen um? Der Prozess muss Anfragen bewerten, Datenzugriffe begrenzen, technische Schritte kontrollieren und die zulässige Kundeninformation berücksichtigen. Das Thema gehört nicht als improvisierte Randnotiz in den Ernstfallordner.

Gemeinsam zeigen diese Bereiche, ob der Anbieter auch unter Druck kontrolliert handelt. Ein Notfallplan, der seit drei Jahren nicht getestet wurde, beschreibt bestenfalls eine Hoffnung. C5 erwartet eine belastbarere Verbindung aus Planung, Übung, Auswertung und Verbesserung.

Vom Katalog zur eigenen Kontrollmatrix

Der vernünftige Einstieg ist keine Schreibwoche für 168 Einzeltexte. Beginnen Sie mit dem konkreten Cloud-Dienst und ordnen Sie vorhandene Prozesse und technische Kontrollen den anwendbaren Kriterien zu. Pro Kriterium sollte sichtbar werden:

• welche Kontrolle die Anforderung erfüllt;
• wer dafür verantwortlich ist;
• welche Systeme und Standorte einbezogen sind;
• wann oder wodurch die Kontrolle ausgelöst wird;
• welche Nachweise entstehen;
• welche Dienstleister oder Kundenpflichten daran hängen;
• welche Lücke noch geschlossen werden muss.

Damit erhalten Sie eine Kontrollmatrix, die zugleich Projektplan und spätere Nachweislandkarte sein kann. Die Details zum eigentlichen Prüfungsprojekt finden Sie in C5: Wie bekommt man ein C5-Testat?. Ob Typ 1 oder Typ 2 zu Ihrer Situation passt, behandeln wir separat im Artikel C5 Typ 1 oder Typ 2. So bleibt dieser Überblick bei den Kriterien, statt in Wirtschaftsprüfermechanik abzubiegen.

Ein vorhandenes ISMS hilft – aber es drückt nicht den Fertig-Knopf

Wenn Ihr Unternehmen bereits ein ISMS betreibt, bringen Sie viel Nützliches mit: Risikomanagement, Richtliniensteuerung, Rollen, Schulung, Lieferantenmanagement, Internes Audit, Managementbewertung und zahlreiche technische Controls. Auch ein ISO 27001-Zertifikat kann eine starke Grundlage sein.

C5 betrachtet jedoch den konkreten Cloud-Dienst und geht in vielen Bereichen sehr detailliert auf dessen Entwicklung, Betrieb, Lieferkette, Transparenz und Kundenabhängigkeiten ein. Deshalb ist „ISO vorhanden“ kein belastbarer Gap-Check. Der grundlegende Unterschied zwischen beiden Nachweisarten steht im Beitrag C5 und ISO 27001: Warum Zertifikat und Testat nicht dasselbe sind. Welche Ihrer vorhandenen ISMS-Strukturen tatsächlich tragen und wo zusätzliche C5-Nachweise nötig werden, verdient eine eigene Readiness-Betrachtung.

Typische Fehler bei der Arbeit mit den C5-Kriterien

Der erste Fehler ist, den Katalog in 17 Dokumentenordner zu zerlegen. Kontrollen laufen quer durch mehrere Bereiche. Ein sauberer Incident-Prozess verbindet beispielsweise Betrieb, Produktsicherheit, Kommunikation, Personal und BCM.

Der zweite Fehler ist die Verwechslung von Vorgabe und Nachweis. Eine Richtlinie beschreibt, was geschehen soll. Ein Ticket, ein Review-Protokoll, eine Logauswertung oder ein Testergebnis zeigt, was geschehen ist. C5 braucht beides in sinnvoller Kombination.

Der dritte Fehler ist ein zu breiter oder zu schwammiger Scope. Dann werden Kontrollen entweder unnötig für das ganze Unternehmen gebaut oder relevante Abhängigkeiten übersehen. Der vierte Fehler ist der Glaube, jedes C5-Projekt sei automatisch gesetzlich vorgeschrieben. Wann eine echte C5-Pflicht insbesondere nach § 393 SGB V besteht und wann Kunden oder Ausschreibungen den Ausschlag geben, haben wir bewusst ausgelagert.

Und schließlich: Behandeln Sie Zusatzkriterien nicht pauschal als Dekoration. Prüfen Sie, welche Schutzbedarfe, Verträge und Kundengruppen sie relevant machen. Die Entscheidung gehört begründet in das Projekt, nicht unter den Teppich.

Interesse geweckt?

Sie möchten aus den 17 Bereichen ein realistisches C5-Projekt für Ihren Cloud-Dienst machen? Sprechen Sie mit uns. Wir helfen Ihnen, Scope, Kontrollmatrix, Lücken und Nachweise so zu strukturieren, dass daraus ein tragfähiges System statt einer weiteren Tabellenruine wird.