Es ist Freitagnachmittag und ein Speicherfehler hat mehrere Systeme getroffen. Neben der Wiederherstellung des Dienstes läuft eine zweite Uhr: Wenn dies ein großes Incident ist, muss es innerhalb einer kurzen Frist gemeldet werden. Jemand fragt: „Welche Dienste waren betroffen, wie viele Benutzer und wie kritisch sind sie?“ Die Antwort wird aus Monitoring, einer Excel-Tabelle der Dienste und dem Gedächtnis erfahrener Kollegen zusammengesetzt. Die gleichen Fragen kommen während einer Inspektion erneut – nur später und mit der Bitte um Beweise.
Was die Vorschriften verlangen
NIS2 und DORA unterscheiden sich in ihrem Umfang und in ihren Aufsichtsbehörden, aber aus Sicht der IT-Operationen kommen die gleichen Anforderungen immer wieder zurück:
- kennen Sie die Auswirkungen eines Ausfalls auf Dienste und deren Kritikalität,
- melden Sie große Incidents innerhalb festgelegter Fristen und mit ausreichenden Beweisen,
- verwalten Sie Änderungen und Schwachstellen und können nachweisen, wer was genehmigt hat,
- behalten Sie einen Überblick über die IKT-Dienste und -Anbieter, von denen die Operationen abhängen,
- verfolgen Sie die Rechenschaftspflicht – wer besitzt den Dienst und wer hat was geändert, wann.
Keine dieser Anforderungen ist neu. Neu ist der Druck, dass die Antworten schnell, vollständig und nachweisbar sein müssen.
Was Stilla heute abdeckt
Die Grundlage für die regulatorischen Antworten ist die Daten, die Stilla für den täglichen Betrieb verwaltet:
- Eine Abhängigkeitskarte vom Business-Service bis zur Infrastruktur und Wirkungsberechnung, die Redundanzen berücksichtigt – Cluster, Datenbankreplikation, gespiegelte Speicherung.
- Ein Besitzer für jeden Dienst, bereichsspezifische Rollen und eine RACI-Matrix, die Stilla gegen Berechtigungen überprüft.
- Ein unveränderlicher Audit-Trail für fünf Jahre; für die Konfiguration wird der Zustand vor und nach einer Änderung gespeichert.
- Verwaltete Änderungen, die vom Besitzer des betroffenen Dienstes genehmigt werden, Wartungsfenster und Change-Freeze.
- Dienstverträge und Anbieter-SLAs, einschließlich Incident-Eskalation an den Anbieter gemäß Vertrag.
- Schwachstellen nach Dienst mit Fristen nach Schweregrad, wobei aktiv ausgenutzte Fehler unterschieden werden.
Wenn ein Incident auftritt, zeigt Stilla die betroffenen Dienste aus der Abhängigkeitskarte, nicht aus einer Schätzung. Der Service Owner kann nachverfolgt werden und die Änderungshistorie zeigt, was in den letzten Tagen geändert wurde.
Was in Vorbereitung ist
Aufbauend auf diesen Daten erstellen wir regulatorische Ausgaben, die noch nicht Teil des Produkts sind:
- Klassifizierung großer Incidents nach NIS2- und DORA-Kriterien, abgeleitet aus der Wirkung in der CMDB,
- Ein vorab gefüllter Bericht mit Zeitstrahl und Wirkung,
- Ein Register von IKT-Diensten und -Anbietern unter DORA.
Das Prinzip bleibt dasselbe wie im Rest des Produkts: Stilla bereitet die Beweise vor, eine Person entscheidet und übermittelt immer. Wir werden den Release-Zeitpunkt mit Pilotkunden bestätigen.
Wo anfangen
Eine regulatorische Antwort ist nur so gut wie die Daten darunter. Deshalb empfehlen wir, dort anzufangen, wo es sich auch ohne Regulierung auszahlt: mit den Schlüsseldiensten, ihren Besitzern und der Abhängigkeitskarte. Wer dies in Ordnung hat, hat die meiste Arbeit bereits erledigt – und am Freitagnachmittag Antworten aus Daten, nicht aus dem Gedächtnis.
Stilla ersetzt keine rechtliche Bewertung. Überprüfen Sie die spezifischen Verpflichtungen Ihres Unternehmens mit Ihrem Compliance-Team.
Stilla Standard
Für Organisationen, die eine zuverlässige CMDB und verwaltete ITSM-Prozesse wünschen.