Orbiq LogoOrbiq
Incident-Response-Plan vs. Incident-Management-System: Was NIS2 wirklich verlangt
2026-02-22
By Anna Bley

Incident-Response-Plan vs. Incident-Management-System: Was NIS2 wirklich verlangt

Jedes ISMS hat einen Incident-Response-Plan. NIS2 verlangt ein Incident-Management-System. Der Unterschied ist nicht semantisch – er ist operativ. Was ein IMS konkret leisten muss, welche Komponenten es braucht und wie Sie den Übergang vom Plan zum System gestalten.

NIS2
Security
Compliance

Incident-Response-Plan vs. Incident-Management-System: Was NIS2 wirklich verlangt

Die meisten Unternehmen haben einen Incident-Response-Plan. Sie haben Rollen definiert, Eskalationswege beschrieben, Kontaktlisten erstellt. Das Problem: Ein Plan ist ein Dokument. Ein Dokument funktioniert nicht um 3 Uhr morgens, wenn der CISO im Urlaub ist, drei Meldepflichten gleichzeitig greifen und die Geschäftsführung eine Lageeinschätzung braucht.

NIS2 prüft nicht den Plan. NIS2 prüft die Fähigkeit. Dieser Artikel beschreibt, was ein Incident-Management-System konkret leisten muss – Komponente für Komponente – und wie Sie den Übergang vom Dokument zum operativen System gestalten.

Direkt zu:

Warum der Plan nicht reicht

Ein Incident-Response-Plan (IRP) nach ISO 27001 ist ein unverzichtbares Governance-Dokument. Er definiert, wie das Unternehmen auf Sicherheitsvorfälle reagieren soll: Wer ist zuständig? Welche Eskalationsstufen gibt es? Welche Schritte sind in welcher Reihenfolge vorgesehen?

Das Problem liegt nicht im Plan selbst. Das Problem liegt in der Annahme, dass ein guter Plan eine gute Reaktion garantiert.

NIS2 hat diese Annahme widerlegt – durch konkrete, fristgebundene Anforderungen, die nicht mit einem Dokument zu erfüllen sind:

  • 24-Stunden-Frühwarnung an das BSI, die Pflichtinhalte enthalten muss und über ein offizielles Portal eingereicht wird (Art. 23(4)(a), § 32 BSIG)
  • 72-Stunden-Meldung mit erster Bewertung von Schwere, Auswirkung und Kompromittierungsindikatoren (Art. 23(4)(b))
  • Parallele Meldepflichten unter DSGVO, Verträgen und ggf. sektorspezifischen Regelungen
  • Nachweisbare Dokumentation der gesamten Vorfallbehandlung – versioniert, nachvollziehbar, jederzeit abrufbar
  • Information an Dienstempfänger über erhebliche Vorfälle, die die Diensterbringung beeinträchtigen könnten (Art. 23(1))

All das muss gleichzeitig funktionieren – unter Zeitdruck, mit unvollständigen Informationen, über mehrere Bereiche hinweg. Das ist kein Prozess, den man in einem Dokument beschreiben und dann im Ernstfall „ausführen" kann. Das ist ein Betriebssystem.

