NIS2 Maßnahme 2 — Incident Handling und Vorfallmanagement

NIS2 Maßnahme 2 — Incident Handling und Vorfallmanagement

Die NIS2-Maßnahme 2 gemäß Art. 21(2)(b) verpflichtet betroffene Unternehmen, Prozesse zur Bewältigung von Sicherheitsvorfällen einzurichten und eine Erstmeldung binnen 24 Stunden abzugeben. Für NIS2 Incident Handling bedeutet das konkret: erhebliche Vorfälle erkennen, bewerten, eindämmen und wiederherstellen, die 24h-Frühwarnung, 72h-Folgemeldung und den Abschlussbericht nach 1 Monat beherrschen und jeden Schritt dokumentieren.

Letzte Aktualisierung: 20. März 2026

Die praktische Konsequenz ist eindeutig: Ein Unternehmen erfüllt NIS2 Maßnahme 2 nicht mit einem allgemeinen Krisenordner, sondern nur mit einem geübten Incident-Response-Plan, klaren Verantwortlichkeiten und belastbaren Meldewegen zum BSI. Wenn Sie zuerst den regulatorischen Rahmen der Fristen vertiefen möchten, lesen Sie ergänzend die Detailseite zur NIS2-Meldepflicht in 24 Stunden, die NIS2-Checkliste und unseren Beitrag zur NIS2-Maßnahme Risikoanalyse.

Was verlangt Art. 21(2)(b) NIS2 zum Incident Handling?

Art. 21 Abs. 2 Buchst. b der Richtlinie (EU) 2022/2555 nennt ausdrücklich die „Bewältigung von Sicherheitsvorfällen“ als Mindestmaßnahme des Cyberrisikomanagements. Gemeint ist nicht nur die technische Reaktion eines Security-Teams, sondern der gesamte Ablauf von Erkennung, Analyse, Eindämmung, Beseitigung, Wiederherstellung und dokumentierter Nachbereitung. Der deutsche Umsetzungsrahmen spiegelt diese Logik in den Entwurfsfassungen zu § 30 Abs. 2 Nr. 2 BSIG-E; für Meldeinhalte und Berichtspflichten ist außerdem § 32 BSIG-E relevant.

Für die Praxis heißt das: Sie müssen entscheiden können, wann aus einem Security Event ein erheblicher Sicherheitsvorfall wird. Diese Schwelle ist für NIS2 Vorfallmanagement zentral, weil daran die Meldepflicht nach Art. 23 NIS2 hängt. Wer erst nach vollständiger Bestätigung oder nach Abschluss der Forensik reagiert, verfehlt die Logik der Richtlinie. Die Norm erwartet Geschwindigkeit, nicht Perfektion.

Ein belastbares Incident Handling umfasst mindestens fünf Elemente:

1. Früherkennung durch Monitoring, Benutzerhinweise, Dienstleistermeldungen oder externe Hinweise.
2. Schnelle Lagebewertung mit Entscheidung, ob ein erheblicher Vorfall vorliegt oder ernsthaft vermutet wird.
3. Sofortmaßnahmen zur Eindämmung und Absicherung betroffener Systeme.
4. Wiederherstellung kritischer Dienste mit Blick auf Business Continuity.
5. Nachbereitung mit Root-Cause-Analyse, Lessons Learned und Aktualisierung des Plans.

Wichtig ist die Verzahnung mit Art. 21 Abs. 2 Buchst. c NIS2. Incident Handling steht nicht isoliert neben Backups, Disaster Recovery und Krisenmanagement, sondern bildet mit diesen Maßnahmen ein Gesamtmodell. Genau deshalb sollten Sie parallel auch die NIS2-Maßnahme Business Continuity betrachten: Ein Vorfall ist erst dann wirklich bewältigt, wenn kritische Dienste kontrolliert wieder laufen und die Organisation ihre Entscheidungen sauber belegen kann.

