Viele Unternehmen lesen bei NIS-2 zuerst die Meldepflichten und denken dann: Also brauchen wir vor allem ein Formular, ein paar Eskalationsstufen und irgendeinen Incident-Plan.
Genau das greift zu kurz.
NIS-2 meint mit Vorfallmanagement nicht bloß das spätere Melden an Behörden wie das BSI. Es geht um einen belastbaren Umgang mit Sicherheitsvorfällen insgesamt: erkennen, einstufen, reagieren, koordinieren, dokumentieren, auswerten und nur bei erheblichen Vorfällen zusätzlich fristgerecht melden. NIS-2 selbst verankert Incident Handling ausdrücklich als Teil der Risikomanagementmaßnahmen; ENISA ordnet daneben auch Business Continuity und Crisis Management als unmittelbar dazugehörige Themen ein.
Die kurze Antwort
Ein gutes Informationssicherheitsvorfall-Management nach NIS-2 braucht mindestens diese Bausteine:
- klare Melde- und Eskalationswege;
- saubere Erkennung und Einstufung von Ereignissen;
- definierte Rollen und Verantwortlichkeiten;
- technische und organisatorische Reaktion;
- Dokumentation und Beweissicherung;
- Nachbereitung und Verbesserung;
- und bei erheblichen Vorfällen die fristgerechte Meldung an das BSI beziehungsweise an die zuständige Stelle.
Das ist der entscheidende Punkt: NIS-2 will nicht nur, dass Sie später melden können. NIS-2 will, dass Sie Vorfälle beherrschen können. Das BSI beschreibt Risikomanagementmaßnahmen allgemein als geeignet, verhältnismäßig und wirksam; die Verantwortung für Umsetzung und Überwachung liegt bei der Geschäftsleitung.
Was ein Informationssicherheitsvorfall überhaupt ist
Ein Informationssicherheitsvorfall ist nicht erst der große Ransomware-Fall mit Pressemitteilung.
Praktisch beginnt das Thema viel früher: kompromittierte Konten, Phishing mit erfolgreicher Eingabe von Zugangsdaten, unbefugter Zugriff, Schadsoftware auf einem System, Fehlkonfiguration mit Sicherheitsauswirkung, Datenabfluss, Manipulation von Diensten oder der Ausfall sicherheitsrelevanter Systeme. Der bestehende Artikel nennt mit Phishing, Ransomware und unbefugtem Zugriff bereits genau die richtige Richtung. Entscheidend ist nur, dass Unternehmen solche Ereignisse nicht erst dann ernst nehmen, wenn der Schaden schon maximal ist.
NIS-2 denkt Vorfallmanagement breiter als viele Unternehmen
Viele Unternehmen verengen Incident Management auf "IT löscht, sperrt oder trennt etwas vom Netz". Das ist zu klein.
Ein Vorfall ist unter NIS-2 nicht nur ein technisches Problem. Er ist oft gleichzeitig ein Führungs-, Kommunikations-, Nachweis- und Fortführungsproblem. Genau deshalb nennt ENISA in der NIS-2-Umsetzungslogik neben Incident Handling ausdrücklich auch Monitoring and Logging, Event Reporting, Event Assessment and Classification, Incident Response sowie Post-Incident Reviews. Zusätzlich gehören Business Continuity und Crisis Management mit ins Bild. Das ist die eigentliche Botschaft: Ein Vorfall muss nicht nur technisch gestoppt, sondern organisatorisch beherrscht werden.
Der häufigste Denkfehler
Der häufigste Denkfehler lautet: Wir brauchen vor allem eine Meldepflicht-Checkliste.
Das ist zu wenig.
Die Meldung ist nur ein Teil des Ganzen. Wenn ein Unternehmen einen Vorfall nicht sauber erkennt, intern falsch einstuft, keine Rollen geklärt hat, keine Beweise sichert und im Ernstfall chaotisch reagiert, hilft auch die formale Meldung nur begrenzt. ENISA betont, dass wirksame und rechtzeitige Incident Reporting-Prozesse ein Eckpfeiler von NIS-2 sind - aber eben als Teil der Reaktionsfähigkeit, nicht als Ersatz dafür.
Was ein belastbarer Vorfallprozess praktisch enthalten sollte
Ein brauchbarer NIS-2-konformer Vorfallprozess braucht keine Heldengeschichten und keine hundertseitige Notfallbibel. Er braucht vor allem Klarheit.
1. Meldeweg für Beobachtungen und Verdachtsfälle
Mitarbeiter müssen wissen, wohin sie sich wenden, wenn etwas verdächtig wirkt. Ohne klaren Eingangskanal wird Incident Management zum Zufallsprodukt. Event Reporting ist ausdrücklich als eigener Baustein in der Incident-Handling-Struktur gedacht.
2. Einstufung und Bewertung
Nicht jedes Sicherheitsereignis ist gleich ein meldepflichtiger erheblicher Sicherheitsvorfall. Genau deshalb braucht es eine Stelle oder ein Team, das Ereignisse bewertet und klassifiziert. Das BSI unterscheidet im Meldekontext unter anderem zwischen Sicherheitsvorfall, erheblichem Sicherheitsvorfall und Beinahevorfall; meldepflichtig sind die erheblichen Sicherheitsvorfälle.
3. Sofortmaßnahmen und Schadensbegrenzung
Sobald ein Vorfall plausibel ist, müssen erste Gegenmaßnahmen sitzen: Systeme isolieren, Zugänge sperren, Kommunikationswege absichern, kritische Services stabilisieren. Der bestehende Artikel nennt das bereits richtig, etwa beim Trennen kompromittierter Systeme und der Nutzung sicherer Kommunikationswege.
4. Rollen, Verantwortung und Eskalation
Jemand muss entscheiden, wer technisch führt, wer intern informiert wird, wer mit Management, Datenschutz, Kunden oder Dienstleistern spricht und wann aus einem Sicherheitsereignis ein Krisenthema wird. Das BSI betont für NIS-2 insgesamt die Verantwortung der Geschäftsleitung für Umsetzung und Überwachung der Maßnahmen. Genau deshalb darf Incident Management nicht nur als IT-Sache definiert werden.
5. Beweissicherung und Dokumentation
Logfiles, Zeitpunkte, betroffene Systeme, erste Maßnahmen, Kommunikationsschritte und Erkenntnisse müssen nachvollziehbar festgehalten werden. Sonst fehlt später die Grundlage für Analyse, Meldung und Verbesserung. Auch der bestehende Artikel hebt Logfiles, E-Mails, Screenshots und eine saubere Zeitleiste bereits zu Recht hervor.
6. Nachbereitung
Ein guter Prozess endet nicht mit "läuft wieder". Post-Incident Reviews gehören ausdrücklich zur von ENISA beschriebenen Incident-Handling-Logik. Wer aus Vorfällen nichts lernt, wird dieselben Probleme später nur teurer wiedersehen.
Die Meldepflicht: wichtig, aber nicht der ganze Film
In Deutschland ist für betroffene Einrichtungen seit dem 06.12.2025 der neue NIS-2-Rahmen praktisch relevant. Das BSI-Portal dient dabei unter anderem als Meldestelle für schwerwiegende Sicherheitsvorfälle. Das BSI stellt außerdem klar, dass vor Registrierung im Portal ein Online-Formular für erhebliche Sicherheitsvorfälle genutzt werden kann.
Wichtig für die Fristenlogik ist: Der erste Meldeimpuls kommt sehr früh. ENISA beschreibt für NIS-2 eine frühe Warnung innerhalb von 24 Stunden und eine vollständige Incident Notification innerhalb von 72 Stunden. Das BSI beschreibt die Erstmeldung ebenfalls mit einer 24-Stunden-Frist nach Kenntniserlangung. Genau deshalb brauchen Unternehmen keine "spätere saubere Aufarbeitung", sondern sehr frühe interne Handlungsfähigkeit.
24 Stunden sind schnell vorbei
In fast jedem Erstgespräch zu diesem Thema unterschätzen Unternehmen, wie kurz 24 Stunden im Ernstfall wirklich sind.
Wenn in den ersten Stunden noch unklar ist,
- wer entscheidet;
- wessen Verantwortung es ist, die Technik zu prüfen;
- wer Management informiert;
- wer den Vorfall klassifiziert;
- und wer die Meldung vorbereitet;
dann ist die Frist praktisch schon halb verloren. Genau deshalb ist NIS-2-Vorfallmanagement in Wahrheit ein Vorbereitungs-Thema, nicht erst ein Reaktions-Thema. Die Pflicht zur frühen Meldung innerhalb von 24 Stunden macht das unmissverständlich.
Was ein Auditor oder Prüfer sehen wollen würde
Im Kontext NIS-2 wird niemand alleine deswegen beeindruckt sein, weil irgendwo ein Incident-Response-Dokument im SharePoint liegt.
Überzeugend ist vielmehr, wenn sichtbar ist:
- wie Vorfälle erkannt und gemeldet werden;
- wer sie bewertet;
- wie zwischen Ereignis, Vorfall und erheblichem Vorfall unterschieden wird;
- welche Sofortmaßnahmen vorgesehen sind;
- wie Logging, Beweissicherung und Kommunikation laufen;
- und wie Lessons Learned wieder in die Sicherheitsmaßnahmen zurückfließen.
Genau diese Punkte passen direkt zu der von ENISA beschriebenen Struktur aus Event Reporting, Assessment, Response und Post-Incident Review.
Ein pragmischer Start für Unternehmen
Wenn ein Unternehmen das Thema heute schlank, aber brauchbar aufsetzen will, reicht als Start oft schon Folgendes:
- einen klaren Meldeweg definieren;
- ein kleines Incident-Team benennen;
- Einstufungskriterien für Ereignisse, Vorfälle und erhebliche Vorfälle festlegen;
- einen kurzen Maßnahmenkatalog für die ersten Stunden dokumentieren;
- Management- und Kommunikationswege klären;
- die Meldepflichten und Fristen praktisch üben;
- nach echten oder simulierten Vorfällen nachschärfen.
Das ist meist wertvoller als eine perfekte Vorlage, die im Ernstfall niemand anwenden kann. Diese Empfehlung ist eine praxisnahe Ableitung aus den offiziellen Meldefristen und der Incident-Handling-Struktur. ENISA hat hier noch mehr dazu geschrieben.
FAQ
NIS-2 verlangt nicht nur die Meldung erheblicher Vorfälle, sondern im Kern belastbare Risikomanagementmaßnahmen rund um Incident Handling. ENISA ordnet dazu unter anderem Monitoring and Logging, Event Reporting, Event Assessment and Classification, Incident Response und Post-Incident Reviews ein.
Nein. Die Meldepflicht ist nur ein Teil. Unternehmen müssen Vorfälle auch erkennen, einstufen, bearbeiten, dokumentieren und auswerten können.
Nach der NIS-2-Logik erfolgt eine frühe Warnung innerhalb von 24 Stunden und eine weitergehende Meldung innerhalb von 72 Stunden. Das BSI nennt für die Erstmeldung ebenfalls eine Frist von 24 Stunden nach Kenntniserlangung.
Für NIS-2-betroffene Einrichtungen dient das BSI-Portal unter anderem als Meldestelle für schwerwiegende Sicherheitsvorfälle.
Ja. Das BSI betont bei NIS-2 die Verantwortung der Geschäftsleitung für Umsetzung und Überwachung der Risikomanagementmaßnahmen. Ein erhebliches Incident Management kann deshalb nicht nur irgendwo in der IT "mitlaufen".
Unser Tipp
Informationssicherheitsvorfall-Management nach NIS-2 ist viel mehr als eine Pflicht zur Behördenmeldung. Es geht darum, Vorfälle schnell zu erkennen, richtig einzuordnen, wirksam zu begrenzen, sauber zu dokumentieren und nur bei erheblichen Fällen zusätzlich fristgerecht zu melden. Wer dafür schon vor dem Ernstfall Rollen, Wege und Entscheidungen klärt, gewinnt nicht nur Compliance, sondern vor allem Handlungsfähigkeit. Genau das ist der Unterschied zwischen einem Vorfallprozess auf dem Papier und einem, der im Ernstfall trägt.
Interesse geweckt?
Wenn Sie Ihr Vorfallmanagement so aufsetzen wollen, dass es unter NIS-2 nicht nur formal stimmt, sondern im Ernstfall wirklich funktioniert, sprechen Sie mit uns oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!