Die Bewältigung von erheblichen Sicherheitsvorfällen ist eines der Kernthemen von NIS2-Richtlinie und dem geänderten BSI-Gesetz (BSIG). Dafür sollten Unternehmen ein NIS2-konformes Incident-Response-Framework implementieren. Wir erklären Ihnen Umfang, Rollen, Reaktionspläne und Umsetzung – damit Ihr Incident-Response-Framework nicht nur gesetzliche Pflichten erfüllt, sondern auch in der Praxis funktioniert.
Für welche Sicherheitsvorfälle fordert NIS2 besondere Maßnahmen?
§ 30 Abs. 2 Nr. 2 BSIG verpflichtet betroffene Einrichtungen, Maßnahmen zur Bewältigung von Sicherheitsvorfällen umzusetzen. Dabei ist entscheidend: Nicht jeder Sicherheitsvorfall löst die gesetzlichen Pflichten aus, sondern nur ein erheblicher.
Als erheblicher Sicherheitsvorfall im Sinne des § 2 Nr. 11 BSIG gilt ein Ereignis,
- das erhebliche Betriebsstörungen oder finanzielle Verluste für die betreffende Einrichtung verursacht hat bzw. verursachen kann, oder
- andere Personen und Einrichtungen durch materielle oder immaterielle Schäden beeinträchtigt hat bzw. beeinträchtigen kann.
Ransomware-Angriffe, Datenpannen mit Serviceausfall oder gezielte Angriffe auf kritische Infrastruktur fallen regelmäßig unter diese NIS2-Definition eines erheblichen Sicherheitsvorfalls.
Wie bauen Unternehmen ein NIS2-konformes Incident-Response-Framework auf?
Um die Anforderungen von NIS2-Richtlinie und BSIG zur Bewältigung erheblicher Sicherheitsvorfälle erfüllen zu können, sollten Unternehmen ein funktionsfähiges Incident-Response-Framework entwickeln. Denn nur durch ein systematisches, geplantes, wiederholbares und dokumentiertes Vorgehen können Sie die Folgen von Cyberangriffen eindämmen und zukünftig besser verhindern.
Ein solches NIS2-konformes Incident-Response-Framework braucht insbesondere geregelte interne Meldewege, ein handlungsfähiges Vorfall-Team und konkrete Reaktionspläne. All diese Elemente bauen direkt aufeinander auf.
Interne Meldewege
Mitarbeitende müssen wissen, wohin sie sich wenden, wenn sie eine Auffälligkeit bemerken, und zwar auch schon bevor ein Vorfall eintritt. Eine benannte Anlaufstelle, ein niedrigschwelliger Meldeprozess und regelmäßige Sensibilisierung der Beschäftigten sind Pflicht. Denn diese Prozesse entscheiden darüber, ob ein Vorfall überhaupt rechtzeitig erkannt wird und damit, ob die recht knapp bemessenen Meldefristen des § 32 BSIG überhaupt einzuhalten sind.
Vorfall-Team
Das Vorfall-Team wird aktiviert, sobald ein erheblicher Sicherheitsvorfall mutmaßlich vorliegt. Aufgrund der interdisziplinären Zusammensetzung ist es entscheidend, dass Zuständigkeiten eindeutig geregelt sind:
- Wer schätzt ein, ob ein Vorfall als erheblich gilt?
- Wer informiert die Geschäftsführung?
- Wer erstellt die Meldung an das BSI?
- Wer zieht rechtlichen Rat hinzu?
- Wer kümmert sich um die Beweissicherung?
- Wer koordiniert die Schadensbekämpfung bzw. Wiederherstellung der Systeme und damit der Geschäftsfähigkeit?
Die Geschäftsführung trägt nach § 38 BSIG die gesetzliche Letztverantwortung. Sie muss in das Vorfall-Team aktiv eingebunden sein, nicht nur informiert werden. Auch der Datenschutzbeauftragte gehört von Beginn an dazu, denn viele Sicherheitsvorfälle sind gleichzeitig meldepflichtige Datenschutzverletzungen nach DSGVO.
Reaktionspläne
Reaktionspläne übersetzen gesetzliche Anforderungen in operative Handlungsanweisungen. Sinnvoll sind Pläne für die wahrscheinlichsten Szenarien: Ransomware-Angriffe, Datenabfluss, kritische Systemausfälle und Angriffe über die Lieferkette.
Jeder Plan sollte verbindlich regeln:
- ab wann er ausgelöst wird,
- welche Sofortmaßnahmen zu ergreifen sind,
- wer die Meldung an das BSI verantwortet und
- wie die interne Eskalation verläuft.
Unsere Erfahrung: Nur regelmäßige Übungen zeigen, ob die Pläne im Ernstfall tragen oder doch nur auf dem Papier existieren. Bei einer gemeinsamen Übung mit einem Kunden für einen Ransomware-Angriff, stockte es bereits nach wenigen Minuten. Man war sich uneins, ob der Vorfall als erheblich einzustufen ist. Die IT-Leitung dachte, das sei ihre Aufgabe. Der Datenschutzbeauftragte auch. Die Geschäftsführung hatte davon keine Vorstellung.
Leider ist so eine Situation keine Ausnahme, sondern der Regelfall. Übungen unter realen Bedingungen können oft in zwei Stunden mehr aufdecken als ein Jahr Dokumentationspflege.
Wir wird ein Incident-Response-Framework im Ernstfall ausgeführt?
Ein Incident-Response-Framework beginnt mit der Einschätzung des Vorfalls sowie – sofern die gesetzlichen Schwellen erreicht sind – der Meldung an das BSI. Entscheidend ist aber, dass es nicht bei der Meldung endet. Es folgt der eigentliche Kern, die operative Reaktion auf den Vorfall selbst: Eindämmung, Beweissicherung und Wiederherstellung. Diese drei Phasen sind gesetzlich nicht im Detail vorgeschrieben, aber ohne sie keine nachhaltige Schadensbegrenzung möglich.
Phase 1: Eindämmung – den Schaden begrenzen
Die erste Priorität nach Erkennen eines Vorfalls ist die Eindämmung. Ziel ist es, die Ausbreitung des Angriffs zu stoppen, ohne dabei Beweise zu vernichten.
Bewährte Sofortmaßnahmen:
- Betroffene Systeme vom Netzwerk trennen, aber nicht sofort ausschalten. Ein Neustart löscht flüchtige Daten im Arbeitsspeicher (RAM), die für die spätere Analyse entscheidend sein können.
- Zugangsdaten sperren oder rotieren, die möglicherweise kompromittiert wurden.
- Netzwerksegmentierung aktivieren, um eine laterale Ausbreitung des Angriffs zu verhindern.
- Backup-Systeme isolieren, damit auch diese nicht verschlüsselt oder kompromittiert werden.
Wichtig: Ruhe bewahren und strukturiert handeln. Hektische Einzelmaßnahmen ohne Abstimmung können mehr Schaden anrichten als der Angriff selbst.
Phase 2: Beweissicherung – Spuren sichern, bevor sie verschwinden
Digitale Beweise sind flüchtig. RAM-Inhalte verschwinden beim Neustart, Logs werden überschrieben, Zeitstempel können sich ändern. Die Beweissicherung beginnt deshalb in dem Moment, in dem ein Vorfall erkannt wird, nicht erst, wenn externe Spezialisten eintreffen.
Was gesichert werden muss:
- Arbeitsspeicher-Abbild (RAM-Dump) der betroffenen Systeme, bevor diese heruntergefahren werden
- System- und Anwendungslogs (zentral gespeichert, nicht nur auf dem betroffenen Gerät)
- Netzwerkverkehr-Mitschnitte, soweit vorhanden
- Forensische Kopien der betroffenen Datenträger – forensische Analysen immer nur an Kopien, nie am Original
Typische Fehler, die Unternehmen in dieser Phase machen:
- Sofortiges Neuaufsetzen befallener Systeme: verständlich aus Betriebssicht, forensisch fatal
- Direkte Arbeit am Originaldatenträger
- Fehlende oder lückenhafte Dokumentation der Sicherungsschritte (Chain of Custody)
Tipp: Legen Sie bereits vor einem möglichen Vorfall vertraglich einen externen IT-Forensik-Dienstleister fest und integrieren Sie ihn in Ihren Reaktionsplan. Das BSI stellt eine Liste qualifizierter Dienstleister bereit.
Lesen Sie dazu auch unseren ausführlichen Artikel zur Beweissicherung bei Cyberangriffen.
Phase 3: Wiederherstellung – Integrität sicherstellen, nicht nur Betrieb
Die Wiederherstellung ist mehr als das Hochfahren von Systemen. Wer zu früh in den Normalbetrieb zurückkehrt, riskiert, dass der Angreifer noch im System ist oder sich erneut Zugang verschafft.
Konkrete Schritte zur sicheren Wiederherstellung:
- Schadcode vollständig entfernen, nicht nur die sichtbaren Symptome beseitigen, sondern sicherstellen, dass keine Hintertüren (Backdoors) oder persistente Zugänge verbleiben.
- Systeme aus sauberem Backup wiederherstellen, die vor dem Angriff erstellt wurden und deren Integrität geprüft ist.
- Zugangsdaten vollständig erneuern, also alle Passwörter, Zertifikate und Schlüssel, die möglicherweise kompromittiert wurden.
- Sicherheitslücken schließen, die den Angriff ermöglicht haben, bevor Systeme wieder ans Netz gehen.
- Schrittweise Wiederinbetriebnahme mit Monitoring. Nicht alle Systeme auf einmal, sondern kontrolliert und überwacht.
Das Schutzziel der Integrität – also die Gewährleistung, dass Daten und Systeme unverändert und vertrauenswürdig sind – steht in dieser Phase im Mittelpunkt. Erst wenn die Integrität der Systeme wiederhergestellt und verifiziert ist, ist der Vorfall operativ bewältigt.
Was muss nach dem Vorfall geschehen?
Ein bewältigter Sicherheitsvorfall ist kein Schlusspunkt. § 32 BSIG verlangt einen Abschlussbericht spätestens einen Monat nach Kenntnis des Vorfalls. Darin müssen Ursache, Ausmaß, ergriffene Maßnahmen und Lessons Learned dokumentiert sein.
Das ist keine Formalität, sondern eine Chance. In der Praxis sehen wir, dass genau dieser Schritt (vor NIS2) oft ausblieb. Der Betrieb läuft wieder, die Dringlichkeit ist weg. Dabei zeigt die Nachbereitung regelmäßig, wo die IT-Sicherheit und das Incident-Response-Framework in der Realität nicht funktioniert haben. Welche Zuständigkeit unklar war, welcher Reaktionsplan nicht gegriffen hat, wo die 24-Stunden-Frist knapp oder gerissen wurde.
Wer den Abschlussbericht ernst nimmt, hat danach bessere Pläne, klarere Zuständigkeiten und ein Team, das den nächsten Vorfall schneller einschätzen kann.
Wie unterscheidet sich Incident-Response unter NIS2 und ISO 27001?
Wer bereits nach ISO 27001 zertifiziert ist, hat grundsätzlich einen echten Vorsprung auf dem Weg zur NIS2-Compliance. Die Strukturen sind da, das Risikomanagement läuft, Sicherheitsvorfälle werden behandelt. Nur kennt ISO 27001 keine Behörde, der gegenüber man meldepflichtig ist. NIS2 schon.
Das BSIG schafft direkte Rechtspflichten mit Fristen, Bußgeldern und persönlicher Haftung der Geschäftsleitung. Ein bestehender ISO-27001-Prozess zur Behandlung von Sicherheitsvorfällen ist deshalb kein fertiges Incident-Response-Framework nach NIS2. Er ist ein guter Ausgangspunkt.
Was konkret fehlt: Sicherstellung der behördlichen Meldefristen, ein definierter Kontakt zum BSI, Eskalationslogiken, die die Geschäftsführung einbinden, und Vorlagen, die im Ernstfall sofort einsatzbereit sind.
Fazit: Vorbereitung ist eine Compliance-Anforderung
Ein Incident-Response-Framework nach NIS2 ist kein Zusatzdokument. Es ist Teil der gesetzlichen Mindestanforderungen an Cybersicherheit und damit Pflicht für alle betroffenen Einrichtungen.
Entscheidend ist, was vor dem Ernstfall geklärt ist:
- Was gilt als erheblicher Sicherheitsvorfall?
- Wer meldet, wann und an wen?
- Welche Pläne greifen bei welchem Szenario?
Diese Fragen lassen sich nicht im laufenden Vorfall beantworten.