NIS2 Incident Handling ist außerdem ein Governance-Thema. Die Geschäftsleitung muss nicht jeden Logeintrag verstehen, aber sie muss sicherstellen, dass Zuständigkeiten, Freigaben, Eskalationen und Berichtspfade existieren. Wenn im Ernstfall unklar ist, wer Systeme isolieren darf, wer externe Forensik beauftragt, wer das BSI informiert und wer die Kundenkommunikation freigibt, liegt nicht nur ein operatives Problem, sondern ein Compliance-Defizit vor.

Die drei Meldefristen — 24h, 72h, 1 Monat

Art. 23 NIS2 strukturiert die Meldepflicht als gestuften Prozess. Das Ziel ist nicht, innerhalb von 24 Stunden einen vollständigen Untersuchungsbericht abzugeben, sondern den Behörden frühzeitig Lagebewusstsein zu verschaffen. Erst danach folgen vertiefte Informationen und der Abschlussbericht.

Die drei Fristen lassen sich wie folgt aufbereiten:

Die 24-Stunden-Frühwarnung ist bewusst eine „Speed-over-Detail“-Meldung. Sie müssen an dieser Stelle noch nicht jede technische Frage beantworten können. Entscheidend ist, dass Sie unverzüglich signalisieren, dass ein erheblicher Vorfall eingetreten ist oder sehr wahrscheinlich vorliegt, ob ein rechtswidriger oder böswilliger Hintergrund vermutet wird und ob eine grenzüberschreitende Auswirkung drohen könnte. Gerade Ransomware-Lagen, erfolgreiche unbefugte Zugriffe oder länger andauernde Ausfälle kritischer Dienste sind klassische Fälle, in denen die Frühwarnung nicht auf die endgültige Bestätigung warten darf.

Die 72-Stunden-Meldung ist die erste fachlich belastbare Bewertung. Hier sollten Sie den Vorfall klassifizieren, betroffene Systeme und Dienste benennen, die Reichweite der Störung abschätzen, erste Indicators of Compromise dokumentieren und die bereits getroffenen Gegenmaßnahmen darstellen. Für viele Organisationen ist dies der schwierigste Punkt, weil parallel technische Eindämmung, Management-Abstimmung, Kundenkommunikation und eventuell DSGVO-Fristen laufen. Genau deshalb braucht der Plan feste Rollen und vorbereitete Datenquellen.

Der Bericht nach einem Monat ist keine bloße Wiederholung der ersten Meldungen. Er dient der strukturierten Gesamtaufarbeitung. Dazu gehören die gesicherte Chronologie, bestätigte Root Cause, tatsächliche Dauer und Reichweite des Vorfalls, die Wirksamkeit der Maßnahmen, Beweissicherung, Wiederherstellung und abgeleitete Verbesserungen. Wenn ein Vorfall noch andauert, muss in der Praxis ein Zwischenstand mit Fortschrittsbericht bereitgestellt werden, bevor der endgültige Abschlussbericht nachgeliefert wird.

Ein häufiger Fehler im NIS2 Vorfallmanagement besteht darin, die Fristen als reine Behördenkommunikation zu sehen. Tatsächlich sind es interne Steuerungsfristen. Wenn Ihre Organisation die 24h-, 72h- und 1-Monats-Uhr nicht bereits in Ticketing, Eskalationskette und Krisenstab übersetzt, hilft die rechtliche Kenntnis allein nicht weiter. Ein guter Incident-Response-Plan arbeitet deshalb rückwärts: Welche Daten müssen bis Stunde 6, Stunde 24 und Tag 3 vorliegen, damit die Meldungen rechtzeitig und belastbar erfolgen?

Meldewege zum BSI — Portal, Formulare, Ansprechpartner

In Deutschland erfolgt die Meldung grundsätzlich an das BSI als zuständige Behörde beziehungsweise über die vorgesehenen Meldewege des Bundesamts. Praktisch relevant sind dafür das BSI-Portal, strukturierte Formulare und vorab definierte Ansprechpartner. Wer erst im Vorfall nach dem Zugang, den Kontaktdaten oder den geforderten Feldern sucht, verliert wertvolle Zeit.

Sie sollten deshalb vor einem Vorfall mindestens diese drei Dinge vorbereiten:

