Incident Response Management: Grundlagen, Prozess und Notfallkommunikation unter NIS-2 & DORA

IT-Sicherheitsvorfälle passieren. Die Frage ist nicht, ob Ihr Unternehmen betroffen sein wird, sondern ob Sie im entscheidenden Moment noch handlungsfähig sind. Über ja oder nein entscheidet, wie gut Sie in Sachen Incident Response Management aufgestellt sind.

Laut IBM Cost of a Data Breach Report 2025 dauert es im globalen Durchschnitt 241 Tage, bis ein Sicherheitsvorfall vollständig identifiziert und eingedämmt ist. Ein getesteter Incident Response Plan ist dabei einer der effektivsten Hebel zur Schadensbegrenzung.

NIS-2 und DORA erhöhen zusätzlich den Druck. Beide Regelwerke verlangen, dass erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden gemeldet werden. Prozesse, Kommunikationswege und Zuständigkeiten müssen dafür schon vor dem Vorfall definiert und getestet sein.

Dieser Artikel erklärt, wie professionelles Incident Response Management aufgebaut ist, warum es mehr ist als ein Plan in der Schublade, was NIS-2 und DORA konkret fordern und wie Sie Ihre Notfallkommunikation so aufstellen, dass Sie im Ernstfall handlungsfähig bleiben.

TL;DR – das Wichtigste in Kürze

• Incident Response Management ist die organisatorische Fähigkeit, auf Sicherheitsvorfälle koordiniert, dokumentiert und fristgerecht zu reagieren.

• Der Incident Response Prozess folgt sechs Phasen: Vorbereitung, Erkennung, Eindämmung, Beseitigung, Wiederherstellung, Nachbereitung. Jede Phase hat regulatorische Implikationen.

• NIS-2 und DORA fordern beide eine Frühwarnung binnen 24 Stunden. Wer keine automatisierten Meldeketten hat, scheitert an dieser Frist.

• Notfallkommunikation funktioniert nur, wenn sie vor dem Ernstfall eingerichtet und geübt ist. Wer im Angriff auf einen unbekannten Out-of-band-Kanal umsteigen muss, verliert Zeit und verpasst im schlimmsten Fall die Frist.

• FTAPI unterstützt dabei, Meldeketten zu automatisieren und die Kommunikation im Ernstfall unabhängig von der primären Infrastruktur zu sichern.

Was Incident Response Management ist – und was nicht

Incident Response bezeichnet die technische Reaktion auf einen aktiven Sicherheitsvorfall: Erkennung, Eindämmung, Beseitigung. Incident Response Management ist der übergeordnete Rahmen, der diese Reaktion organisiert – mit definierten Rollen, Kommunikationswegen, Dokumentationspflichten und einer strukturierten Nachbereitung. Es entscheidet, ob das Unternehmen beim Vorfall handlungsfähig bleibt.

Cyberresilienz-Experte Dr. Daniel Lemmer hat es im Rahmen der CPT 2026 auf den Punkt gebracht:

Resilienz bedeutet zu erkennen, dass es keine 100-prozentige Sicherheit gibt. Es wird Sie früher oder später an einem Punkt in der Lieferkette erwischen. Die Frage ist, wie gut Sie vorbereitet sind.

NIS-2 und DORA verlangen genau deshalb nachweisbare Reaktionsfähigkeit (dazu später mehr).

Der Unterschied in der Praxis: Ein Incident Response Team, das nur technisch gut aufgestellt ist, kann einen Security Incident generell eindämmen. Aber ohne klare Zuständigkeiten, ohne funktionierende Kommunikationswege und ohne automatisierte Meldeprozesse reagiert es im Zweifel nicht schnell genug innerhalb gesetzlicher Fristen.

Reaktion auf Vorfälle: Incident Response Prozess mit 6 Phasen

Ein professioneller Incident Response Prozess folgt einer klaren Struktur. Die meisten Frameworks – BSI, NIST, ISO 27035 – gliedern ihn in sechs Phasen. Wir haben zusammengefasst, was in jeder Phase grundsätzlich zu tun ist. Generell gilt: Was nicht gut genug vorbereitet ist, kann (und wird) Ihnen unter Zeitdruck bei der Reaktion auf Vorfälle das Genick brechen.

Phase 1: Vorbereitung

Im ersten Schritt sollten Sie planen und einrichten, was Sie im Ernstfall brauchen. Dazu gehören:

