NIS2 Incident Response Plan
Letzte Aktualisierung: 24. März 2026
Ein NIS2-konformer Incident Response Plan ist nach Art. 21(2)(b) Pflicht und definiert die Prozesse zur Erkennung, Bewältigung und Meldung von Cybersicherheitsvorfällen. Für regulierte Einrichtungen bedeutet das praktisch: Erstmeldung innerhalb 24 Stunden, weitergehender Bericht binnen 72 Stunden, Abschlussbericht nach 1 Monat und bei Organisationsmängeln Bußgeldrisiken bis 10 Millionen EUR oder 2 Prozent des weltweiten Jahresumsatzes bei wesentlichen Einrichtungen.
Die kurze Antwort lautet deshalb: Ein NIS2 Incident Response Plan ist kein langer Theorietext, sondern ein umsetzbarer Notfallplan mit klaren Rollen, Eskalationen, Kommunikationswegen, Wiederherstellungsschritten und fest hinterlegten Fristen. Wenn Sie schon bei einem Ausfall, einer Ransomware-Lage oder einem Datenabfluss diskutieren müssen, wer das BSI informiert, wer Entscheidungen freigibt und wer Systeme isoliert, ist Ihr Plan zu spät. Für die strategische Einordnung lesen Sie ergänzend Krisenmanagement bei Cyberangriffen, den Beitrag zur Geschäftsführer-Haftung bei Cyberangriffen und den Vergleich CRA vs. NIS2.
Was ein NIS2 Incident Response Plan leisten muss
Ein NIS2 Incident Response Plan muss ein Unternehmen in die Lage versetzen, erhebliche Sicherheitsvorfälle schnell zu erkennen, geordnet zu bewältigen, fristgerecht zu melden und den Betrieb kontrolliert wiederherzustellen. Maßgeblich ist Art. 21 Abs. 2 Buchst. b der Richtlinie (EU) 2022/2555, der Incident Handling ausdrücklich als Mindestmaßnahme des Cyberrisikomanagements nennt.
Der Begriff Incident Response Plan wird in der Praxis oft zu eng verstanden. Gemeint ist nicht nur die technische Reaktion des Security-Teams, sondern der gesamte Führungs- und Entscheidungsrahmen für einen erheblichen Vorfall. Dazu gehören Governance, Erkennung, Eskalation, Containment, Forensik, interne und externe Kommunikation, Meldeprozesse, Wiederanlauf und Nachbereitung. Ein isoliertes IT-Dokument reicht deshalb nicht aus.
Für NIS2-regulierte Unternehmen ist besonders wichtig, dass Incident Response mit Business Continuity und Krisenmanagement verzahnt wird. Art. 21 Abs. 2 Buchst. c NIS2 nennt ausdrücklich Business Continuity, Backup Management, Disaster Recovery und Krisenmanagement. Ihr Notfallplan muss daher nicht nur beantworten, wie ein Angriff technisch eingedämmt wird, sondern auch, wie kritische Dienste weiterlaufen, welche Ausweichprozesse greifen und wann die Geschäftsleitung den Krisenmodus ausruft.
Die Mindestfrage für die Praxis lautet: Können Sie in den ersten 60 Minuten eines Vorfalls die richtigen Personen alarmieren, betroffene Systeme absichern, die regulatorische Einordnung anstoßen und die 24-Stunden-Uhr starten? Wenn die Antwort unsicher ist, fehlt Ihnen kein Tool, sondern ein belastbarer Plan.
Welche Phasen der Notfallplan abdecken muss
Ein brauchbarer NIS2 Notfallplan deckt den gesamten Vorfallszyklus ab und nicht nur die erste technische Reaktion. Die folgende Tabelle zeigt die sechs Kernphasen, die in fast jedem belastbaren Incident-Response-Modell vorkommen und für NIS2 besonders relevant sind.
| Phase | Ziel | Typische Fragen | NIS2-relevanter Output |
|---|---|---|---|
| Vorbereitung | Rollen, Kontakte, Prozesse und Tools vorab festlegen | Wer entscheidet? Wer meldet? Welche Systeme sind kritisch? | Freigegebener Plan, Kontaktlisten, Playbooks, Übungsnachweise |
| Erkennung | Vorfall identifizieren und klassifizieren | Ist das ein erheblicher Sicherheitsvorfall? Welche Assets sind betroffen? | Erstbewertung, Ticket, Severity-Einstufung |
| Eindämmung | Schaden begrenzen und Ausbreitung stoppen | Müssen Systeme isoliert werden? Welche Geschäftsprozesse sind bedroht? | Containment-Entscheidungen, Change- und Freigabelog |
| Beseitigung | Ursache und Persistenz entfernen | Welche Konten, Schwachstellen oder Artefakte müssen beseitigt werden? | Maßnahmenprotokoll, Forensikstatus |
| Wiederherstellung | Betrieb kontrolliert zurückführen | Wann kann produktiv wieder gestartet werden? Welche Kontrollen laufen weiter? | Restore-Nachweise, Freigabe zur Wiederaufnahme |
| Nachbereitung | Ursachen, Lücken und Maßnahmen auswerten | Was war Root Cause? Wo versagte der Prozess? Was wird verbessert? | Lessons Learned, Abschlussbericht, Plan-Update |
Die Tabelle ist mehr als eine Theorieübersicht. Sie zwingt dazu, dass jede Phase einen Verantwortlichen, einen Entscheidungsanlass und ein dokumentiertes Ergebnis hat. Genau daran scheitern viele Notfallpläne in Audits: Sie beschreiben Ziele, aber keine auslösenden Ereignisse, keine Freigaben und keine Nachweise.
Ein häufiger Fehler ist die Vermischung von Phasen. Wenn Erkennung, Eindämmung und Kommunikation ungeordnet parallel laufen, entstehen widersprüchliche Aussagen gegenüber Management, Behörden, Kunden und Versicherern. Ein guter Plan trennt deshalb sauber zwischen „Was wissen wir?“, „Was tun wir sofort?“ und „Was dürfen wir extern schon sagen?“.
Diese Rollen müssen im Incident Response Plan fest zugewiesen sein
Ein NIS2 Incident Response Plan funktioniert nur, wenn Rollen vor dem Vorfall zugewiesen sind. Die wichtigste Organisationsregel lautet: Menschen müssen im Ernstfall nicht diskutieren, ob sie zuständig sind, sondern nur noch handeln.
Mindestens diese Rollen sollten schriftlich benannt sein:
- Incident Manager: Führt den Vorfall operativ, priorisiert Maßnahmen, hält Lagebild und Zeitleiste zusammen.
- Technische Einsatzleitung: Veranlasst Isolation, Analyse, Log-Sicherung, Forensik und Wiederherstellung.
- Geschäftsleitung oder Krisenleitung: Trifft Entscheidungen mit hohem Geschäftsimpact, priorisiert Dienste und genehmigt Eskalationen.
- Meldeverantwortliche Stelle: Koordiniert BSI-, CSIRT- oder sektorspezifische Meldungen innerhalb der Fristen.
- Datenschutzfunktion: Prüft parallel, ob zusätzlich Art. 33 DSGVO und gegebenenfalls Art. 34 DSGVO relevant sind.
- Rechtsfunktion: Bewertet Meldepflichten, Vertragsrisiken, Beweissicherung und externe Kommunikation.
- Kommunikation/PR: Bereitet interne Informationen, Kundenkommunikation, Medienstatements und Sprachregelungen vor.
- Fachbereichsverantwortliche: Bewerten Geschäftsfolgen, Prioritäten und Notbetriebsanforderungen für kritische Prozesse.
Die Geschäftsleitung darf operative Arbeit delegieren, aber nicht die Letztverantwortung für Governance und Überwachung. Genau darauf weist NIS2 in Art. 20 hin. Wer nur ein technisches SOC-Playbook besitzt, aber keine Entscheidungslinie für Management, Recht und Kommunikation definiert hat, hat keinen vollständigen Incident Response Plan.
Für mittelständische Unternehmen muss diese Struktur nicht groß sein. Eine Person kann mehrere Rollen tragen, solange Vertretungen festgelegt, Kontaktwege aktuell und Freigabegrenzen definiert sind. Kritisch ist nicht die Anzahl der Menschen, sondern die Eindeutigkeit der Zuständigkeiten.
Welche Meldefristen der Plan zwingend abbilden muss
Ein NIS2 Incident Response Plan ist ohne Fristenlogik unvollständig. Art. 23 NIS2 verlangt bei erheblichen Vorfällen eine gestufte Meldearchitektur, die Ihr Notfallplan als feste Eskalationsuhr verankern muss.
Die zentrale Fristenlogik lautet:
- Innerhalb von 24 Stunden: Frühwarnung nach Kenntnis eines erheblichen Vorfalls.
- Innerhalb von 72 Stunden: Incident Notification mit weiteren Informationen und erster Lagevertiefung.
- Binnen eines Monats: Abschlussbericht mit Ursachenanalyse, Auswirkungen und Maßnahmen.
Praktisch bedeutet das: Ihr Plan muss eindeutig definieren, wann die Uhr startet, wer die Erheblichkeit bewertet, wer die Meldung vorbereitet, wer freigibt und welche Informationen in welcher Reifephase bereits belastbar sind. Ohne diese Logik geraten Unternehmen in die typische Falle, den Vorfall technisch noch nicht verstanden zu haben und deshalb regulatorisch gar nicht zu melden. Genau das ist falsch gedacht. NIS2 verlangt keine Vollerklärung in 24 Stunden, sondern eine frühe, strukturierte Meldung.
Für deutsche Unternehmen ist außerdem die Parallellogik relevant. Wenn personenbezogene Daten betroffen sind, läuft neben NIS2 häufig zusätzlich die 72-Stunden-Frist aus Art. 33 DSGVO. Ein Notfallplan muss deshalb nicht nur ein NIS2-Kapitel enthalten, sondern eine Verzweigungslogik: Handelt es sich ausschließlich um einen Betriebsvorfall, um einen Datenschutzvorfall oder um beides zugleich? Unser Leitfaden zu Krisenmanagement bei Cyberangriffen vertieft genau diese Mehrfachpflichten.
Ein guter Plan enthält dazu mindestens drei konkrete Elemente: ein Fristendiagramm, einen Meldeentscheidungsbaum und vorbereitete Datenfelder für Meldungen. Dann muss im Ernstfall nicht erst juristisch bei null begonnen werden.
So sieht die Mindeststruktur eines NIS2 Notfallplans aus
Ein NIS2 Incident Response Plan braucht keine 80 Seiten. Für viele Unternehmen reicht ein Kern-Dokument von 8 bis 15 Seiten, wenn es klar strukturiert und im Ernstfall benutzbar ist. Die folgende Struktur hat sich in der Praxis bewährt.
1. Zweck, Scope und Auslösekriterien
Der Plan muss zuerst definieren, für welche Gesellschaft, Standorte, Systeme und Dienstprozesse er gilt. Ebenso wichtig ist die Auslösefrage: Wann sprechen Sie von einem Security Incident, wann von einem Major Incident und wann von einem erheblichen Vorfall im NIS2-Sinn? Ohne diese Definition eskalieren Teams entweder zu spät oder dauerhaft zu früh.
2. Kritische Assets und Dienste
Der Plan muss benennen, welche Dienste für Ihr Unternehmen prioritär sind: etwa ERP, Produktionssteuerung, Kundensysteme, Kommunikationsplattformen, IAM, Backup-Infrastruktur oder OT-Netze. Nur so lassen sich Auswirkungen, Prioritäten und Wiederanlaufreihenfolgen sauber steuern.
3. Rollen, Stellvertretungen und Kontaktlisten
Der Plan muss jede kritische Rolle mit Name, Funktion, Vertretung und Kontaktweg hinterlegen. Kontaktlisten gehören in einen schnell erreichbaren, auch offline verfügbaren Anhang. Ein Plan, dessen Kontaktdaten nur im gestörten Mailsystem liegen, ist operativ wertlos.
4. Eskalationsmatrix
Der Plan muss definieren, welche Kriterien welche Eskalationsstufe auslösen. Typische Trigger sind Produktionsstillstand, Datenabfluss, privilegierte Kontenkompromittierung, Ransomware-Hinweise, Ausfall kritischer Lieferanten oder Anzeichen für laterale Bewegung.
5. Technische Sofortmaßnahmen
Der Plan muss Standardmaßnahmen für die ersten Minuten enthalten: Log-Sicherung, Beweiserhalt, Trennung betroffener Segmente, Sperrung kompromittierter Konten, Aktivierung externer Forensik, Sicherung von Cloud-Artefakten und Prüfung unveränderter Backups. Gerade diese ersten Schritte verhindern häufig Sekundärschäden.
6. Kommunikations- und Meldeprozess
Der Plan muss klären, wer intern informiert wird, ab wann die Geschäftsleitung eingebunden wird, wer mit Behörden kommuniziert und wer Kunden, Partner oder Medien informiert. Ein Kommunikationsplan ist kein PR-Anhang, sondern Teil der Incident Response, weil falsche oder voreilige Aussagen regulatorische und haftungsrechtliche Risiken erzeugen.
7. Wiederherstellung und Notbetrieb
Der Plan muss definieren, wann Systeme zurückkehren dürfen, welche Mindestkontrollen vorher erfüllt sein müssen und welche manuellen oder alternativen Prozesse im Notbetrieb gelten. NIS2 denkt Cyberresilienz ausdrücklich mit Wiederherstellung und Business Continuity zusammen.
8. Nachbereitung und Verbesserungszyklus
Der Plan muss eine verpflichtende Nachbereitung vorsehen: Root Cause Analysis, Bewertung der Wirksamkeit, Lessons Learned, Maßnahmenplan, Anpassung des Playbooks und gegebenenfalls Schulung. Ein Plan ohne Rückkopplung altert sehr schnell.
Vorlage: Aufbau für einen belastbaren Incident Response Plan
Die folgende Vorlage ist bewusst kompakt gehalten. Sie eignet sich als Startstruktur für KMU und als Referenzgerüst für größere Organisationen.
1. Ziel und Geltungsbereich
2. Definitionen und Schweregrade
3. Kritische Geschäftsprozesse und Systeme
4. Rollen, Verantwortlichkeiten und Vertretungen
5. Alarmierung und Eskalationsstufen
6. Entscheidungsbaum: erheblicher Vorfall ja/nein
7. Erste 60 Minuten: Sofortmaßnahmen
8. 24-Stunden-Frühwarnung: Zuständigkeit und Mindestangaben
9. 72-Stunden-Folgemeldung: Datenquellen und Freigaben
10. Abschlussbericht binnen 1 Monat
11. Kommunikationsplan intern/extern
12. Datenschutz- und Vertragsprüfung
13. Wiederherstellung, Backup, Restore und Freigaben
14. Beweissicherung und Forensik
15. Nachbereitung, Lessons Learned und Planpflege
16. Anhänge: Kontaktliste, Dienstleister, Behörden, Vorlagen
Der Mehrwert dieser Vorlage liegt darin, dass technische, regulatorische und organisatorische Anforderungen in einem einzigen Ablauf verbunden werden. Ein Unternehmen muss im Ernstfall nicht zwischen Security-Handbuch, Datenschutzleitfaden, Krisenordner und Managementmemo springen.
Viele Organisationen erstellen stattdessen getrennte Dokumente ohne verbindende Logik. Dann weiß die IT nicht, wann Legal eingebunden wird, Legal kennt die Systemkritikalitäten nicht und das Management hat keinen klaren Freigabepunkt. Ein NIS2-konformer Incident Response Plan beseitigt genau diese Brüche.
Schritt-für-Schritt: So erstellen Sie den Plan in der Praxis
Ein NIS2 Incident Response Plan entsteht am schnellsten, wenn Sie nicht mit einem Blankodokument beginnen, sondern mit realen Betriebsabläufen. Die folgenden Schritte sind in mittelständischen Organisationen meist der pragmatischste Weg.
Schritt 1: Kritische Dienste und Meldeobjekte identifizieren
Starten Sie mit den Diensten, deren Ausfall regulatorisch oder geschäftlich kritisch wäre. Dazu gehören häufig Kundenportale, Produktionssysteme, Kommunikationsinfrastruktur, Kernanwendungen, IAM, Backup-Systeme und externe Managed Services. Genau diese Sicht brauchen Sie später, um Erheblichkeit, Priorität und Meldepflicht einschätzen zu können.
Schritt 2: Vorfallklassen und Schweregrade definieren
Definieren Sie klare Kategorien wie „Security Event“, „Incident“, „Major Incident“ und „erheblicher Vorfall“. Hinterlegen Sie dazu messbare Trigger: Ausfallzeiten, Anzahl betroffener Nutzer, Datenkategorien, Kritikalität des Systems, Ausmaß der Störung und Anzeichen böswilliger Aktivität. Unklare Severity-Modelle führen regelmäßig zu verspäteten Meldungen.
Schritt 3: Rollen und Freigaben verbindlich benennen
Benennen Sie Incident Manager, technische Leads, Meldeverantwortliche, Rechts- und Datenschutzfunktion sowie Geschäftsleitungsfreigaben. Legen Sie schriftlich fest, welche Entscheidungen ohne Managementfreigabe zulässig sind und welche nicht. Gerade bei Segmentabschaltungen, externen Mitteilungen oder Restore-Entscheidungen sparen Sie damit wertvolle Zeit.
Schritt 4: Die ersten 60 Minuten ausarbeiten
Beschreiben Sie minutengenau, was in der ersten Stunde geschieht: Alarmierung, erste Lageeinschätzung, Sicherung von Logs, Isolation, Ticketanlage, Aktivierung externer Partner und Fristenstart. Die Qualität dieser ersten Stunde entscheidet häufig darüber, ob Forensik, Meldung und Kommunikation später noch konsistent sind.
Schritt 5: Fristen und Meldelogik einbauen
Bauen Sie die 24h-/72h-/1-Monats-Logik direkt in das Dokument ein. Hinterlegen Sie Mindestangaben, interne Vorlaufzeiten und Freigabeschritte. Für Unternehmen mit personenbezogenen Daten gehört parallel die DSGVO-Logik hinein. Der Plan darf nicht davon abhängen, dass einzelne Experten die Fristen aus dem Kopf kennen.
Schritt 6: Kommunikationsbausteine vorbereiten
Formulieren Sie Vorlagen für interne Lageupdates, Management-Briefings, Kundeninformationen und behördliche Meldungen. Ein vorstrukturierter Kommunikationsplan reduziert Fehler, verhindert Widersprüche und beschleunigt Abstimmungen unter hohem Druck.
Schritt 7: Wiederherstellung an echte Restore-Fähigkeit koppeln
Definieren Sie Wiederanlaufkriterien nur dort, wo tatsächlich getestete Backups, klare Restore-Reihenfolgen und technische Freigaben existieren. Ein Notfallplan ist unglaubwürdig, wenn er Wiederherstellungszeiten verspricht, die nie praktisch erprobt wurden.
Schritt 8: Testen, überarbeiten und versionieren
Führen Sie Tabletop-Übungen, Restore-Tests und Krisensimulationen durch. Dokumentieren Sie dabei nicht nur technische Erkenntnisse, sondern auch Governance-Lücken, Kommunikationsprobleme und Freigabekonflikte. Erst nach einem Test ist Ihr Incident Response Plan mehr als Papier.
Die häufigsten Schwächen in NIS2-Notfallplänen
Die meisten Schwächen liegen nicht in fehlender Technik, sondern in fehlender Entscheidungsarchitektur. Gerade mittelständische Unternehmen haben oft einzelne gute Bausteine, aber keinen integrierten Plan.
Typische Lücken sind:
- Keine klare Definition der Erheblichkeit: Teams erkennen Vorfälle, wissen aber nicht, wann die NIS2-Meldelogik greift.
- Keine Management-Eskalation: Die IT arbeitet, aber die Geschäftsleitung wird zu spät eingebunden.
- Fehlende Offline-Verfügbarkeit: Kontaktlisten, Runbooks und Freigaben liegen nur in betroffenen Systemen.
- Kein Parallelblick auf DSGVO: Datenschutz- und NIS2-Pflichten werden getrennt behandelt, obwohl Vorfälle beide Regime gleichzeitig betreffen.
- Kein getesteter Restore-Prozess: Backups existieren, Wiederherstellung wurde aber nie verifiziert.
- Ungeklärte Kommunikation: Fachbereich, Vertrieb, Recht und PR kommunizieren nicht entlang einer gemeinsamen Faktenlage.
- Keine Nachbereitung: Der Vorfall endet operativ, aber der Plan wird nicht verbessert.
Diese Lücken sind nicht nur operative Probleme. Sie sind zugleich Compliance-Risiken. Wenn bei einer Prüfung oder im Schadenfall sichtbar wird, dass Fristen, Zuständigkeiten und Nachweise ungeklärt waren, wird aus einer Cyberlage schnell ein Governance-Thema. Genau an dieser Stelle wird der Bezug zur Geschäftsführer-Haftung bei Cyberangriffen praktisch relevant.
Wie der Plan mit Business Continuity, Backup und Krisenmanagement zusammenhängt
Ein NIS2 Incident Response Plan darf nie isoliert stehen. Art. 21 Abs. 2 NIS2 verbindet Incident Handling mit Business Continuity, Backup Management, Disaster Recovery und Krisenmanagement. Deshalb ist ein guter Notfallplan immer auch ein Steuerungsdokument für Prioritäten im Geschäftsbetrieb.
Das zeigt sich besonders bei Ransomware, Cloud-Ausfällen, Lieferkettenvorfällen oder OT-Störungen. In solchen Lagen reicht es nicht, den Angreifer technisch zu isolieren. Das Unternehmen muss gleichzeitig entscheiden, welche Dienste notbetriebsfähig bleiben, welche Datenquellen verlässlich sind, wann alternative Prozesse aktiviert werden und welche Kommunikationspflichten gegenüber Kunden oder Aufsicht entstehen.
Backup ist dabei kein Anhang, sondern Kern der Wiederherstellung. Ein Plan sollte deshalb mindestens festlegen, wo unveränderte Sicherungen liegen, wer Restore-Entscheidungen freigibt, in welcher Reihenfolge kritische Systeme zurückkehren und wie nach einem Restore überwacht wird. Ohne getestete Backups bleibt Incident Response oft reine Schadensverwaltung.
Auch Krisenmanagement gehört in dieselbe Logik. Der Übergang vom Security Incident zum Unternehmenskrisenfall muss definiert sein: etwa bei langem Produktionsstillstand, erheblichem Reputationsschaden, sektoraler Relevanz, Betroffenheit zahlreicher Kunden oder drohender Aufsichtsintervention. Unser Beitrag zu Krisenmanagement bei Cyberangriffen zeigt, wie diese Managementebene mit Meldepflichten verbunden wird.
Wer den Plan freigeben und überwachen sollte
Ein Incident Response Plan ist kein rein operatives Dokument der IT-Abteilung. Die Geschäftsleitung sollte den Plan formell billigen, Review-Zyklen festlegen und sich regelmäßige Übungs- und Verbesserungsberichte vorlegen lassen. Genau damit wird aus einem Security-Dokument ein Governance-Instrument.
In größeren Organisationen liegt die operative Verantwortung oft bei CISO, Security Lead oder IT-Leitung, während Legal, Datenschutz und Business Continuity eingebunden werden. In kleineren Unternehmen kann die Struktur kompakter sein, aber die Freigabe durch die Leitung bleibt sinnvoll, weil NIS2 die Managementverantwortung ausdrücklich betont.
Praxistauglich ist ein jährlicher Review-Zyklus mit anlassbezogenen Updates nach Vorfällen, Architekturänderungen, neuen Dienstleistern oder geänderten regulatorischen Anforderungen. Zusätzlich sollten Übungen mindestens einmal jährlich stattfinden; kritische Wiederherstellungsprozesse sollten häufiger getestet werden.
Wer den Plan freigibt, sollte auch definieren, welche Nachweise im Unternehmen zentral abgelegt werden: Versionen, Übungsprotokolle, Lessons Learned, Restore-Nachweise, Kontaktlisten und Freigabevermerke. Diese Dokumente sind im Prüfungs- und Haftungskontext oft wichtiger als eine perfekt formulierte Einleitung.
Checkliste: Ist Ihr NIS2 Incident Response Plan prüfungsfest?
Die folgende Kurzcheckliste eignet sich für ein internes Gap Assessment:
- Gibt es einen freigegebenen Incident Response Plan mit Versionsstand?
- Sind kritische Dienste, Systeme und Abhängigkeiten dokumentiert?
- Sind Incident Manager, Meldeverantwortliche und Vertretungen benannt?
- Ist die 24h-/72h-/1-Monats-Logik explizit im Plan abgebildet?
- Gibt es einen Entscheidungsbaum zur Erheblichkeit von Vorfällen?
- Sind DSGVO-, Vertrags- und Kundeninformationspflichten integriert?
- Sind Kontaktlisten offline verfügbar und aktuell?
- Sind Sofortmaßnahmen für Containment und Beweissicherung beschrieben?
- Gibt es getestete Backups und definierte Restore-Reihenfolgen?
- Wurden Tabletop-Übungen oder Krisensimulationen dokumentiert?
- Gibt es Vorlagen für Management-Updates und Behördenmeldungen?
- Ist eine verpflichtende Nachbereitung mit Maßnahmenverfolgung vorgesehen?
Wenn Sie mehrere dieser Fragen mit Nein beantworten, brauchen Sie keinen größeren Alarmismus, sondern einen strukturierten Aufbau Ihres Plans. Der Aufwand ist überschaubarer, als viele Unternehmen annehmen. Meist fehlen weniger technische Systeme als klare Entscheidungen, Vorlagen und Verantwortlichkeiten.
Fazit: Ein NIS2 Incident Response Plan ist Führungsinstrument, nicht Formular
Ein NIS2 Incident Response Plan ist dann wirksam, wenn er in den ersten Minuten eines Vorfalls Orientierung gibt, in den ersten 24 Stunden fristensichere Meldungen ermöglicht und in den folgenden Wochen Wiederherstellung und Nachbereitung steuert. Genau deshalb reicht weder ein reines IT-Runbook noch ein allgemeiner Krisenordner ohne regulatorische Fristen.
Für regulierte Unternehmen lautet die pragmatische Priorität: Rollen festlegen, Fristen verankern, Kommunikationswege definieren, Wiederherstellung realistisch planen und den gesamten Ablauf testen. Wer Incident Handling, Business Continuity, Backup und Governance zusammenführt, erfüllt nicht nur NIS2 näherungsweise sauberer, sondern reduziert echte Betriebs- und Haftungsrisiken.
Wenn Sie Ihre Organisation nicht nur auf einzelne Vorfälle, sondern auf Governance, Rollenverständnis und regulatorische Pflichten insgesamt vorbereiten wollen, ist unsere EU AI Act Schulung ein sinnvoller nächster Schritt. Sie schaffen damit belastbare Verantwortlichkeiten, dokumentierte Kompetenz und eine klarere Entscheidungsbasis für Management, Compliance und Fachbereiche.
FAQ zum NIS2 Incident Response Plan
Was muss ein NIS2 Incident Response Plan enthalten?
Ein NIS2 Incident Response Plan muss mindestens Rollen, Eskalationswege, Meldefristen, Entscheidungsregeln, technische Sofortmaßnahmen, Kommunikationsprozesse, Wiederherstellungsschritte und eine dokumentierte Nachbereitung enthalten. Zentral ist, dass Incident Handling nach Art. 21 Abs. 2 Buchst. b NIS2 praktisch umsetzbar ist und nicht nur formal erwähnt wird.
Wie schnell muss ein Vorfall nach NIS2 gemeldet werden?
Nach Art. 23 NIS2 ist bei erheblichen Vorfällen eine Frühwarnung innerhalb von 24 Stunden vorgesehen, eine weitergehende Meldung innerhalb von 72 Stunden und ein Abschlussbericht grundsätzlich binnen eines Monats. Ein belastbarer Plan bildet diese Uhr ab dem Zeitpunkt der Kenntnisnahme verbindlich ab.
Wer ist für den Notfallplan verantwortlich?
Verantwortlich ist nicht nur die IT-Abteilung. Die Geschäftsleitung muss Cyber-Risikomaßnahmen billigen und deren Umsetzung überwachen, während operative Aufgaben typischerweise bei Incident Manager, IT-Sicherheit, Datenschutz, Recht, Kommunikation und betroffenen Fachbereichen liegen.
Muss der Incident Response Plan regelmäßig getestet werden?
Ja. Ein ungeübter Plan ist im Ernstfall regelmäßig zu langsam. Tabletop-Übungen, Restore-Tests und Krisensimulationen zeigen, ob Rollen, Fristen, Kommunikationswege und technische Wiederherstellung tatsächlich funktionieren.
Was passiert ohne Notfallplan bei einer NIS2-Prüfung?
Fehlt ein belastbarer Notfallplan, spricht das gegen angemessenes Incident Handling und gegen wirksame Cyber-Governance. Das erhöht das Risiko aufsichtsrechtlicher Maßnahmen und kann Bußgeld- sowie Haftungsfragen deutlich verschärfen.