1. Zugangsdaten und Vertretungsregelung für das relevante BSI-Portal.
2. Eine intern freigegebene Meldevorlage für 24h-, 72h- und Abschlussbericht.
3. Benannte Primär- und Backup-Ansprechpartner für Technik, Compliance und Management.

Die Meldewege dienen nicht nur der Erfüllung einer Pflicht, sondern auch der Qualität Ihrer Reaktion. Eine saubere Meldung zwingt die Organisation dazu, Mindestfakten zu klären: Was ist passiert, seit wann, welche Dienste sind betroffen, welche Sofortmaßnahmen laufen, welche Außenwirkung ist zu erwarten? Wer diese Fragen innerhalb weniger Stunden nicht beantworten kann, hat meist kein Meldeproblem, sondern ein Strukturproblem im Incident Handling.

Für die operative Vorbereitung empfiehlt sich eine kompakte Melde-Matrix:

Zusätzlich sollten Sie den Meldestrom zu anderen Regimen abgrenzen. Ein erheblicher NIS2-Vorfall kann parallel Datenschutzpflichten, vertragliche Notification-Klauseln oder meldepflichtige Ereignisse gegenüber Versicherern auslösen. Das BSI ist also selten der einzige Kommunikationsadressat. Ihr Plan muss daher klar regeln, wer welche Meldung koordiniert und wie widersprüchliche Aussagen vermieden werden. Für eine vertiefte Einordnung der 24-Stunden-Logik lohnt sich die bereits erwähnte Seite zur NIS2-Meldepflicht in 24 Stunden.

In vielen Organisationen ist außerdem unklar, ob das BSI direkt aus dem Krisenstab heraus oder über Compliance beziehungsweise Legal adressiert wird. Beides kann funktionieren, solange Zuständigkeit, Freigabe und Datenschnittstelle eindeutig sind. Entscheidend ist nicht das Organigramm, sondern die Reaktionsfähigkeit: Das Team muss die Meldung binnen Stunden vorbereiten können, ohne erst über Kompetenzen zu verhandeln.

Incident-Response-Plan erstellen (Schritt-für-Schritt)

Ein NIS2-konformer Incident-Response-Plan ist die operative Übersetzung von Art. 21(2)(b) in den Alltag. Er muss kurz genug sein, um im Ernstfall genutzt zu werden, und präzise genug, um Rollen, Fristen und Maßnahmen tatsächlich zu steuern. Ein Dokument mit 80 Seiten Theorie hilft nicht, wenn niemand in der ersten Stunde die entscheidenden Schritte findet.

Der pragmatischste Aufbau besteht aus sieben Schritten:

1. Geltungsbereich und kritische Dienste definieren

Beginnen Sie mit der Frage, welche Dienste, Systeme, Standorte und Drittparteien für Ihr Unternehmen kritisch sind. Incident Handling ohne Kritikalitätsbild bleibt abstrakt. Sie müssen wissen, bei welchen Ausfällen oder Integritätsverlusten die NIS2-Meldelogik wahrscheinlich greift, welche Systeme vorrangig geschützt werden und welche Fachbereiche sofort betroffen wären.

2. Vorfallklassen und Schweregrade festlegen

Definieren Sie klare Kategorien wie Security Event, Incident, Major Incident und erheblicher Vorfall. Hinterlegen Sie objektive Trigger, etwa erfolgreiche unbefugte Zugriffe, signifikante Ausfallzeiten, hohe wirtschaftliche Schäden, Auswirkungen auf viele Nutzer oder eine vermutete grenzüberschreitende Wirkung. Diese Definitionen beschleunigen die Entscheidung, wann Art. 23 aktiviert werden muss.

3. Die erste Stunde strukturieren

Die ersten 60 Minuten sind der Engpass jedes Vorfalls. Deshalb sollte Ihr Plan minutengenau beschreiben, wer alarmiert wird, wer die erste Lagebewertung führt, wer Systeme isoliert, wer Protokoll führt und wann externe Partner hinzukommen. Auch die Frage, ob betroffene Systeme heruntergefahren werden dürfen oder zunächst forensisch gesichert werden müssen, gehört in diesen Abschnitt.

4. Meldebausteine vorbereiten