• ein dokumentierter Incident Response Plan,

• definierte Rollen im Incident Respons Team und Eskalationswege,

• Kontaktlisten für interne und externe Ansprechpartner,

• getestete Kommunikationskanäle und

• szenariospezifische Playbooks.

Ein häufiger Fehler ist es dabei, die Notfallpläne und Listen einfach digital auf der primären Infrastruktur zu hinterlegen. Denn: Was passiert, wenn diese beim Angriff offline geht? Kritische Dokumente sollten immer redundant und unabhängig von der primären IT-Infrastruktur abrufbar sein.

Außerdem sollte ein Incident Response Team immer aus Personen aus verschiedenen Fachbereichen zusammengesetzt sein. Idealerweise umfasst es fünf bis zehn Mitglieder; darunter IT-, Rechts- und Kommunikationsexperten.

Und ein Plan ist nur so gut wie seine Generalprobe. Bewährt haben sich im modernen IR-Management sogenannte Tabletop Exercises (Krisensimulationen). Dabei spielt das gesamte Team, vom CISO über die Rechtsabteilung bis zur Geschäftsführung, realistische Angriffsszenarien im Konferenzraum durch. Erst unter diesem simulierten Stress zeigt sich, ob die theoretischen Kommunikationswege in der Praxis standhalten und an welchen Stellen die Playbooks nachgebessert werden müssen.

Phase 2: Erkennung und Analyse

Ein Sicherheitsvorfall beginnt selten offensichtlich. Typische Frühsignale sind anomaler Netzwerkverkehr, ungewöhnliche Logins oder verdächtige Dateiänderungen. SIEM-Systeme (Security Information and Event Management), EDR-Tools und SOC-Monitoring helfen, diese Signale zu erkennen und einzuordnen.

Die zentrale Aufgabe in dieser Phase: unterscheiden, ob es sich um einen echten Vorfall oder einen Fehlalarm handelt, und bei einem echten Vorfall den Schweregrad klassifizieren. Das ist auch regulatorisch entscheidend, denn ab dem Moment der Bestätigung eines erheblichen Vorfalls beginnt die 24-Stunden-Frist (nach NIS-2 und DORA); parallel zu allen technischen Maßnahmen, nicht danach.

Als erheblich gilt ein Vorfall dann, wenn er den Betrieb der betroffenen Einrichtung spürbar stört oder stören kann, etwa durch den Ausfall kritischer Systeme, unbefugten Datenzugriff oder eine Beeinträchtigung wesentlicher Dienste. Ein praxistauglicher Incident Response Plan legt dabei auch fest, wer die finale Autorisierungs- und Meldepflicht (z. B. CISO in direkter Abstimmung mit der Geschäftsführung) hat.

Phase 3: Eindämmung

Sobald ein Cyberangriff bestätigt ist, geht es darum, seine Ausbreitung zu stoppen: betroffene Systeme isolieren, kompromittierte Zugänge sperren, Netzwerke segmentieren. Wichtig dabei: Systeme sollten wenn möglich im laufenden Zustand belassen werden, damit forensische Spuren für die spätere Analyse erhalten bleiben.

Parallel beginnt die Krisenkommunikation. Der Krisenstab wird über einen Kanal alarmiert, der unabhängig von der kompromittierten Unternehmens-IT funktioniert. Fehlt dieser Kanal – oder kennen ihn die Beteiligten nicht – stockt die Koordination genau dann, wenn sie am dringendsten gebraucht wird.

Phase 4: Beseitigung

Nach der Eindämmung folgt die gezielte Bereinigung: Schadcode entfernen, ausgenutzte Schwachstellen schließen, kompromittierte Zugangsdaten zurücksetzen. Jede Maßnahme muss in dieser Phase dokumentiert werden. NIS-2 und DORA verlangen für die vollständige Meldung einen nachvollziehbaren Bericht über Ursache, Umfang und ergriffene Gegenmaßnahmen. Wer hier keine laufende Aufzeichnung führt, kann diesen Bericht später nicht vollständig rekonstruieren.

Phase 5: Wiederherstellung

Systeme werden sukzessive aus sauberen Backups wiederhergestellt, getestet und wieder in Betrieb genommen. Wie schnell das gelingt, hängt davon ab, ob RTO (Recovery Time Objective) und RPO (Recovery Point Objective) vorab definiert wurden – also welche Ausfallzeiten und welcher maximale Datenverlust tolerierbar sind.

