NIS2 Incident Management ist mehr als Störungsbearbeitung
§ 30 BSIG nennt die Bewältigung von Sicherheitsvorfällen ausdrücklich als Risikomanagementmaßnahme. Für NIS2 muss Incident Management technische Reaktion, Geschäftsfolgen, regulatorische Bewertung, Kommunikation, Evidenz und Managementeskalation zusammenführen.
Der Incident-Lebenszyklus
| Phase | Ziel |
|---|---|
| Prepare | Rollen, Playbooks, Kontakte, Werkzeuge und Entscheidungswege vorbereiten |
| Detect & Triage | Ereignis erkennen, klassifizieren und Geschäftskontext herstellen |
| Contain | Ausbreitung begrenzen und kritische Dienste schützen |
| Eradicate | Ursache und Persistenz beseitigen |
| Recover | Dienste kontrolliert wiederherstellen und überwachen |
| Learn | Ursachen, Kontrolllücken und Maßnahmen in Governance überführen |
Severity ist nicht dasselbe wie NIS2-Erheblichkeit
Ein internes Severity-Modell kann technische Dringlichkeit bewerten. Die gesetzliche Erheblichkeitsbewertung betrachtet zusätzlich mögliche schwerwiegende Betriebsstörungen, finanzielle Verluste und erhebliche Schäden für andere. Beide Bewertungen sollten verbunden, aber nicht verwechselt werden.
Die regulatorischen Fristen beschreibt NIS2-Meldepflichten.
Rollenmodell und Entscheidungsrechte
Ein belastbarer Prozess trennt operative Incident-Führung, technische Workstreams, Business Impact Assessment, regulatorische Bewertung und Executive Entscheidungen. Für kritische Vorfälle müssen Entscheidungsrechte für Isolation, Abschaltung, Wiederanlauf, externe Unterstützung und Kommunikation vorab geklärt sein.
Evidenz und Timeline
Eine konsistente Incident-Timeline ist für technische Analyse, Managemententscheidungen, Meldungen und Lessons Learned zentral. Zeitpunkt der Kenntniserlangung, Klassifizierungsentscheidungen, Auswirkungen, Maßnahmen, Freigaben und Kommunikationsschritte sollten nachvollziehbar dokumentiert werden.
Welche Playbooks zuerst?
Priorität sollten Szenarien erhalten, die kritische Geschäftsservices oder hohe Exposition betreffen: Ransomware, kompromittierte privilegierte Konten, Datenabfluss, kritische Cloud-/Provider-Ausfälle, Lieferantenkompromittierung und Verlust zentraler Kommunikations- oder Identitätsdienste.
Tabletop und technische Übungen
Ein Plan ist erst belastbar, wenn er unter Zeitdruck funktioniert. Tabletop-Übungen testen Entscheidungen und Kommunikation; technische Übungen testen Erkennung, Isolation, Forensik, Wiederherstellung und Abhängigkeiten. Findings gehören in Risikoregister und Maßnahmensteuerung.
Typische Fehler
- Incident Response ist ausschließlich Aufgabe der IT.
- Business Impact wird erst nach technischer Behebung bewertet.
- Entscheidungsrechte für Abschaltungen sind ungeklärt.
- Forensische Evidenz wird durch hektische Wiederherstellung zerstört.
- Lessons Learned erzeugen keine verantworteten Maßnahmen.
Passende NIS2 Resources
Die Fachseite ordnet das Thema ein. Für die strukturierte Standortbestimmung und die organisatorische Umsetzung stehen die NIS2 Toolkits bereit.
NIS2 Self-Assessment Toolkit
Executive Capabilities bewerten, Gaps erkennen und Handlungsbedarf priorisieren.
NIS2 Governance Toolkit
Governance-Dokumente, Prozesse, Rollen, Register, Nachweise und Implementierungshilfen für die Umsetzung.
Verwandte NIS2-Themen
Quellen und Rechtsstand
Inhaltlicher Stand: 9. August 2026. Maßgeblich bleiben der jeweils geltende Gesetzes- und Behördenstand sowie die konkrete Situation der Einrichtung.
Hinweis: Fachliche Orientierung; keine Rechtsberatung.