Hinterlegen Sie Vorlagen für Frühwarnung, 72-Stunden-Meldung und Abschlussbericht. Diese Vorlagen sollten nicht nur Textbausteine enthalten, sondern auch die jeweiligen Datenquellen: SIEM, EDR, IAM, Ticketsystem, Backup-Status, betroffene Services, Ansprechpartner und Management-Freigaben. So vermeiden Sie, dass das Team unter Zeitdruck Informationen neu zusammensuchen muss.

5. Wiederherstellung an Business Continuity koppeln

Incident Handling endet nicht mit der Eindämmung. Der Plan muss regeln, nach welchen Kriterien Systeme wieder in den Betrieb zurückkehren, welche Restore-Reihenfolge gilt und wer die Rückkehr in die Produktion freigibt. Gerade hier zeigt sich die Verbindung zur NIS2-Maßnahme Business Continuity: Wiederherstellung ist eine Führungsentscheidung mit technischer, rechtlicher und operativer Dimension.

6. Beweissicherung und Dokumentation integrieren

Jeder relevante Schritt muss mit Zeitstempel, Verantwortlichem und Entscheidungsgrundlage dokumentiert werden. Das betrifft technische Maßnahmen ebenso wie Management-Freigaben, Kontaktaufnahmen, Meldungen und Kommunikationsentscheidungen. Ohne diese Dokumentation wird aus einem sachlich gut bearbeiteten Vorfall schnell ein Nachweisproblem gegenüber Aufsicht, Versicherung oder externen Prüfern.

7. Übungen und Pflege verbindlich einplanen

Ein Incident-Response-Plan ist nur so gut wie seine letzte Übung. Verankern Sie deshalb feste Review- und Testzyklen, etwa Tabletop-Übungen, Restore-Tests und abgestufte Krisensimulationen. Ergänzend hilft eine NIS2-Checkliste, um den Reifegrad des gesamten Programms regelmäßig gegen Mindestanforderungen zu prüfen.

Eskalationsketten und Verantwortlichkeiten definieren

NIS2 Incident Handling scheitert in der Praxis selten an fehlenden Tools, sondern an unklaren Entscheidungen. Eine funktionierende Eskalationskette beantwortet vorab, wer alarmiert, wer führt, wer informiert und wer freigibt. Diese Fragen müssen vor dem Vorfall geklärt sein und offline verfügbar bleiben.

Eine belastbare Rollenlogik umfasst typischerweise:

Diese Rollen müssen nicht in jedem Unternehmen exakt so heißen. Entscheidend ist, dass die Verantwortung nicht im Ungefähren bleibt. Besonders wichtig sind Vertretungen. Ein Plan, der am Wochenende oder in Urlaubszeiten zusammenbricht, ist kein belastbarer Plan. Hinterlegen Sie deshalb für jede Schlüsselrolle Primär- und Backup-Verantwortliche samt Mobilnummer, Eskalationsreihenfolge und Erreichbarkeitsfenster.

Ein oft übersehener Punkt ist die Unterscheidung zwischen Informationsrecht und Entscheidungsrecht. Viele Personen müssen informiert werden, aber nur wenige sollten Entscheidungen treffen. Wenn jede Kommunikation, jede Isolationsmaßnahme und jede externe Beauftragung in großen Verteilergruppen diskutiert wird, verlieren Sie die knappen ersten Stunden. Gute Eskalationsketten sind deshalb bewusst schlank.

Ebenso relevant ist die Trennung zwischen Lagebild und Freigabeprozess. Das technische Team muss früh analysieren und handeln können, ohne auf jede Managemententscheidung zu warten. Umgekehrt braucht die Geschäftsleitung ein verdichtetes, belastbares Lagebild statt ungefilterter Einzelbeobachtungen. Diese Schnittstelle sollte Ihr Incident-Response-Plan mit festen Update-Zyklen und klaren Lageformaten abbilden.

Forensik und Beweissicherung bei Cybervorfällen

Forensik ist unter NIS2 kein Luxus für Großunternehmen, sondern ein Kernelement belastbarer Vorfallbewältigung. Ohne saubere Beweissicherung können Sie Ursache, Umfang und Eintrittszeitpunkt eines Vorfalls oft nicht mehr sicher rekonstruieren. Das erschwert nicht nur den Abschlussbericht, sondern schwächt auch Wiederherstellung, Versicherungsdeckung und mögliche Rechtsdurchsetzung.

