C5-Themengebiet OIS: Rollen, Gremien und Risikoprozess prüffähig aufsetzen

Diese Seite behandelt das Themengebiet OIS (Organisation der Informationssicherheit) des C5:2026, Abschnitt 5.1 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet OIS?

OIS regelt, wie der Cloud-Anbieter Informationssicherheit organisiert und steuert. Der Katalog nennt als Ziel die Planung, Umsetzung, Aufrechterhaltung und kontinuierliche Verbesserung eines Rahmenwerks zur Informationssicherheit innerhalb der Organisation (Abschnitt 5.1). Praktisch heißt das: Es gibt ein ISMS mit einem Anwendungsbereich, der den Dienst abdeckt, eine von der obersten Leitung verabschiedete Informationssicherheitsrichtlinie, klare Grenzen zu Kunden und Dienstleistern, getrennte Aufgaben und einen Risikoprozess mit benannten Risikoeigentümern.

Das Gebiet umfasst zehn Kriterien, OIS-01 bis OIS-10, mit 34 Basis-Unterkriterien, 2 verschärfenden und 5 erweiternden Zusatz-Unterkriterien. Neu gegenüber C5:2020 sind laut Änderungshistorie OIS-05 (Threat Intelligence), OIS-09 (Risikobehandlung) und OIS-10 (Informationssicherheit im Projektmanagement). Die Nummern haben sich verschoben: Die Richtlinie für Risikomanagement, in C5:2020 OIS-06, ist jetzt OIS-07. Viele andere Kriterien verweisen auf OIS-07, etwa „Auf der Grundlage einer Risikobeurteilung (vgl. OIS-07)“ in AM-10 bis AM-12. Ein schwacher Risikoprozess wirkt sich deshalb weit über dieses Gebiet hinaus aus.

Ausgangssituation: ein SaaS-Anbieter mit ISO-Zertifikat

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Plattform, auf der mittelständische Unternehmen und Kommunen eingehende elektronische Rechnungen empfangen, prüfen und an ihre Buchhaltung weitergeben. Rund 70 Beschäftigte, der Dienst läuft als SaaS auf der Infrastruktur eines großen Cloud-Anbieters. Der Anbieter ist nach ISO/IEC 27001 zertifiziert, der Geltungsbereich umfasst Entwicklung und Betrieb. Einige Kunden sind Kommunalverwaltungen.

So sieht es vor dem Projekt aus:

• Das Risikoregister ist eine Tabelle, die die Informationssicherheitsbeauftragte (ISB) einmal im Jahr vor dem Überwachungsaudit überarbeitet. Die Umstellung auf eine neue Datenbankarchitektur im Frühjahr hat keine Neubewertung ausgelöst.
• Restrisiken zeichnet die ISB selbst ab, weil sich sonst niemand zuständig fühlt.
• Was Kunden selbst tun müssen, steht verstreut in AGB, Leistungsbeschreibung und einem Onboarding-Wiki. Ein zusammenhängendes Dokument dazu gibt es nicht.
• Sicherheitswarnungen von Herstellern und Behörden liest das Betriebsteam, wenn sie auffallen; eine Verbindung zum Risikoregister besteht nicht.
• Das Projekt „KI-gestützte Belegerkennung“ läuft seit drei Monaten, ohne dass jemand die Risiken bewertet hat.
• Einmal im Monat trifft sich eine „Sicherheitsrunde“; Protokolle gibt es nur gelegentlich.

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

OIS liegt beim Anbieter. Auch wenn er Tätigkeiten an Subdienstleister (Subservice-Organisationen) auslagert, bleibt die Verantwortung für die Risiken nach den ergänzenden Informationen zu OIS-08 und OIS-09 bei ihm. Unsere Einordnung für das Beispiel:

Welche Kundenkontrollen Sie voraussetzen, gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung; wie Sie diese Pflichten mit Kunden abstimmen, zeigt die Seite korrespondierende Kriterien. Der Prüfer prüft solche Kontrollen nicht beim Kunden, nur ob sie sachgerecht dargestellt sind.

Wie sieht ein prüffähiges Rollen- und Gremienmodell aus?

