C5-Themengebiet OPS: den Regelbetrieb prüffähig aufstellen

Diese Seite behandelt das Themengebiet OPS (Regelbetrieb) des C5:2026, Abschnitt 5.6 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet OPS?

OPS verlangt, dass der laufende Betrieb des Dienstes geplant, überwacht und nachweisbar abgesichert ist. Mit 35 Kriterien, 89 Basis-Unterkriterien, 9 verschärfenden und 28 erweiternden Zusatz-Unterkriterien ist es das umfangreichste Gebiet. Die Kriterientitel ergeben acht Teilbereiche; die Gruppierung ist unsere Lesehilfe:

Elf OPS-Kriterien sind in C5:2026 ohne Vorgänger neu, darunter Patch-Management (OPS-27, OPS-28), Fremdbibliotheken (OPS-29), Datentrennung als Richtlinie (OPS-30) sowie Confidential Computing und Container. Mehrere bisherige Kriterien tragen neue Nummern: aus OPS-19 bis OPS-23 in C5:2020 wurden OPS-22 bis OPS-26, aus OPS-24 wurde OPS-31. Verweise in alten Kontrollbeschreibungen müssen Sie deshalb umstellen.

Ausgangssituation: ein SaaS-Anbieter vor der ersten Prüfung

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt ein Portal, über das Arztpraxen Laboraufträge erteilen und Befunde empfangen. Der Dienst läuft auf der Infrastruktur eines großen Cloud-Anbieters in einem verwalteten Kubernetes-Cluster, mit verwalteter Datenbank und Objektspeicher. Protokolle gehen an einen SIEM-Dienst eines spezialisierten Dienstleisters. Das Betriebsteam besteht aus fünf Personen mit wöchentlicher Rufbereitschaft.

So sieht es vor dem Projekt aus:

• Die Datenbank erstellt automatisch Snapshots; eine Wiederherstellung wurde zuletzt vor zwei Jahren bei einem Fehler durchgeführt, nicht als geplanter Test.
• Ein Schwachstellenscanner prüft die Knoten des Clusters, die Container-Images und die eingebundenen Bibliotheken aber nicht.
• Kritische Funde behandelt das Team schnell, feste Fristen je Schweregrad gibt es nicht.
• Das SIEM sammelt Protokolle, die Regeln wurden seit der Einführung nicht angepasst.
• Für Produktanalysen werden Nutzungsdaten der Praxen ausgewertet; was davon im Vertrag steht, weiß niemand genau.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

In OPS teilen sich Anbieter und Plattform viele Aufgaben, und der Katalog nennt bei mehreren Kriterien ausdrücklich Mitwirkungspflichten der Kunden. Unsere Einordnung für das Beispiel:

Plattform und SIEM-Dienstleister sind Subdienstleister (Subservice-Organisationen). Nutzen Sie für sie die Carve-out-Methode, liegen deren Kontrollen außerhalb Ihrer Prüfung, die Verantwortung für die Kriterien bleibt aber bei Ihnen; die Überwachung läuft über das Gebiet SSO. Wie Sie die Methode wählen, steht auf der Seite C5-Scope.

Beispiel-Kontrollbeschreibung zu OPS-25

OPS-25 verlangt, die Systemkomponenten im Verantwortungsbereich des Anbieters „mindestens monatlich einem Schwachstellenscan“ zu unterziehen, mit Abgleich gegen aktuelle Schwachstellendatenbanken wie CVE oder EUVD (OPS-25.01B). Der Schweregrad wird nach definierten Kriterien bewertet, Maßnahmen beginnen innerhalb definierter Zeitfenster, und die Ergebnisse fließen in die SIEM-Regeln ein (OPS-25.02B bis 04B). Die Fristen selbst legt die Richtlinie nach OPS-18 fest; dort verlangt der Katalog unter anderem, dass die Bearbeitung „hoher“ Schwachstellen binnen eines Arbeitstags beginnt (OPS-18.03B). Unsere Beispiel-Kontrolle (eigene Formulierung, kein Katalogtext):

Die ergänzenden Informationen zu OPS-25 nennen als Beispiel für einen risikobasierten Rahmen mit CVSS-Zeitfenstern etwa 24 bis 48 Stunden für „kritisch“ und einen Monat für „niedrig“; das erweiternde Unterkriterium OPS-25.01AC verlangt einen solchen risikobasierten Rahmen, die Zahlen selbst sind ein Beispiel, keine Vorgabe. Die Daten der Softwarekomponenten können, müssen aber nicht, über eine SBOM ermittelt werden.

Welche Nachweise der Prüfer sehen will

OPS erzeugt viele Nachweise mit festem Rhythmus. Bei einem Typ-2-Bericht muss jeder Rhythmus im Zeitraum lückenlos belegt sein. Beispiele aus dem Szenario:

Wie Sie diese Nachweise je Unterkriterium und Fälligkeit verwalten, zeigt die Seite Nachweise und Dokumentation.

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken ergeben sich aus dem Wortlaut der Kriterien und dem Szenario. Ist ein einziges Unterkriterium nicht erfüllt, gilt das Kriterium als nicht erfüllt, und der Prüfer berichtet die Abweichung (Abschnitte 3.4.12 und 3.4.13).

Welche Lücken die Prüfung tatsächlich blockieren und in welcher Reihenfolge Sie sie schließen, klärt eine Maßnahmenplanung über alle Gebiete.

Alle Kriterien des Themengebiets OPS

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 (B = Basis, AS = verschärfend, AC = erweiternd). Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Sicherheitsvorfälle im engeren Sinn regelt das Gebiet SIM; OPS-19 legt fest, wann eine Störung dorthin eskaliert wird.

Bezug zu ISO/IEC 27001:2022 Anhang A

Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm.