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.
In aller Kürze:
- Interne Meldewege, ein Vorfall-Team und konkrete Reaktionspläne bilden die Basis eines NIS2-konformen Incident-Response-Frameworks.
- Auf die Meldung folgt die eigentliche Arbeit: Schaden begrenzen, Spuren sichern, Systeme wiederherstellen.
- Ein Incident-Response-Framework nach ISO 27001 ist eine gute Grundlage, reicht aber nicht aus, um die NIS2-Vorgaben zu erfüllen.
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?
Ein 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.
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.
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.
Wie 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 über das zentrale Melde- und Informationsportal 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 muss gesichert werden?
- 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
Was sind 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.
Der Abschlussbericht ist deshalb keine reine 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?
Incident-Response unterscheidet sich unter NIS2 und ISO 27001 vor allem an einem Punkt: ISO 27001 kennt keine Behörde, der gegenüber man meldepflichtig ist. NIS2 schon. 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.
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.
Wie unterstützt activeMind Unternehmen beim Aufbau eines NIS2-konformen Incident-Response-Frameworks?
Um ein NIS2-konformes Incident-Response-Framework zu etablieren, konzentrieren wir uns auf drei Handlungsfelder, die direkt aufeinander aufbauen:
- Mit einer benannten Anlaufstelle und einem niedrigschwelligen Meldeprozess richten wir zunächst interne Meldewege ein und sensibilisieren Ihre Beschäftigten regelmäßig dafür – schon bevor ein Vorfall eintritt.
- Mit dem Aufbau eines handlungsfähigen Vorfall-Teams klären wir eindeutige Zuständigkeiten – von der Einschätzung der Erheblichkeit bis zur Einbindung von Geschäftsführung und Datenschutzbeauftragtem.
- Bei der Entwicklung konkreter Reaktionspläne für die wahrscheinlichsten Szenarien – Ransomware, Datenabfluss, Systemausfälle, Angriffe über die Lieferkette – legen wir fest, ab wann sie ausgelöst werden und wie die Eskalation verläuft.
Ihre Vorteile
- Unsere Erfahrung aus zahlreichen Übungen mit Kunden zeigt uns genau, wo es in der Praxis hakt: Zuständigkeiten und Prozesse sind zwischen IT-Leitung, Datenschutzbeauftragtem und Geschäftsführung oft nicht eindeutig geklärt. Solche Lücken decken wir gezielt vorab auf.
- Sie erhalten ein Framework, das im Ernstfall tatsächlich trägt und nicht nur auf dem Papier existiert. Im Ergebnis reduzieren Sie nicht nur das Risiko von Bußgeldern und persönlicher Haftung, sondern verkürzen auch Ihre Reaktionszeit, wenn es wirklich darauf ankommt.
Ein Incident-Response-Framework, das nur auf dem Papier existiert, hilft im Ernstfall nicht. Wir sorgen dafür, dass Meldewege, Teams und Reaktionspläne bei Ihnen tatsächlich funktionieren – bevor der nächste Vorfall eintritt.
Kontaktieren Sie uns jetzt für ein kostenfreies Erstgespräch!
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.