Wichtig für die Fristen: Die vollständige Meldung an das BSI oder die BaFin muss 72 Stunden nach Bekanntwerden des Vorfalls eingegangen sein. Diese Frist läuft seit Phase 2. Wiederherstellung und Meldepflicht laufen also parallel, nicht nacheinander.

Phase 6: Nachbereitung

Nach dem Vorfall sollten Sie den gesamten Ablauf auswerten, unter anderem mit Blick auf:

• Was hat die Erkennung verzögert?

• Wo hat die Kommunikation nicht funktioniert?

• Welche Playbooks müssen angepasst werden?

Mit den Erkenntnissen sollten Sie direkt den Incident Response Plan und die Playbooks (mehr dazu im nächsten Abschnitt) aktualisieren. Nur so wird das Incident Response Management mit jedem Zyklus besser. Eine Krise sollte immer auch als Chance zum Lernen betrachtet werden, damit sich nach und nach echte Resilienz aufbaut, so Lemmer auf der CPT 2026.

Plus: NIS-2 und DORA fordern einen Abschlussbericht innerhalb eines Monats. Die Nachbereitung ist damit auch regulatorisch verpflichtend und nicht nur intern sinnvoll.

Incident Response Plan und Playbook: Unterschied

Ein Incident Response Plan und ein Incident Response Playbook erfüllen unterschiedliche Aufgaben und bauen aufeinander auf. Gebraucht wird beides. Der Plan schafft den organisatorischen Rahmen, das Playbook macht ihn im Ernstfall handlungsfähig.

Der Incident Response Plan

Der Incident Response Plan ist das schriftliche Fundament. Er definiert, wie das Unternehmen auf Sicherheitsvorfälle reagiert, unabhängig davon, wer gerade verfügbar ist und welche Systeme laufen.

Ein belastbarer Incident Response Plan enthält zum Beispiel:

• Geltungsbereich und Definition erheblicher Sicherheitsvorfälle z. B. nach NIS-2 und DORA

• Rollen und Verantwortlichkeiten: Wer führt den Krisenstab? Wer meldet an das BSI/an die BaFin?

• Eskalationswege: Wer wird wann informiert, über welchen Kanal?

• Kontaktlisten intern (z. B. CISO, CEO, SOC) und extern (z. B. forensische Dienstleister, BSI, BaFin, Rechtsanwälte, Versicherung)

• Out-of-band-Kommunikationswege, wenn die primäre Infrastruktur nicht verfügbar ist

• Meldepflichten und Fristen nach NIS-2 und DORA

• Verweise auf szenariospezifische Playbooks

Der Plan muss dabei regelmäßig getestet und aktualisiert werden. Ein Dokument, das seit zwei Jahren nicht mehr geöffnet wurde, ist im Ernstfall kein echter Plan.

Das Incident Response Playbook

Während der Plan den Rahmen setzt, liefert das Incident Response Playbook die konkreten Schritte für spezifische Szenarien. Ein Ransomware-Playbook sieht beispielsweise anders aus als eines für Phishing oder Datenverlust, weil sich Erkennungsmerkmale, Sofortmaßnahmen und Meldewege bei diesen IT-Sicherheitsvorfällen unterscheiden.

Ein gutes Playbook ist generell knapp, klar und unter Stress lesbar. Es beantwortet für jedes Szenario:

• Wie erkenne ich diesen Vorfallstyp?

• Was ist die Sofortmaßnahme in der ersten Stunde?

• Wer wird wie informiert?

• Welche Meldepflichten greifen?

• Wie sieht der Wiederherstellungspfad aus?

Playbooks für die häufigsten Szenarien – Ransomware, Phishing, Datenverlust, Insider-Bedrohung, Ausfall kritischer Infrastruktur – werden normalerweise im Übungsfall getestet und nach realen Vorfällen überarbeitet.

Was NIS-2 und DORA konkret fordern

Incident Response Management war lange nur Best Practice: Wer in Sachen IT-Sicherheit gut aufgestellt war, hat freiwillig strukturierte Pläne entwickelt, Playbooks getestet und Kommunikationswege definiert. NIS-2 und DORA haben das geändert, Incident Response Management ist jetzt Pflicht – mit konkreten Fristen, dokumentierten Nachweispflichten und persönlicher Haftung der Geschäftsführung. Wer bisher ohne formalen Plan gut durchgekommen ist, hat jetzt keine Wahl mehr.