Die wichtigste Regel lautet: Eindämmung und Beweissicherung müssen parallel gedacht werden. Es ist nachvollziehbar, ein kompromittiertes System möglichst schnell vom Netz zu nehmen. Wenn dabei aber volatile Daten, Speicherinhalte, laufende Prozesse oder zentrale Logdateien verloren gehen, nimmt sich die Organisation selbst wichtige Erkenntnisse. Ihr Plan sollte daher vorab definieren, welche Systeme zuerst isoliert, welche Artefakte zuerst gesichert und welche externen Spezialisten wann eingebunden werden.

Zur Mindestpraxis der Beweissicherung gehören in der Regel:

1. Zeitnahe Sicherung relevanter Logs aus SIEM, EDR, Firewalls, Servern und Cloud-Diensten.
2. Dokumentation aller Maßnahmen mit UTC-Zeitstempel und verantwortlicher Person.
3. Schutz vor Überschreiben oder automatischer Löschung rotierender Logquellen.
4. Gesicherte Ablage von Artefakten, Hash-Werten und Analyseergebnissen.
5. Chain-of-Custody-Dokumentation für besonders relevante Beweise.

Gerade bei Ransomware, Insider-Fällen oder Lieferkettenvorfällen ist die Reihenfolge entscheidend. Wer etwa betroffene Endpunkte neu installiert, bevor Artefakte gesichert sind, verliert oft die Chance, den initialen Angriffsvektor zu bestimmen. Das wirkt sich direkt auf die Qualität des 1-Monats-Berichts aus, weil dort bestätigte Root Cause, Zeitachse und Lessons Learned erwartet werden.

Die folgende Mapping-Tabelle hilft, NIS2 Maßnahme 2 mit etablierten ISO-27001-Kontrollen zu verbinden:

Das ISO-Mapping ersetzt die Rechtsgrundlage nicht, hilft aber bei der Implementierung. Viele Unternehmen verfügen bereits über ISO-nahe Policies, Tickets, Review-Prozesse oder Continuity-Dokumente. Diese Strukturen können Sie nutzen, um NIS2 Incident Handling schneller prüfungsfest auszubauen, statt ein komplett neues System zu erfinden.

Übungen und Simulationen — Vorbereitung auf den Ernstfall

Ein ungeübter Incident-Response-Plan ist nur ein theoretisches Dokument. NIS2 verlangt zwar keinen starren Übungsrhythmus mit genauem Kalenderdatum, aber ohne regelmäßige Tests werden Fristen, Eskalationen und Schnittstellen in der Praxis selten funktionieren. Übungen sind deshalb der belastbarste Nachweis dafür, dass Ihr Vorfallmanagement mehr ist als Papier-Compliance.

Für die meisten Organisationen ist ein gestuftes Übungsmodell sinnvoll:

1. Tabletop-Übungen für Management, Legal, IT und Fachbereiche.
2. Technische Restore-Tests für Backups, privilegierte Zugänge und Notbetrieb.
3. Kommunikationsübungen für Meldungen, Kundeninformation und interne Lageupdates.
4. Szenariobasierte Simulationen zu Ransomware, Datenabfluss, Lieferkettenausfall oder Cloud-Störung.

Tabletops sind besonders wertvoll, weil sie die Schwachstellen der Governance sichtbar machen. Häufig zeigt sich erst in der Simulation, dass niemand eine aktuelle Kontaktliste besitzt, dass die Freigabe für externe Kommunikation unklar ist oder dass die 72-Stunden-Meldung an widersprüchlichen Datenquellen scheitert. Genau diese Erkenntnisse sollten nicht im Protokoll versanden, sondern in eine verbindliche Maßnahmenliste mit Verantwortlichen und Fristen überführt werden.

