Die NIS2-Richtlinie zur Cybersicherheit ist seit mehreren Jahren auf europäischer Ebene in Kraft. Es handelt sich um eine Richtlinie, die europäische Organisationen nicht nur dazu auffordert, neue Sicherheitstools anzuschaffen. Sie verlangt, dass Cyber-Risiken durch überprüfbare technische, operative und organisatorische Prozesse verwaltet werden: vom Incident Management bis zur Betriebskontinuität, vom Change Management bis zur Sicherheit der Lieferkette. Der entscheidende Punkt sei gleich zu Beginn hervorgehoben: Viele dieser Prozesse existieren bereits innerhalb des ITSM. Das Problem ist, dass die NIS2-Compliance in zahlreichen Organisationen nach wie vor als isoliertes Projekt behandelt wird, das fast ausschließlich den Teams für Cybersicherheit, Risikomanagement oder der Rechtsabteilung übertragen wird.
Dabei wird ein erheblicher Teil der von den Regulierungsbehörden geforderten Nachweise täglich vom Service Desk, von Incident-Management-Workflows, von Change-Management-Prozessen und von Lieferanten-Managementsystemen erzeugt. Die eigentliche Herausforderung vieler Unternehmen besteht daher nicht darin, neue Kontrollen von Grund auf zu schaffen. Sie besteht darin, die Anforderungen aus Regulierungen wie der NIS2-Richtlinie und Compliance-Anforderungen mit den bereits vorhandenen ITSM-Prozessen zu verknüpfen, deren Reifegrad zu erhöhen und operative Daten in zuverlässige Compliance-Nachweise umzuwandeln.
Genau darauf konzentrieren wir uns in diesem Artikel.
Vom regulatorischen Anforderung zur operativen Governance
Machen wir einen Schritt zurück, um die Frage anhand eines konkreten Fallbeispiels einzuordnen. Die NIS2-Richtlinie, formal die EU-Richtlinie 2022/2555, trat am 16. Januar 2023 in Kraft. Die Mitgliedstaaten mussten sie bis zum 17. Oktober 2024 umsetzen und die neuen europäischen Regeln gelten seit dem 18. Oktober 2024 durch die jeweiligen nationalen Rechtsvorschriften. Für Organisationen, die in mehreren europäischen Ländern tätig sind, ist es daher auch erforderlich, die spezifischen Umsetzungsmodalitäten in den einzelnen Rechtsordnungen zu prüfen.
Der Anwendungsbereich ist deutlich weiter gefasst als bei der früheren NIS-Richtlinie. Er umfasst öffentliche und private Organisationen aus 18 kritischen Sektoren, darunter Energie, Verkehr, Gesundheit, digitale Infrastrukturen, Cloud-Dienste, Rechenzentren, verwaltete IKT-Dienstleistungen, öffentliche Verwaltung, industrielle Produktion und Forschung.
Doch die wichtigste Änderung betrifft nicht nur die Anzahl der betroffenen Einrichtungen. Die NIS2-Richtlinie bringt Cybersicherheit in die Unternehmensführung. Leitungsorgane müssen die Maßnahmen zum Cyber-Risikomanagement genehmigen sowie überwachen und können für Mängel der Organisation zur Verantwortung gezogen werden.
Sicherheit kann daher nicht mehr auf das SOC beschränkt oder an eine kleine Gruppe von Spezialisten delegiert werden. Sie muss Teil des normalen Betriebs des Unternehmens werden. Genau hier kommt ITSM ins Spiel.
Warum Compliance über ITSM läuft
Eine reife ITSM-Umgebung basiert auf einigen Grundsätzen, die mit den Erwartungen einer Richtlinie wie der NIS2 übereinstimmen:
- klar definierte Verantwortlichkeiten
- Klassifizierung und Priorisierung von Ereignissen
- regelbasierte Eskalationen
- SLAs und zeitliche Schwellenwerte
- Genehmigung und Nachverfolgung von Änderungen
- Kenntnis der betroffenen Assets und Services
- Überwachung der Lieferantenleistung
- vollständige Dokumentation der Aktivitäten
- kontinuierliche Verbesserung.
Ein korrekt verwaltetes Ticket ist nicht nur eine operative Anfrage, sondern eine dokumentierte Abfolge von Entscheidungen, Verantwortlichkeiten, Kommunikationen und Maßnahmen. Ebenso ist ein Change Record nicht einfach die Genehmigung zur Installation einer neuen Softwareversion. Er kann zum Nachweis werden, dass die Organisation Risiken bewertet, Auswirkungen analysiert, einen Rollback-Plan definiert und die erforderlichen Genehmigungen eingeholt hat.
Es ist dasselbe Prinzip, das bereits in unserem früheren Artikel zur Integration von KI in ITSM im Lichte des EU AI Act behandelt wurde: Je mehr Technologie in Geschäftsprozesse einfließt, desto mehr werden Owner, Kontrollen, Dokumentation und Audit Trails benötigt.
In beiden Fällen kann die ITSM-Plattform zum Verbindungspunkt zwischen Richtlinien und dem operativen Betrieb werden. Hier hört Compliance auf, eine Sammlung von Dokumenten zu sein, und wird zu einem operativen Prozess.
Incident Management: Fristen einhalten beginnt beim ersten Ticket
Gehen wir mit einem weiteren Beispiel aus der NIS2-Richtlinie ins Detail. Diese setzt eine mehrstufige Meldepflicht für erhebliche Vorfälle. Im Allgemeinen sind vorgesehen:
- eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme des Vorfalls
- eine Meldung innerhalb von 72 Stunden, einschließlich einer ersten Bewertung
- einen Abschlussbericht innerhalb eines Monats, mit Einzelheiten zu den Auswirkungen, den Ursachen und den ergriffenen Korrekturmaßnahmen
Die Einhaltung dieser Fristen hängt nicht nur von der Leistungsfähigkeit des Sicherheitsteams, sondern davon, was in den ersten Minuten am Service Desk passiert, ab.
Der Incident-Management-Workflow muss zunächst zuverlässig zwischen einem normalen technischen Problem und einem potenziellen Sicherheitsvorfall unterscheiden. Anschließend müssen sofort die notwendigen Informationen erfasst werden: betroffener Service, betroffene Assets, betroffene Benutzer, Ursprung der Meldung, Kritikalitätsstufe, mögliche Ausbreitung, Abhängigkeiten und geschäftliche Auswirkungen.
Die Klassifizierung kann nicht einzelnen Urteilen überlassen bleiben. Es braucht gemeinsame Kategorien, Prioritäten und Eskalationsregeln. Ein Ticket, das potenziell für NIS2 relevant ist, sollte automatisch auslösen:
- die Benachrichtigung des Cybersicherheits-Verantwortlichen
- die Einbeziehung des Incident Managers
- die Erstellung einer überprüfbaren Zeitleiste
- die Anwendung von SLAs, die mit den regulatorischen Fristen übereinstimmen
- die Aufbewahrung technischer und entscheidungsbezogener Nachweise
- den Start des Kommunikations-Workflows in Richtung Management, Rechtsabteilung und Compliance
Eine Lösung zur Incident-Management-Automatisierung wie die von EasyVista ermöglicht es, die Erfassung, Klassifizierung, Zuweisung und Überwachung von Vorfällen zu zentralisieren und das Risiko zu reduzieren, dass ein schwerwiegendes Ereignis in einer E-Mail, einem Chat oder einer allgemeinen Warteschlange stecken bleibt. Das ist ein erster konkreter Schritt in Richtung Compliance.
Change Management: Keine Änderung ohne Risikobewertung
Nicht alle Vorfälle entstehen durch einen externen Angriff. Ein erheblicher Teil der Probleme entsteht durch schlecht geplante Änderungen, fehlerhafte Konfigurationen, unvollständige Updates oder Änderungen, die ohne angemessene Bewertung der Abhängigkeiten eingeführt wurden.
Deshalb ist das Change Management eine der wichtigsten Verbindungen zwischen der NIS2-Richtlinie, ITSM-Compliance und dem täglichen Service Management. Ein compliance-bereiter Workflow sollte mindestens Folgendes dokumentieren:
- Grund und Ziel der Änderung
- betroffene Services, Assets und Konfigurationen
- Bewertung der operativen und sicherheitsbezogenen Auswirkungen
- technische Abhängigkeiten
- eingeholte Genehmigungen
- Testplan
- Implementierungsfenster
- Rollback-Plan
- Ergebnis der Änderung
- etwaige nachfolgende Vorfälle oder Schwachstellen
Standard- und risikoarme Änderungen können automatisiert werden. Solche, die wesentliche Services, privilegierte Zugänge, Sicherheitskonfigurationen oder exponierte Komponenten betreffen, müssen hingegen robustere Kontrollen vorsehen und, wenn nötig, die Einbeziehung der Sicherheitsverantwortlichen.
Supplier Management: Die Lieferkette muss in ITSM-Workflows integriert werden
Die Sicherheit der Lieferkette ist eine der Säulen der NIS2-Richtlinie. Organisationen müssen nicht nur die Risiken in ihren eigenen Systemen berücksichtigen, sondern auch jene, die mit direkten Lieferanten von IKT-Produkten und -Diensten verbunden sind. Cloud-Anbieter, Managed Service Provider, Softwareanbieter, Support-Partner und Outsourcer können wesentliche Abhängigkeiten für die Erbringung von Diensten darstellen. Es reicht nicht mehr aus, eine allgemeine Klausel in den Vertrag aufzunehmen.
Das Supplier Management sollte daher umfassen:
- ein aktuelles Inventar der Lieferanten und der erbrachten Dienste
- die Klassifizierung der Anbieter nach Kritikalität
- die Zuordnung zwischen Lieferant, Vertrag, Service und Asset
- Mindestsicherheitsanforderungen
- verbindliche Fristen für die Meldung von Vorfällen
- Prüf- und Auditrechte
- Eskalationsverfahren
- regelmäßige Risikobewertungen
Was bedeutet es also, im ITSM „compliance-ready“ zu sein?
Die Antwort auf diese Frage ist nicht trivial. Compliance-bereit zu sein bedeutet nicht, erklären zu können, dass eine Plattform allein „die Konformität mit der NIS2-Richtlinie herstellt“.
Konformität hängt vom Zusammenspiel zwischen Menschen, Prozessen, Technologien, Governance und Sicherheitsmaßnahmen ab. Eine ITSM-Software kann jedoch die notwendige operative Architektur bereitstellen, um Kontrollen anzuwenden und die entsprechenden Nachweise zu erzeugen. Eine compliance-bereite ITSM-Umgebung sollte in der Lage sein, schnell auf sehr konkrete Fragen zu antworten:
- Wer hat diesen Vorfall klassifiziert und auf Basis welcher Kriterien?
- Wann begann der 24-Stunden-Countdown?
- Welche Services und Assets waren betroffen?
- Wer hat eine kritische Änderung genehmigt?
- Welche Risikobewertung wurde durchgeführt?
- Welcher Lieferant war für die Komponente verantwortlich?
- Welche Korrekturmaßnahmen wurden abgeschlossen? Wie wurden sie überprüft?
- Was hat sich nach dem Post-Incident-Review geändert?
Die Fähigkeit zu antworten darf nicht vom Gedächtnis Einzelner abhängen. Sie muss aus den Workflows, den Records und den Audit Trails hervorgehen.
Deshalb ermöglichen Produkte wie EV Service Manager, die Service-Management-Prozesse zu strukturieren, Informationen zu zentralisieren und Aufgaben der Zuweisung, Eskalation, Genehmigung und Berichterstattung zu automatisieren.
Fazit
Die NIS2-Richtlinie sollte wie andere europäische Vorschriften keine zweite, parallele Prozesse-Infrastruktur neben der IT schaffen. ITSM-Disziplinen wie das Management von Incidents, Changes, Problemen und Assets regeln bereits Services. Compliance von diesen Prozessen zu trennen bedeutet, Aktivitäten zu duplizieren, Kosten zu erhöhen und fragmentierte Nachweise zu produzieren.
Sie in das ITSM zu integrieren bedeutet hingegen, jedes Ticket, jede Genehmigung, jede Eskalation und jede Überprüfung zu einem kohärenten Teil der Governance zu machen.
Daraus ergibt sich ein doppelter Vorteil. Einerseits verbessert die Organisation ihre Fähigkeit, die eigene Konformität nachzuweisen. Andererseits wird sie tatsächlich widerstandsfähiger: Sie erkennt Vorfälle früher, koordiniert die Reaktion besser, kontrolliert Änderungen, kennt die Abhängigkeiten und verwaltet Lieferanten mit größerer Sorgfalt.
FAQ
Was ist die NIS2-Richtlinie?
NIS2 ist die europäische Richtlinie, die die Cybersicherheitspflichten für Organisationen in kritischen Sektoren gestärkt und erweitert hat. Sie führt Anforderungen in Bezug auf das Risikomanagement, die Reaktion auf und Meldung von Vorfällen, die Betriebskontinuität, die Lieferkettensicherheit und die Verantwortung der Leitungsorgane ein.
Wie unterstützt ITSM die europäische Compliance?
ITSM bietet strukturierte Prozesse zur Erfassung, Klassifizierung, Zuweisung, Überwachung und Dokumentation von Vorfällen, Änderungen, Problemen, Assets und Lieferanten-Aktivitäten. Diese Prozesse unterstützen dabei, beispielsweise NIS2-Kontrollen anzuwenden und überprüfbare Audit Trails sowie Nachweise zu erzeugen.
Garantiert eine ITSM-Plattform automatisch die europäische Compliance?
Nein. Keine Software garantiert allein die Konformität. Eine ITSM-Plattform kann jedoch die Anwendung von Prozessen, die Automatisierung von Kontrollen, die Erfassung von Informationen, die Zusammenarbeit zwischen Teams und die Erstellung der geforderten Nachweise unterstützen.