Obwohl beide Regelwerke unterschiedliche Zielgruppen adressieren, sind die Anforderungen an das Incident Response Management strukturell weitgehend identisch.

Die NIS-2-Richtlinie ist über das NIS-2-Umsetzungsgesetz in Deutschland seit Dezember 2025 formal in Kraft, in Österreich wird sie über das neue Netz- und Informationssystemsicherheitsgesetz (NISG 2026) umgesetzt, das ab dem 1. Oktober 2026 gilt. Betroffen sind kritische und wichtige Einrichtungen (Details können Sie hier nachlesen).

NIS-2 fordert in Sachen Incident Response:

• Frühwarnung an das BSI (für Österreich BKA oder CERT.at) innerhalb 24 Stunden nach Bekanntwerden eines erheblichen Vorfalls

• Vollständige Meldung innerhalb 72 Stunden mit Ursache, Umfang und ersten Gegenmaßnahmen

• Abschlussbericht innerhalb eines Monats

• Dokumentierte Prozesse für Incident Response, Business Continuity und Krisenmanagement

• Persönliche Haftung der Geschäftsführung bei Verstößen gegen die Meldepflichten

DORA (Digital Operational Resilience Act) gilt seit Januar 2025 speziell für Finanzunternehmen, Versicherungen und ihre IKT-Dienstleister. Gefordert sind:

• Klassifizierung von IKT-Vorfällen nach definierten Schwellenwerten

• Frühwarnung an die zuständige Finanzaufsicht (BaFin, EBA) innerhalb von 24 Stunden bei schwerwiegenden Vorfällen

• Vollständige Meldung nach 72 Stunden, Abschlussbericht nach einem Monat

• Dokumentierte und regelmäßig getestete Incident Response Pläne

• Aktives IT-Drittanbieter-Management – die Sicherheit von Zulieferern und Dienstleistern ist Teil der eigenen DORA-Pflichten

Die Anforderungen beider Regelwerke überschneiden sich stark: identische Meldefristen, dieselben Anforderungen an Dokumentation, Zugriffskontrolle, Verschlüsselung und Business Continuity.

Wichtig für die Einordnung: Finanzunternehmen, die direkt unter DORA fallen (Banken, Versicherungen, Zahlungsdienstleister) sind von NIS-2 ausgenommen. DORA ersetzt NIS-2 für diese Unternehmen. IT-Dienstleister, die Finanzunternehmen beliefern, können dagegen unter beide Regelwerke fallen. Für sie gilt: Wer DORA-konforme Incident-Response-Prozesse aufbaut, hat damit das strukturelle Fundament für NIS-2 bereits weitgehend gelegt.

Notfallkommunikation als häufigster Engpass im Ernstfall

Stellen Sie sich nun folgendes Szenario vor: Montagmorgen. Ihr SOC meldet anomalen Netzwerkverkehr. Zwei Stunden später ist klar: Active Directory ist kompromittiert, die Unternehmens-E-Mail läuft über denselben Server und ist ausgefallen, Microsoft Teams funktioniert nicht mehr.

Die 24-Stunden-Frist für die NIS-2-Frühwarnung läuft. Aber der Krisenstab kann sich nicht koordinieren. Kontaktlisten liegen im Exchange, der offline ist. Notfallpläne sind auf einem SharePoint gespeichert, der ebenfalls nicht verfügbar ist. Externe Forensiker können nicht sicher kontaktiert werden.

Das ist kein Extremszenario. Es kann der typische Ablauf eines schwerwiegenden Angriffs sein. Damit es bei Ihnen nicht so läuft, braucht es Kommunikationswege, die redundant aufgestellt sind. Und das Incident Response Team sollte diese Wege bereits gut kennen, bevor der Ernstfall eintritt.

Konkret braucht Out-of-band-Kommunikation vier Eigenschaften, damit sie im Ernstfall funktioniert:

• Unabhängigkeit: Der Kanal darf keinen gemeinsamen Server, keine gemeinsame Domäne und keine gemeinsamen Anmeldedaten mit der primären Infrastruktur teilen. Separates Setup, separate Zugangsdaten und im Idealfall separate Geräte für den Krisenstab.