Plan vs. System: Der operative Unterschied {#plan-vs-system}

Die Unterscheidung ist kein Wortspiel. Sie beschreibt zwei fundamental verschiedene Reifegrade:

Ein Incident-Response-Plan ist reaktiv und statisch. Er wird erstellt, freigegeben, abgelegt und im Ernstfall herangezogen. Seine Qualität hängt davon ab, ob die richtigen Leute ihn gelesen haben, ob sie sich daran erinnern und ob die Realität dem Plan entspricht.

Ein Incident-Management-System ist proaktiv und dynamisch. Es stellt sicher, dass die richtigen Abläufe passieren – unabhängig davon, ob Einzelpersonen sich an den Plan erinnern. Es koordiniert, dokumentiert und eskaliert automatisch. Es funktioniert auch dann, wenn der Ernstfall nicht dem Szenario im Plan entspricht.

EigenschaftIncident-Response-PlanIncident-Management-System
FormatDokument (PDF, Wiki, ISMS-Tool)Operatives System mit Workflows
AktivierungManuell – jemand muss den Plan finden und befolgenSystemgestützt – Workflows starten bei Trigger
KoordinationBeschrieben, aber nicht erzwungenStrukturiert und nachvollziehbar
DokumentationNachträglich rekonstruiertEchtzeit-Protokollierung
MeldepflichtenReferenziert als ProzessschrittIntegriert mit Fristen, Templates, Kanälen
NachweisbarkeitAbhängig von Disziplin der BeteiligtenSystemisch – jede Aktion wird protokolliert
PersonenabhängigkeitHochReduziert durch Rollen und Stellvertretung
TestbarkeitTabletop-Übung gegen den PlanTabletop-Übung gegen das System

Der Reifegrad-Sprung vom Plan zum System ist der Sprung, den NIS2 erzwingt. Nicht optional, nicht „nice to have" – sondern operativ notwendig, um die Meldepflichten fristgerecht und nachweisbar zu erfüllen.

Die sieben Komponenten eines NIS2-tauglichen IMS {#sieben-komponenten}

Ein Incident-Management-System muss nicht monolithisch sein. Es muss sieben Dinge leisten – und jede dieser Komponenten kann mit unterschiedlichen Tools oder Prozessen umgesetzt werden. Entscheidend ist, dass sie zusammenwirken.

1. Triage und Klassifizierung

Was es leisten muss: Innerhalb von Minuten nach Erkennung eines Vorfalls feststellen, ob es sich um einen erheblichen Vorfall im Sinne von NIS2 handelt. Die Klassifizierung bestimmt, welche Meldepflichten greifen und welche Fristen laufen.

Konkret: Vordefinierte Kriterien für die Schwellenbestimmung: Welche Vorfalltypen sind „erheblich"? Ab welcher Schwere? Welche Systeme/Dienste sind betroffen? Entscheidungsbaum oder Checkliste, die auch unter Stress anwendbar ist – nicht eine dreiseitige Policy, die erst interpretiert werden muss.

Typischer Fehler: Die Klassifizierung wird in die technische Analyse gezogen und dauert Stunden statt Minuten. Die 24-Stunden-Frist läuft aber ab Kenntniserlangung – nicht ab Abschluss der Analyse.

2. Rollenaktivierung und Eskalation

Was es leisten muss: Die richtigen Personen innerhalb von Minuten aktivieren – mit klarer Rollenzuweisung und Stellvertretungsregelung. Nicht „Security wird informiert", sondern „Person X in Rolle Y wird über Kanal Z aktiviert, bei Nichterreichbarkeit Stellvertretung A."

Konkret: Namentlich benannte Rollen für jede Phase: Incident Commander (Gesamtkoordination), Technical Lead (technische Analyse), Regulatory Lead (Meldepflichten), Communications Lead (interne/externe Kommunikation), Executive Sponsor (Geschäftsführung). Automatische Eskalation, wenn Aktivierung nicht innerhalb definierter Zeit bestätigt wird.

Typischer Fehler: Die Eskalationskette existiert auf Papier, aber niemand hat die Mobilnummern der Stellvertretung. Oder: Die Geschäftsführung wird zu spät eingebunden, weil das Security-Team „erst mehr Fakten sammeln" will.

3. Parallele Meldepflichtsteuerung

Was es leisten muss: Alle relevanten Meldepflichten identifizieren und parallel steuern – mit eigenen Fristen, Inhalten und Kanälen für jede einzelne.

Konkret: Mapping aller Meldepflichten pro Vorfalltyp: NIS2 (24h/72h/1 Monat an BSI), DSGVO (72h an Datenschutzbehörde), vertragliche Pflichten (je nach Vertrag), sektorspezifische Pflichten (je nach Branche). Für jede Pflicht: Template, Frist-Tracking, zuständige Person, Einreichungskanal.

Typischer Fehler: Die NIS2-Meldung wird vorbereitet, aber die DSGVO-Meldung vergessen – oder umgekehrt. Oder: Vertragliche Notification-Pflichten gegenüber Kunden werden erst entdeckt, nachdem die Frist bereits abgelaufen ist.

4. Strukturierte Lagebildführung

Was es leisten muss: Ein zentrales, versioniertes Lagebild, das den aktuellen Kenntnisstand über den Vorfall zusammenfasst – und für unterschiedliche Zielgruppen aufbereitet werden kann.

Konkret: Ein lebendes Dokument (kein statisches PDF), das fortlaufend aktualisiert wird: Was wissen wir? Was wissen wir nicht? Was hat sich seit der letzten Version geändert? Welche Entscheidungen stehen an? Das Lagebild muss in einer Version für die technische Analyse vorliegen, in einer Version für die Geschäftsführung und in einer Version für die regulatorische Meldung.

Typischer Fehler: Es gibt kein zentrales Lagebild. Stattdessen zirkulieren verschiedene E-Mails, Chat-Nachrichten und mündliche Updates mit widersprüchlichen Informationen. Die Geschäftsführung trifft Entscheidungen auf Basis veralteter Informationen.

5. Versionierte Echtzeit-Dokumentation

Was es leisten muss: Jede Entscheidung, jede Maßnahme, jede Kommunikation wird dokumentiert – mit Zeitstempel, Verantwortlichem und Kontext. Nicht nachträglich, sondern während der Vorfallbehandlung.

Konkret: Ein zentrales Log, das automatisch erfasst: Wer hat wann welche Entscheidung getroffen? Auf Basis welcher Informationen? Welche Maßnahmen wurden eingeleitet? Welche Kommunikation hat stattgefunden – intern und extern? Dieses Log muss auditfähig sein – es ist der Nachweis, dass das Unternehmen seinen Pflichten nachgekommen ist.

Typischer Fehler: Die Dokumentation wird „nach dem Vorfall aufgearbeitet" – aus E-Mails, Chat-Verläufen und Erinnerungen rekonstruiert. Das ist unter NIS2 nicht nachweistauglich und bei einer BSI-Prüfung ein Problem.

6. Externe Kommunikationssteuerung

Was es leisten muss: Koordinierte, abgestimmte Kommunikation nach außen – gegenüber Behörden, Kunden, Partnern und ggf. der Öffentlichkeit. Abgestimmt zwischen Legal, Kommunikation und Geschäftsführung, bevor sie rausgeht.

Konkret: Vorabgestimmte Kommunikationsvorlagen für die häufigsten Szenarien. Ein Freigabeprozess, der schnell genug ist, um die regulatorischen Fristen einzuhalten, aber gründlich genug, um rechtliche Risiken zu vermeiden. Versionierte Dokumentation aller externen Kommunikation.

Typischer Fehler: Die PR-Abteilung kommuniziert, bevor Legal freigegeben hat. Oder: Legal blockiert jede Kommunikation, bis der Vorfall vollständig analysiert ist – was die Meldefrist sprengt.

7. Nachbereitung und Evidenzsicherung

Was es leisten muss: Nach Abschluss des Vorfalls: Ursachenanalyse, Lessons Learned, Aktualisierung des IMS. Aber vor allem: Sicherung aller Nachweise für die regulatorische Dokumentation – der Abschlussbericht (1 Monat nach Erstmeldung) und die Aufbewahrung für mögliche spätere BSI-Prüfungen.

Konkret: Strukturierter Post-Incident-Review mit allen Beteiligten. Konsolidierung aller Artefakte: Lagebilder, Entscheidungslogs, Meldungen, Kommunikation, technische Analysen. Archivierung in einem Format, das nachvollziehbar und auditfähig ist. Identifikation von Verbesserungsmaßnahmen und deren Nachverfolgung.

Typischer Fehler: Die Nachbereitung wird aufgeschoben und dann vergessen. Oder: Die Artefakte liegen in verschiedenen Systemen verstreut und können bei einer späteren BSI-Anfrage nicht zusammengeführt werden.

Der Aufbau in der Praxis {#aufbau-in-der-praxis}

Schritt 1: Bestandsaufnahme (Woche 1)

Was haben Sie bereits? In den meisten Unternehmen existieren Teile eines IMS, aber sie sind nicht verbunden: Ein IRP im ISMS. Ein Ticketsystem für Security Incidents. Eine E-Mail-Verteiler für Eskalation. Vielleicht ein War Room oder ein Krisenstab-Verfahren.

Mappen Sie diese Elemente gegen die sieben Komponenten oben. Wo gibt es Abdeckung? Wo fehlt es?

Schritt 2: Lücken schließen – schnell (Woche 2–4)

Beginnen Sie mit den Komponenten, die sich sofort umsetzen lassen und den größten Effekt haben:

  • Triage-Kriterien definieren: Wann ist ein Vorfall „erheblich"? Entscheidungsbaum auf eine Seite. Abstimmen, freigeben, verteilen.
  • Rollen namentlich besetzen: Incident Commander, Regulatory Lead, Communications Lead, Executive Sponsor – mit Stellvertretung und Erreichbarkeit.
  • Meldepflicht-Mapping erstellen: Welche Pflichten greifen bei welchem Vorfalltyp? Fristen, Inhalte, Kanäle, Zuständige.
  • Templates vorbereiten: Vorlagen für 24h-Frühwarnung, 72h-Meldung, Abschlussbericht – vorab erstellt und freigegeben.

Schritt 3: Systematisieren (Monat 1–3)

Jetzt die Komponenten verbinden:

  • Lagebild-Führung einrichten: Zentraler Ort für das versionierte Lagebild – zugänglich für alle Rollen, mit Änderungshistorie.
  • Dokumentationsprozess automatisieren: Jede Entscheidung, jede Maßnahme, jede Kommunikation wird zeitgestempelt protokolliert.
  • Externe Kommunikation vorbereiten: Templates, Freigabeprozess, Kanalsteuerung für Behörden, Kunden, Partner.

Schritt 4: Testen (Monat 2–3)

Eine Tabletop-Übung gegen das System – nicht gegen den Plan. Realistisches Szenario, echte Zeitlimits, alle Rollen besetzt:

  • Kann die Triage innerhalb von 30 Minuten abgeschlossen werden?
  • Werden die richtigen Rollen innerhalb von einer Stunde aktiviert?
  • Kann die 24h-Frühwarnung fristgerecht produziert und eingereicht werden?
  • Werden parallele Meldepflichten erkannt und gesteuert?
  • Ist die Dokumentation vollständig und nachvollziehbar?

Jede Übung offenbart Lücken. Das ist der Sinn der Übung.

Schritt 5: Iterieren (laufend)

Ein IMS ist nie fertig. Es wird besser durch jede Übung, jeden echten Vorfall und jedes Feedback. Mindestens zwei Tabletop-Übungen pro Jahr – mit wechselnden Szenarien und unter Einbeziehung der Geschäftsführung.

Der IMS-Reifegrad-Check

Fünf Fragen, um den aktuellen Reifegrad Ihres Incident Managements einzuschätzen:

  1. Können Sie innerhalb von 30 Minuten nach Erkennung eines Vorfalls feststellen, ob eine NIS2-Meldepflicht besteht? Wenn nein: Triage-Komponente fehlt oder ist zu langsam.

  2. Wissen Sie jetzt – in diesem Moment – wer Ihr Incident Commander ist und wie Sie ihn um 3 Uhr morgens erreichen? Wenn nein: Rollenaktivierung ist nicht operationalisiert.

  3. Haben Sie Templates für die 24h-Frühwarnung und die 72h-Meldung, die vorab freigegeben und getestet sind? Wenn nein: Meldepflichtsteuerung ist nicht vorbereitet.

  4. Können Sie nach einem Vorfall lückenlos nachweisen, wer wann welche Entscheidung getroffen hat? Wenn nein: Echtzeit-Dokumentation fehlt.

  5. Haben Sie in den letzten sechs Monaten eine Tabletop-Übung gegen die NIS2-Meldefristen durchgeführt? Wenn nein: Das System ist ungetestet – und ein ungetestetes System ist kein System.

Quellen

  1. Richtlinie (EU) 2022/2555 (NIS2-Richtlinie) – Volltext – Artikel 21(2)(b) zu Incident Handling, Artikel 23 zu Meldepflichten.
  2. BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – § 32 BSIG zum dreistufigen Melderegime.
  3. BSI – #nis2know Infopaket: NIS-2-Meldepflicht – BSI-Informationspaket zur Meldepflicht.
  4. ENISA – Implementing Guidance on NIS2 Security Measures – Umsetzungsempfehlungen zu Incident Handling und Reporting.
  5. ISO/IEC 27001:2022 – Annex A, A.5.24-A.5.28 – ISO-Controls für Incident Management als Vergleichsbasis.

Weiterführende Inhalte