Handlungsfähig im Ernstfall: NIS-2 Incident-Response

Es ist später Nachmittag. In der IT häufen sich die Support-Anfragen, das Monitoring meldet Auffälligkeiten und erste Fachbereiche fragen nach, warum die Systeme nicht mehr funktionieren. In vielen Organisationen wurde dies früher als "Vorfall" klassifiziert, der unter Hochdruck gelöst wurde und im Anschluss im Tagesgeschäft vernachlässigt wurde. Unter NIS-2 erhält eine solche Situation eine zweite Ebene: Aus dem technischen Problem kann sehr schnell ein meldepflichtiger Sicherheitsvorfall werden. Und plötzlich ist eine Uhr in Betrieb.

In diesem Beitrag erfahren Sie, wann ein Vorfall unter NIS-2 relevant wird, welche Fristen realistisch auf Sie zukommen und wie der Meldeweg in Deutschland vorgesehen ist. Im Mittelpunkt steht die Frage, wie Incident-Response so konzipiert wird, dass im Ernstfall nicht nur die Systemsicherheit gewährleistet, sondern auch die Aufrechterhaltung der Auskunftsfähigkeit sichergestellt werden kann.

NIS-2 ist keine reine „Policy-Übung“. Im Kern geht es darum, ob eine Organisation unter Druck handlungsfähig bleibt. Incident-Response ist der Moment der Wahrheit: Erkennung, erste Einordnung, Entscheidung, Kommunikation, Dokumentation. Wenn in diesen ersten Stunden Unklarheit herrscht, wer was bewertet, wer informiert werden muss und wer eine Meldung auslöst, verlieren Sie Zeit. Und Zeit ist unter NIS-2 ein Faktor, den Sie nicht wegdiskutieren können.

Nicht jede Störung ist automatisch meldepflichtig. Entscheidend ist, ob ein Vorfall als „erheblich“ gilt. Das BSI beschreibt das in Deutschland (über das BSIG) im Kern über die Auswirkungen: Es geht um schwerwiegende Betriebsstörungen, um finanzielle Schäden oder um erhebliche materielle bzw. immaterielle Schäden bei Dritten, jeweils auch dann, wenn diese Auswirkungen drohen können.

Das ist wichtig, weil es die Perspektive verschiebt. Nicht die technische Ursache entscheidet, sondern die Frage: Was bedeutet das für den Dienst, für die Leistungserbringung, für Dritte und für den Schaden? Genau diese Einordnung muss in Ihrem Prozess früh stattfinden, nicht erst nach drei Tagen forensischer Analyse.

Für bestimmte digitale Dienste gelten zusätzlich Konkretisierungen aus der EU-Durchführungsverordnung 2024/2690. Wenn Sie in diese Kategorien fallen, sollten Sie die Kriterien daraus in Ihre Erstbewertung integrieren, damit Sie nicht nach Bauchgefühl entscheiden.

Was viele unterschätzen: NIS-2 erwartet nicht, dass Sie innerhalb von 24 Stunden alles wissen. Es geht darum, dass Sie melden können, dass Sie den Vorfall als potenziell erheblich erkannt haben, dass Sie ihn aktiv bearbeiten und dass Sie erste Eckdaten liefern können. Danach folgt innerhalb von 72 Stunden eine belastbarere Meldung, und später eine Abschluss- oder Folgemeldung, spätestens nach einem Monat.

In der Praxis heißt das: Ihr Incident-Response braucht neben der technischen Spur immer auch eine „Berichtsspur“. Wer sammelt die Fakten, wer hält sie konsistent, wer entscheidet über den Meldepunkt, und wer darf die Meldung freigeben? Wenn das nicht geklärt ist, entsteht im Ernstfall genau das, was Sie vermeiden wollen: hektische Abstimmungen, widersprüchliche Informationen und unnötige Verzögerungen.

Für regulierte Einrichtungen ist das BSI die zentrale Anlaufstelle. Das BSI sieht dafür ein Portal vor, das ab dem 6. Januar 2026 genutzt werden muss. 

Diese Details sind nicht nur „nice to know“. Sie entscheiden im Ernstfall darüber, ob jemand im Team weiß, wohin gemeldet wird und welche Kontaktstrecke funktioniert, wenn es schnell gehen muss. Genau deshalb gehört der Meldeweg nicht nur in eine Richtlinie, sondern in das Playbook und in die Übungen.

Die gute Nachricht: Wenn Sie bereits Incident-Management betreiben, müssen Sie das Rad nicht neu erfinden. Meist scheitert NIS-2-Tauglichkeit nicht an der Technik, sondern an Schnittstellen und Verantwortlichkeiten.

Ein pragmatischer Ansatz ist, Ihren bestehenden Prozess an drei Stellen zu schärfen:

Erstens in der Vorbereitung: Rollen, Erreichbarkeit, Stellvertretung, Kommunikationswege. Nicht auf dem Papier, sondern so, dass es auch am Freitag um 17:30 Uhr funktioniert.

Zweitens in der Erstbewertung: Sie brauchen eine kurze, belastbare Routine, die aus den ersten Informationen eine nachvollziehbare Einschätzung macht. Ist der Dienst betroffen? Wie groß ist die Auswirkung? Gibt es Anzeichen für einen Angriff? Könnte das „erheblich“ sein?

Drittens in der Dokumentation während der Bearbeitung: Nicht als Bürokratie, sondern als Chronik. Was ist wann passiert, welche Entscheidungen wurden getroffen, welche Maßnahmen wurden umgesetzt, welche Wirkung hatten sie? Diese Chronik macht es später deutlich leichter, eine 72-Stunden-Meldung sauber zu erstellen und im Nachgang nachvollziehbar zu bleiben.

Ein Punkt, der oft falsch verstanden wird: Das BSI weist darauf hin, dass es keine zusätzliche Dokumentationspflicht „für den Meldefall“ gibt, die über die eigentliche Meldung hinausgeht. Gleichzeitig ist es naheliegend, Meldungen und Vorfälle intern zu dokumentieren und auszuwerten, einfach weil Sie daraus bessere Abläufe, bessere Schutzmaßnahmen und bessere Entscheidungen ableiten können.

Kurz gesagt: Sie müssen kein Dokumentationsmonster bauen. Aber Sie sollten so dokumentieren, dass Sie auskunftsfähig sind und wiederholbare Verbesserung möglich wird.

Incident-Response ist unter NIS-2 kein Spezialthema für die IT. Es ist ein Handlungsfähigkeits-Thema für die gesamte Organisation. Wer den Meldeweg kennt, die Bewertung früh sauber trifft und die Kommunikation im Prozess mitdenkt, gewinnt im Ernstfall Zeit, Ruhe und Kontrolle zurück. Genau das macht den Unterschied zwischen „wir haben es irgendwie gelöst“ und „wir hatten die Lage im Griff“.