Der Katalog schreibt kein bestimmtes Gremium vor. Er verlangt aber Handlungen bestimmter Rollen: Die oberste Leitung verabschiedet die Richtlinie (OIS-02.01B), Risikoeigentümer akzeptieren Restrisiken (OIS-07.01B, OIS-09.03B), die Ebene der Leitung, die für die Sicherheit des Dienstes verantwortlich ist, bewertet Risikobeurteilung und Behandlungspläne (OIS-07.01B Nr. 6). Rollen, die Risiken überprüfen, sollen sich nach den ergänzenden Informationen zu OIS-04 von Rollen unterscheiden, die Risiken verantworten. Ein Lenkungsausschuss für Informationssicherheit kommt im Katalog nur in einer Aufzählung von Beispielen vor (ergänzende Informationen zu SP-02). Wir empfehlen ihn trotzdem, weil dort die Entscheidungen mit Datum und Teilnehmern entstehen, die der Prüfer sehen will. Unser Modell für das Beispiel:

Die Spalte „Nicht zugleich“ ist der Kern eines Verzeichnisses der Konflikte nach OIS-04.04B. Wie kleine Teams Aufgabentrennung mit kompensierenden Kontrollen lösen, zeigt die Seite C5 für SaaS-Anbieter. Ausnahmen von Richtlinien laufen über denselben Risikoprozess; das Verfahren dafür steht auf der Seite Sicherheitsrichtlinien und Arbeitsanweisungen.

Wie läuft der Risikoprozess nach OIS-07 bis OIS-09?

OIS-07 verlangt eine dokumentierte Methodik, die vergleichbare und reproduzierbare Ergebnisse liefert; OIS-08 regelt die Beurteilung, OIS-09 die Behandlung. Der Katalog lässt qualitative, semi-quantitative und quantitative Verfahren zu und verlangt keine bestimmten formalen Rahmenwerke; schlanke Formen der Dokumentation sind ausdrücklich möglich, soweit angemessen. So setzen wir den Prozess für das Beispiel auf:

Als Anlässe nennen die ergänzenden Informationen zu OIS-08.01B unter anderem Änderungen der Bedrohungslage, Sicherheitsvorfälle, neue rechtliche oder vertragliche Anforderungen, Änderungen der Organisation oder der Architektur, Ereignisse bei Service-Organisationen, Ausnahmen von Richtlinien und kritische Schwachstellen. Halten Sie in Ihrer Methodik fest, welche dieser Anlässe bei Ihnen eine Beurteilung auslösen und wer sie meldet.

Beispiel-Kontrollbeschreibung zu OIS-08

OIS-08.01B verlangt, den Risikomanagementprozess „anlassbezogen und mindestens jährlich“ durchzuführen, OIS-08.06B eine Überprüfung durch die Risikoeigentümer mindestens jährlich und bei wesentlichen Änderungen am Dienst. Genau daran scheitert ein Register, das nur vor dem Audit gepflegt wird. Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Die 20 Arbeitstage sind unsere Empfehlung; der Katalog nennt keine Frist für die anlassbezogene Beurteilung. Wichtig ist, dass Ihre Methodik eine Frist festlegt und Sie sie einhalten. Bei einem Typ-2-Bericht prüft der Prüfer, ob die Kontrolle über den ganzen Zeitraum wirksam war, also auch, ob jeder Anlass im Zeitraum eine Bewertung hatte.

Welche Nachweise der Prüfer sehen will

Für OIS sind Nachweise überwiegend Dokumente und Protokolle mit Datum, Version und Freigabe. Beispiele aus unserem Szenario:

Ein Nachweisregister ordnet jedem Unterkriterium seinen Nachweis und seine Fälligkeit zu; wie Sie es führen, 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 oben. 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 dieser Lücken die Prüfung blockieren und in welcher Reihenfolge Sie sie schließen, klärt die Maßnahmenplanung; Risikomethodik und erste Beurteilung gehören dort zum Fundament.

Alle Kriterien des Themengebiets OIS

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.

Die Zusatzkriterien betreffen das Zertifikat (OIS-01.01AS, OIS-01.01AC), die Überwachung der Aufgabentrennung (OIS-04.01AC, OIS-04.02AC) und das Risikomanagement: OIS-08.01AS verlangt zusätzlich, die Entwicklung der Risiken zu überwachen, OIS-08.01AC die Einbindung in ein unternehmensweites Risikomanagement, OIS-08.02AC die Berücksichtigung von Innentätern.

Bezug zu ISO/IEC 27001:2022

OIS-01.01B verlangt ein ISO/IEC-27001-konformes ISMS; ein Zertifikat ist für das Basis-Unterkriterium nach den ergänzenden Informationen nicht nötig, der Prüfer bewertet gezielt die Dokumentation. Das verschärfende OIS-01.01AS verlangt eine gültige Zertifizierung, deren Anwendungsbereich den Dienst abdeckt. Was Sie aus einem zertifizierten ISMS wiederverwenden können und was trotzdem fehlt, steht auf der Seite C5 und ISO 27001.

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.