• Verschlüsselung: Im Krisenfall werden die sensibelsten Informationen des Unternehmens kommuniziert: Vorfallsdetails, forensische Befunde, Entscheidungen des Krisenstabs, Behördenkontakte. Alle Inhalte müssen Ende-zu-Ende-verschlüsselt übertragen und gespeichert werden – auch und gerade unter Zeitdruck.

• Verfügbarkeit und Stabilität: Der Kanal muss erreichbar sein, wenn interne Systeme offline sind. Das schließt alle Lösungen aus, die selbst auf der kompromittierten Infrastruktur laufen.

• Bekanntheit und Routine: Ein Kanal, der erst im Ernstfall eingeführt wird, wird nicht genutzt. Mitarbeiter, Krisenstabsmitglieder und externe Partner müssen ihn kennen, getestet haben und darin geübt sein.

Warum manuelle Meldeketten an der 24-Stunden-Frist scheitern

24 Stunden klingt im ersten Moment nach ausreichend Zeit. In der Praxis ist es das nicht. Im Ernstfall läuft in dieser Zeit nämlich gleichzeitig die forensische Analyse, Eindämmungsmaßnahmen, interne Lagebewertung, Koordination mit externen Dienstleistern. Und irgendwo dazwischen soll eine strukturierte, vollständige Frühwarnung an das BSI oder die BaFin entstehen.

Wer das manuell abbildet, scheitert schlicht an der Kapazität. Die Meldung kommt zu spät, ist unvollständig oder enthält Fehler. Unter NIS-2 und DORA kann das alles Bußgelder und persönliche Haftung der Geschäftsführung nach sich ziehen.

Automatisierte Meldeprozesse lösen dieses Problem: Definierte Ereignisse lösen automatisch Benachrichtigungen und Meldeprozesse aus. Fristen werden sichtbar getrackt. Dokumentation entsteht kontinuierlich als Audit-Trail. Die richtigen Personen werden ohne manuelle Weitergabe informiert. Das Team rund um den Incident Response Manager kann sich auf die technische Eindämmung konzentrieren, während die Meldepflichten zuverlässig laufen.

Incident Response Management mit FTAPI umsetzen

FTAPI kann ein zentraler Baustein für ein funktionierendes Incident Response Management unter NIS-2 und DORA sein. Die Plattform liefert die Werkzeuge für Meldeketten, Krisenkommunikation und Dokumentation.

• Meldeketten und Eskalationsprozesse: Über SecuFlows Advanced lassen sich interne Meldewege digital abbilden und automatisieren. Eingehende Vorfallsmeldungen lösen definierte Workflows aus, Fristen werden getrackt, Dokumentation entsteht automatisch im Hintergrund.

• Out-of-band-Kommunikation: Mit SecuMails steht ein Kommunikationskanal bereit, der unabhängig von der internen E-Mail-Infrastruktur funktioniert. Ende-zu-Ende-verschlüsselt und mit vollständiger Protokollierung.

• Krisendokumentation und Notfallpläne: Krisenteams greifen über SecuRooms geräteunabhängig auf Notfallpläne, Playbooks und forensische Dokumentation zu, auch wenn interne Shares nicht verfügbar sind. Alle Aktionen werden automatisch protokolliert.

• Datenaustausch mit externen Partnern: Logs, forensische Befunde und sensible Daten lassen sich über FTAPI verschlüsselt und zugriffskontrolliert mit Forensikern, CERTs und Behörden teilen, ohne Medienbrüche.

Fazit: Incident Response Management muss gelebt werden

Ein Incident Response Plan, der nie geübt wurde, ist nur ein Dokument. Der Incident Response Prozess muss regelmäßig trainiert, überprüft und gelebt werden, damit er im Ernstfall funktioniert und Organisationen wirklich resilient sind.

NIS-2 und DORA markieren hier einen Wendepunkt. Incident Response Management wird von freiwilliger Best Practice zur gesetzlichen Pflicht. Wer Notfallkommunikation jetzt nicht vorbereitet, Meldeketten nicht automatisiert hat und seinen Incident Response Plan nicht geübt hat, riskiert persönliche Haftung, empfindliche Bußgelder und den Vertrauensverlust bei Kunden und Partnern.

FTAPI unterstützt hier als zentraler Baustein. Die Plattform bündelt sichere Kommunikation im Notfall, automatisierte Workflows für Meldeketten und revisionssichere Dokumentation.