Restore-Tests sind mindestens ebenso wichtig. Ein Backup auf dem Papier genügt nicht, wenn im Ernstfall unklar bleibt, wie schnell eine kritische Anwendung tatsächlich wieder anlaufen kann. NIS2 Incident Handling und Business Continuity greifen hier unmittelbar ineinander: Die Aufsicht interessiert am Ende nicht nur, ob Sie ein Backup besitzen, sondern ob Sie einen realistischen Wiederanlauf beherrschen.

Simulationen haben außerdem eine kulturelle Funktion. Sie schaffen ein gemeinsames Verständnis von Eskalation, Berichtspflichten und Kommunikationsdisziplin. Teams lernen, mit Unsicherheit umzugehen, vorläufige Informationen sauber zu kennzeichnen und trotzdem rechtzeitig zu handeln. Gerade für Unternehmen, die noch kein eigenes SOC betreiben, sind Übungen der beste Weg, um aus verteilten Zuständigkeiten einen belastbaren Vorfallprozess zu formen.

Häufig gestellte Fragen (FAQ)

Was fordert NIS2 zum Incident Handling?

Art. 21 Abs. 2 Buchst. b NIS2 verlangt Prozesse zur Erkennung, Analyse, Eindämmung, Bewältigung und Wiederherstellung nach Sicherheitsvorfällen. Unternehmen müssen Vorfälle strukturiert führen, fristgerecht melden und dokumentiert nachbereiten. Ein bloß technischer Ad-hoc-Prozess reicht dafür nicht aus.

Wie schnell muss ein NIS2-Vorfall gemeldet werden?

Die Frühwarnung muss grundsätzlich innerhalb von 24 Stunden erfolgen, die weitergehende Meldung innerhalb von 72 Stunden und der Abschlussbericht grundsätzlich innerhalb eines Monats. Entscheidend ist, dass die Uhr mit der Kenntnis des erheblichen Vorfalls startet. Unternehmen dürfen also nicht auf vollständige Gewissheit oder den Abschluss der Forensik warten.

Was muss in der NIS2-Erstmeldung stehen?

Die Erstmeldung sollte den erheblichen Vorfall als solchen erkennbar machen, einen möglichen böswilligen Hintergrund benennen, grenzüberschreitende Auswirkungen einschätzen und die erste operative Wirkung beschreiben. Sie ist eine Lagewarnung mit Mindestinformationen, keine ausformulierte Root-Cause-Analyse.

Welche ISO-27001-Kontrollen decken NIS2 Maßnahme 2 ab?

Vor allem Annex A.16 zum Informationssicherheitsvorfallmanagement ist einschlägig. Ergänzend ist Annex A.17 zum Business Continuity Management relevant, weil Incident Handling und Wiederherstellung eng zusammenhängen. Viele Unternehmen können vorhandene ISO-nahe Strukturen deshalb gezielt für NIS2 ausbauen.

Brauche ich ein SOC für NIS2?

Nein. Ein internes Security Operations Center ist keine ausdrückliche Pflicht. Sie brauchen aber belastbare Erkennungs-, Eskalations- und Reaktionsprozesse. Diese können intern, über einen Managed Service oder in einem hybriden Modell organisiert sein, solange Reaktionsfähigkeit, Verantwortlichkeiten und Nachweise gesichert sind.

Fazit: NIS2 Incident Handling ist Führungs- und Umsetzungsdisziplin

NIS2 Incident Handling nach Art. 21(2)(b) ist keine isolierte IT-Maßnahme, sondern ein verbindlicher Organisationsprozess mit klaren Fristen, Rollen und Nachweisen. Wer Maßnahme 2 sauber umsetzt, gewinnt nicht nur Compliance-Sicherheit, sondern auch echte operative Resilienz: schnellere Entscheidungen, konsistentere Meldungen und bessere Wiederherstellung nach Cybervorfällen.

Der sinnvollste nächste Schritt ist deshalb kein weiteres Grundsatzpapier, sondern die praktische Prüfung Ihres Incident-Response-Plans gegen reale Szenarien, Meldefristen und Verantwortlichkeiten. Wenn Sie Ihre Führungskräfte und Schlüsselrollen strukturiert auf NIS2, Meldepflichten und Governance vorbereiten wollen, ist unsere NIS2-Schulung für Unternehmen der passende Einstieg.