Ein Incident Response Plan ist ein vorab dokumentiertes Regelwerk, das festlegt, wie eine Organisation Sicherheitsvorfälle erkennt, bewertet, eindämmt, behebt und nachbereitet. Der Incident Response Plan definiert Rollen und Entscheidungsbefugnisse, Klassifizierungs- und Eskalationsstufen, Meldewege, Kommunikationskanäle sowie Playbooks für typische Angriffsszenarien. Maßgebliche Referenzen sind NIST SP 800-61, die Normenreihe ISO/IEC 27035 und der IT-Grundschutz-Baustein DER.2.1 des BSI. Die Kurzform IRP ist ebenfalls verbreitet.

Was ist ein Incident Response Plan?

Ein Incident Response Plan ist die verbindliche Handlungsgrundlage für den Fall, dass die Informationssicherheit einer Organisation tatsächlich verletzt wird. Er beschreibt nicht, wie Angriffe verhindert werden – das leisten präventive Maßnahmen wie Systemhärtung, Patch-Management und Zugriffskontrolle –, sondern wie die Organisation handelt, sobald ein Angriff erfolgreich war oder ein belastbarer Verdacht besteht. Der Incident Response Plan verschiebt Entscheidungen aus dem Ereignis in die Vorbereitung: Wer alarmiert wird, wer entscheiden darf, welche Schritte in welcher Reihenfolge folgen und welche Fristen gelten, steht vorher fest.

Grundlage jedes Incident Response Plans ist eine klare Begriffsabgrenzung. Ein Event ist jedes beobachtbare Ereignis in einem System, etwa ein fehlgeschlagener Anmeldeversuch. Ein Sicherheitsvorfall (Incident) verletzt die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen tatsächlich oder wahrscheinlich. Eine Krise liegt vor, wenn der Vorfall die Organisation als Ganzes betrifft und die Linienorganisation zur Bewältigung nicht ausreicht.

Diese Abgrenzung bestimmt, welche Rollen anlaufen und welche Meldepflichten greifen. Abzugrenzen ist außerdem das Incident Management nach ITIL: Dort ist jede Störung eines IT-Services ein Incident, auch ein defekter Drucker. Da beide Prozesse häufig über denselben Service Desk anlaufen, braucht der Incident Response Plan ein klares Kriterium dafür, ab wann ein Ticket den Sicherheitsprozess auslöst.

Dokumentarisch besteht Incident Response meist aus drei Ebenen: einer übergeordneten Richtlinie mit Zielen, Geltungsbereich und Verantwortung der Leitung, dem Incident Response Plan mit Prozess, Rollen und Eskalation sowie den Playbooks für den technischen Ablauf einzelner Szenarien. Diese Trennung hält den Plan stabil, während sich die technischen Details fortlaufend ändern.

Warum ist ein Incident Response Plan wichtig?

Ein Incident Response Plan ist wichtig, weil die verfügbare Reaktionszeit bei Sicherheitsvorfällen regelmäßig kürzer ist als die Zeit, die eine unvorbereitete Organisation für Abstimmung und Zuständigkeitsklärung benötigt.

Bei Ransomware-Angriffen liegen zwischen dem ersten Zugriff und der Verschlüsselung produktiver Systeme häufig nur Stunden. Wer in dieser Phase erst klärt, wer eine Netztrennung anordnen darf, verliert genau die Zeit, in der eine Eindämmung noch wirksam wäre.

Hinzu kommt, dass die ersten Maßnahmen über die Aufklärbarkeit entscheiden. Gut gemeinte Reflexe – Systeme neu starten, betroffene Server neu installieren, sofort aus dem Backup zurücksichern – zerstören flüchtige Spuren und damit die Grundlage der IT-Forensik. Dann bleibt offen, welcher Zugangsweg genutzt wurde, ob Daten abgeflossen sind und ob der Angreifer noch im Netz ist. Eine Wiederherstellung ohne Kenntnis der Ursache führt erfahrungsgemäß häufig zum zweiten Vorfall über denselben Weg.

Regulatorisch ist ein Incident Response Plan für viele Organisationen inzwischen Pflicht. Die NIS-2-Richtlinie verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen und knüpft daran kurze Meldefristen. Die DSGVO fordert bei Verletzungen des Schutzes personenbezogener Daten eine Meldung innerhalb von 72 Stunden.

Diese Fristen laufen parallel zur technischen Bewältigung und sind ohne einen vorbereiteten Prozess kaum einzuhalten. Nach einem Vorfall prüfen zudem Versicherer, Aufsichtsbehörden und Wirtschaftsprüfer, ob die Organisation vorbereitet war – der dokumentierte und geübte Plan ist dann der Nachweis der Erfüllung der Sorgfaltspflichten.

Was gehört in einen Incident Response Plan?

Ein Incident Response Plan enthält mindestens Geltungsbereich, Klassifizierung, Rollen mit Entscheidungsbefugnis, Melde- und Eskalationswege, den Reaktionsprozess, einen Kommunikationsplan, Playbooks, Kontaktverzeichnisse, Dokumentationsvorgaben und Regeln zur Pflege des Dokuments. Im Einzelnen:

Geltungsbereich und Ziele: abgedeckte Einheiten, Standorte, Systeme und Dienstleister sowie die Rangfolge der Schutzziele
Klassifizierung und Schweregrade: Kriterien für Kritikalitätsstufen, etwa SEV 1 bis SEV 3, inklusive der Frage, wann ein Vorfall zur Krise erklärt wird
Rollen und Entscheidungsbefugnisse: benannte Funktionen mit Vertretung und ausdrückliche Befugnis für einschneidende Maßnahmen wie Netztrennung oder Produktionsstopp
Alarmierung und Erreichbarkeit: Meldewege für Mitarbeitende, Dienstleister und externe Hinweisgeber, rund um die Uhr erreichbar
Reaktionsprozess: die Phasen von der Erkennung bis zur Nachbereitung mit definierten Entscheidungspunkten
Kommunikationsplan: freigegebene Kanäle, Sprachregelungen und Zuständigkeit für Presse-, Kunden- und Belegschaftskommunikation
Playbooks: Handlungsanweisungen für Ransomware, Phishing und Kontokompromittierung, Datenabfluss, DDoS, Insider-Handlungen und Vorfälle bei Dienstleistern
Melde- und Berichtspflichten: Adressaten, Fristen und Verantwortliche für Aufsichts- und Datenschutzbehörden, Versicherer und Vertragspartner
Beweissicherung: Vorgaben zu Logging, Datensicherung, Chain of Custody und forensischen Werkzeugen
Ressourcen und Kontakte: Notfallkontakte, Retainer-Verträge für Forensik und Rechtsberatung, Ansprechpartner bei Behörden
Pflege und Nachweis: Übungsplan, Aktualisierungsanlässe, Versionierung und Freigabe durch die Leitung

Entscheidend ist die Nutzbarkeit im Ereignisfall. Ein Incident Response Plan, der als 80-seitiges Dokument nur im Intranet liegt, ist im Ernstfall doppelt unbrauchbar – zu lang zum Lesen und möglicherweise nicht erreichbar, weil das Intranet Teil des Vorfalls ist. Bewährt hat sich eine kurze, entscheidungsorientierte Fassung für die ersten Stunden, die auch offline vorliegt, ergänzt um die ausführlichen technischen Playbooks.

Welche Phasen hat ein Incident Response Plan?

Ein Incident Response Plan folgt üblicherweise den vier Phasen von NIST SP 800-61: Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung und Wiederherstellung sowie Nachbereitung. Verbreitet ist außerdem das sechsstufige Modell des SANS Institute, das dieselbe Logik feiner unterteilt.

Phase nach NIST SP 800-61	Entsprechung im SANS-Modell	Kernfrage
Preparation (Vorbereitung)	Preparation	Sind Rollen, Werkzeuge, Verträge und Übungen vorhanden?
Detection & Analysis (Erkennung und Analyse)	Identification	Liegt ein Sicherheitsvorfall vor, und welche Systeme sind betroffen?
Containment, Eradication & Recovery	Containment · Eradication · Recovery	Wie wird die Ausbreitung gestoppt, die Ursache entfernt und der Betrieb wiederhergestellt?
Post-Incident Activity (Nachbereitung)	Lessons Learned	Was ist die Ursache, und welche Maßnahmen folgen daraus?

Vorbereitung
Hier entstehen Plan und Playbooks, die Rollenbesetzung, die Detektionsfähigkeit über SIEM- und EDR-Systeme, eine Protokollierung mit ausreichender Aufbewahrungsdauer und die Verträge mit externen Dienstleistern. Wer erst im Vorfall einen Forensik-Dienstleister sucht, verhandelt Konditionen unter maximalem Zeitdruck.
Erkennung und Analyse
Aus Meldungen, Alarmen und Beobachtungen wird ein bewerteter Sicherheitsvorfall. Der Plan legt fest, wer die Erstbewertung vornimmt, nach welchen Kriterien klassifiziert wird und wann eskaliert wird – einschließlich des Zeitpunkts, ab dem die Organisation als „in Kenntnis“ gilt, denn daran hängen die gesetzlichen Meldefristen.
Eindämmung
Ziel ist, die Ausbreitung zu stoppen, ohne Beweise zu vernichten und ohne den Angreifer früh zu alarmieren: Netzsegmentierung, Isolation einzelner Systeme, Sperrung kompromittierter Konten, Entzug von Zugriffsrechten. Die Abwägung zwischen sofortiger Abschaltung und beobachtender Eindämmung ist eine Leitungsentscheidung.
Beseitigung
Entfernt werden Schadsoftware, Persistenzmechanismen, angelegte Konten und ausgenutzte Schwachstellen. Bei weitreichenden Kompromittierungen – insbesondere im Active Directory – reicht die Bereinigung einzelner Systeme nicht aus; erforderlich ist ein koordinierter Wiederaufbau.
Wiederherstellung
Systeme gehen kontrolliert und überwacht zurück in den Betrieb, priorisiert nach Kritikalität der Geschäftsprozesse. Diese Priorisierung liefert die Business Impact Analyse aus dem Business Continuity Management – eine der wichtigsten Schnittstellen zwischen beiden Disziplinen.
Nachbereitung
Innerhalb weniger Wochen folgen Post-Incident-Review, Ursachenanalyse und ein verbindlicher Maßnahmenplan mit Verantwortlichen und Fristen. Diese Phase wird am häufigsten übersprungen und ist die einzige, die den nächsten Vorfall weniger wahrscheinlich macht.

Wie unterscheidet sich ein Incident Response Plan von Disaster Recovery und Business Continuity Management?

Ein Incident Response Plan regelt die Bewältigung eines Sicherheitsvorfalls, während Disaster Recovery die technische Wiederherstellung und Business Continuity Management die Aufrechterhaltung der Geschäftsprozesse adressieren. Die Dokumente ergänzen sich und sollten aufeinander verweisen, ersetzen sich aber nicht.

Plan	Fokus	Verhältnis zum Incident Response Plan
Incident Response Plan	Erkennung, Eindämmung, Beseitigung und Nachbereitung von Sicherheitsvorfällen	–
Disaster Recovery Plan (DRP)	Technische Wiederherstellung von Systemen und Daten nach Ausfall	Wird in der Wiederherstellungsphase des Incident Response Plans angestoßen
Business Continuity Plan (BCP)	Notbetrieb der Geschäftsprozesse trotz Ausfall	Liefert die Priorisierung des Wiederanlaufs; läuft parallel zum Incident Response Plan
Krisenmanagementplan	Führung, Krisenstab, externe Kommunikation	Übernimmt, wenn ein Vorfall zur Krise eskaliert
Incident Management nach ITIL	Wiederherstellung gestörter IT-Services	Anderer Vorfallbegriff; braucht ein Übergabekriterium zum Sicherheitsprozess

Wer ausschließlich einen Disaster-Recovery-Plan besitzt, kann Systeme wiederherstellen – möglicherweise samt der Hintertür des Angreifers. Wer ausschließlich einen Incident Response Plan besitzt, kann den Angriff bewältigen, hat aber keine Antwort darauf, wie die Fachbereiche in den Tagen ohne IT arbeiten. Die Verzahnung erfolgt über gemeinsame Auslöser, ein gemeinsames Lagebild und identische Alarmierungswege.

Welche Normen und Standards gelten für Incident Response Pläne?

Für Incident-Response-Pläne sind vier Regelwerke maßgeblich. NIST SP 800-61 ist der international am häufigsten zitierte Leitfaden; die Revision 2 prägte die verbreitete Vier-Phasen-Logik, mit der Revision 3 hat das NIST die Empfehlungen stärker an das Cybersecurity Framework 2.0 angebunden.

ISO/IEC 27035 behandelt das Management von Informationssicherheitsvorfällen in mehreren Teilen: Teil 1 beschreibt Grundlagen und Prozess, Teil 2 die Planung und Vorbereitung der Reaktion, Teil 3 die operativen Abläufe. Ein weiterer Teil widmet sich der Koordination zwischen den beteiligten Organisationen.

ISO/IEC 27001:2022 verlangt in Anhang A die Steuerung von Sicherheitsvorfällen über fünf Maßnahmen: Planung und Vorbereitung (A 5.24), Bewertung und Entscheidung über Ereignisse (A 5.25), Reaktion auf Vorfälle (A 5.26), Lernen aus Vorfällen (A 5.27) und Sammlung von Beweismaterial (A 5.28) – ein Incident Response Plan ist damit faktisch Voraussetzung für eine Zertifizierung.

Im deutschsprachigen Raum ist zusätzlich das IT-Grundschutz-Kompendium des BSI relevant, insbesondere der Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“, ergänzt um DER.1 zur Detektion, DER.2.2 zur Vorsorge für die IT-Forensik und DER.2.3 zur Bereinigung weitreichender Sicherheitsvorfälle.

Branchenspezifisch kommen Vorgaben wie Anforderung 12.10 des PCI DSS oder die Prüfkataloge von TISAX hinzu. Sie unterscheiden sich in Details, verlangen aber dasselbe: einen dokumentierten, mit Verantwortlichkeiten hinterlegten und regelmäßig getesteten Plan.

Welche Melde- und Nachweispflichten muss ein Incident Response Plan abdecken?

Ein Incident Response Plan muss alle Melde- und Berichtspflichten abbilden, die parallel zur technischen Bewältigung laufen. Zentral sind zwei Regularien:

Die NIS-2-Richtlinie (EU) 2022/2555 verlangt für erhebliche Sicherheitsvorfälle ein dreistufiges Verfahren: eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats.

Die DSGVO verlangt nach Artikel 33 bei einer Verletzung des Schutzes personenbezogener Daten die Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnis, nach Artikel 34 die Benachrichtigung der Betroffenen bei hohem Risiko und nach Artikel 33 Absatz 5 die Dokumentation aller Verletzungen, auch der nicht meldepflichtigen.

Für Finanzunternehmen gilt zusätzlich die DORA-Verordnung (EU) 2022/2554 mit einem gestuften Verfahren aus Erstmeldung, Zwischenbericht und Abschlussbericht, dessen konkrete Fristen in den technischen Regulierungsstandards festgelegt sind. Betreiber kritischer Infrastrukturen unterliegen den Melde- und Nachweispflichten des BSI-Gesetzes. Vertraglich kommen häufig Informationspflichten gegenüber Kunden, Auftraggebern und Cyberversicherern hinzu, teilweise mit kürzeren Fristen als die gesetzlichen.

Zwei Punkte werden dabei regelmäßig unterschätzt:

Fristbeginn: Gesetzliche Fristen laufen ab Kenntnis beziehungsweise ab dem Bewusstwerden der Verletzung, nicht ab abgeschlossener Analyse. Der Plan muss festlegen, wer diesen Zeitpunkt feststellt und dokumentiert.
Parallelität: NIS-2-Meldung, Datenschutzmeldung, Vertragsinformation und Versicherungsmeldung betreffen denselben Vorfall, adressieren aber unterschiedliche Empfänger mit unterschiedlichen Inhalten.

Ohne koordinierte Zuständigkeit entstehen widersprüchliche Angaben, die später schwer zu korrigieren sind.

Welche Rollen und Verantwortlichkeiten definiert ein Incident Response Plan?

Ein Incident Response Plan benennt für jede Aufgabe eine Funktion, eine Vertretung und eine Entscheidungsbefugnis. Die operative Führung übernimmt ein Incident Manager/Incident Commander, der den Ablauf koordiniert, den Lagestand führt und eskaliert.

Die technische Analyse und Bearbeitung liegt beim Incident Response Team, in größeren Organisationen als CSIRT oder CERT organisiert und häufig durch ein Security Operations Center (SOC) mit Detektion und Erstbewertung unterstützt.

Ergänzend eingebunden sind der CISO für die fachliche Steuerung, der Datenschutzbeauftragte für die Bewertung nach Artikel 33 und 34 DSGVO, die Rechtsabteilung für Melde- und Haftungsfragen, die Unternehmenskommunikation, die Fachbereiche als Verantwortliche der betroffenen Prozesse sowie externe Forensik- und Rechtsdienstleister.

Die Geschäftsleitung entscheidet über einschneidende Maßnahmen und die Erklärung der Krise. Delegierbar ist die Gesamtverantwortung nicht. Werden personenbezogene Daten ausgewertet oder ist Personal von Maßnahmen betroffen, ist die Personalvertretung frühzeitig einzubeziehen.

Zwei Festlegungen sind besonders wichtig, weil ihr Fehlen unmittelbar Zeit kostet: eine 24/7-Erreichbarkeit mit belastbarer Vertretungsregelung und eine namentlich zugeordnete Befugnis, Systeme oder Netzsegmente ohne Rückfrage abzuschalten.

Welche Rolle spielt Kommunikation im Incident Response Plan?

Kommunikation ist im Incident Response Plan zugleich Steuerungsinstrument und potenzielle Angriffsfläche. Der Grund liegt in der Natur des Vorfalls: Sind Verzeichnisdienste, E-Mail-Systeme oder Kollaborationsplattformen kompromittiert, kommuniziert die Reaktionsorganisation über Infrastruktur, die der Angreifer möglicherweise mitliest. Bei gezielten Angriffen ist es ein dokumentiertes Muster, dass Angreifer die Postfächer der Reaktionsverantwortlichen beobachten und ihr Vorgehen an den geplanten Gegenmaßnahmen ausrichten.

Ein Incident Response Plan ohne vom betroffenen Netz unabhängige Kommunikationswege hat an dieser Stelle eine strukturelle Lücke.

Vier Anforderungen ergeben sich daraus:

Unabhängigkeit:
Alarmierung, Lagebild und Abstimmung müssen ohne Rückgriff auf die betroffenen Systeme funktionieren – das gilt auch für Erreichbarkeitslisten, die andernfalls genau dort liegen, wo sie im Ereignisfall nicht abrufbar sind.
Sofortverfügbarkeit:
Ein Kanal, der im Vorfall erst eingerichtet wird, steht faktisch nicht zur Verfügung.
Vertraulichkeit und Nachvollziehbarkeit: Vorfallkommunikation enthält Informationen über Schwachstellen, Betroffene und Entscheidungen und erfordert daher eine vollständige Verschlüsselung sowie eine Dokumentation, die gegenüber Aufsicht und Versicherern Bestand hat.
Getrennte Kommunikationskreise für Team, Leitung, Fachbereiche und Gesamtorganisation, damit Lagebild und Belegschaftsinformation nicht vermischt werden.

Fehlen freigegebene und geübte Kanäle, weichen Beteiligte erfahrungsgemäß auf private Consumer-Messenger aus. Es entsteht Schatten-IT genau in dem Moment, in dem Kontrolle und Beweisfähigkeit am dringendsten gebraucht werden. Organisationen erfüllen diese Anforderung in der Regel über vorab freigegebene dienstliche Kommunikationslösungen, die von der betroffenen Infrastruktur getrennt betrieben und in den Übungen des Incident Response Plans überprüft werden.

Wie sich sichere Notfallkommunikation für Reaktionsteams und Krisenstäbe abbilden lässt, zeigt Teamwire in einer Demo oder im kostenlosen Test.

Welche Kennzahlen zeigen, ob ein Incident Response Plan funktioniert?

Die Wirksamkeit eines Incident Response Plans wird über Zeitkennzahlen des Reaktionsprozesses und über Nachweiskennzahlen der Vorbereitung gemessen. Die Zeitkennzahlen zeigen, wie schnell eine Organisation von der Kompromittierung zur Kontrolle kommt.

Kennzahl	Bedeutung
MTTD	Mean Time to Detect: durchschnittliche Zeit von der Kompromittierung bis zur Erkennung
MTTA	Mean Time to Acknowledge: Zeit von der Alarmierung bis zur Übernahme durch eine zuständige Person
MTTC	Mean Time to Contain: Zeit bis zur wirksamen Eindämmung des Vorfalls
MTTR	Mean Time to Respond/Recover: Zeit bis zur abgeschlossenen Bearbeitung beziehungsweise Wiederherstellung
Dwell Time	Verweildauer des Angreifers im Netz bis zur Entdeckung
Fristentreue	Anteil der Vorfälle, in denen gesetzliche Meldefristen eingehalten wurden

Kennzahlen sind allerdings nur im Verhältnis zu Schwereklasse und Detektionsfähigkeit aussagekräftig: Eine steigende Zahl erkannter Vorfälle kann auf eine schlechtere Lage hindeuten – oder auf eine deutlich verbesserte Detektion.

Ergänzend sinnvoll sind Nachweiskennzahlen wie der Anteil der im laufenden Jahr geübten Playbooks, das Alter der Kontakt- und Eskalationslisten, der Anteil kritischer Systeme mit vollständiger Protokollierung und die Erledigungsquote der Maßnahmen aus vorangegangenen Post-Incident Reviews.

Wie wird ein IRP getestet und aktuell gehalten?

Ein Incident Response Plan wird durch gestufte Übungen getestet, die vom Dokumenten-Review bis zur technischen Simulation reichen. Der Review prüft, ob Rollen, Kontakte und Verweise stimmen. Darauf folgen Tabletop-Übungen, in denen ein Szenario am Tisch durchgesprochen wird – der wirksamste Einstieg, weil sie Zuständigkeits- und Entscheidungslücken zuverlässig offenlegen. Darüber liegen Stabsübungen mit realistischem Zeitdruck sowie technische Tests bis hin zu Angriffssimulationen und Purple-Teaming-Formaten, bei denen Detektion und Reaktion gemeinsam mit dem SOC erprobt werden.

Der Zweck von Übungen ist nicht die Bestätigung, sondern der Fund: Eine Übung, die keine Lücke zeigt, war zu einfach angelegt. Sinnvoll ist es deshalb, bewusst die unbequemen Annahmen zu testen – der Incident Manager ist nicht erreichbar, der Verzeichnisdienst ist kompromittiert, der Vorfall beginnt am Freitagabend, die Meldefrist läuft während der technischen Analyse.

Ein Incident Response Plan wird anlassbezogen aktualisiert, mindestens aber jährlich. Auslöser sind reale und beinahe eingetretene Vorfälle, Änderungen an der IT-Landschaft und den Cloud-Diensten, neue Dienstleister, Personalwechsel und regulatorische Änderungen. Am schnellsten veralten Kontaktdaten und Eskalationslisten – ihre Pflege gehört in einen festen Turnus und nicht in die Verantwortung einer einzelnen Person.

Was sind typische Fehler in Incident Response Plänen?

Der häufigste Fehler ist ein Incident Response Plan, der existiert, aber nie geübt wurde und im Vorfall deshalb nicht angewendet wird. Weitere typische Schwachstellen aus der Praxis:

Plan, Playbooks und Kontaktlisten liegen ausschließlich digital in dem System, das im Vorfall betroffen ist
keine namentlich zugeordnete Befugnis, Systeme oder Netzsegmente abzuschalten
kein definierter Zeitpunkt der Kenntnisnahme, obwohl die gesetzlichen Meldefristen daran anknüpfen
Playbooks nur für Ransomware, während Datenabfluss, Kontokompromittierung und Vorfälle bei Dienstleistern fehlen
Beweisvernichtung durch gut gemeinte Erstmaßnahmen wie Neustart, Neuinstallation oder sofortige Rücksicherung
keine Retainer-Verträge, sodass Forensik- und Rechtsdienstleister im Vorfall erst gesucht und verhandelt werden
Abstimmung über potenziell kompromittierte Kanäle statt über unabhängige Kommunikationswege
unzureichende Protokollierung oder zu kurze Aufbewahrungsfristen, sodass der Angriffsverlauf nicht rekonstruierbar ist
keine Nachbereitung: Maßnahmen aus Post-Incident Reviews werden dokumentiert, aber nicht umgesetzt

Braucht auch eine kleine Organisation einen Incident Response Plan?

Auch kleine und mittlere Organisationen brauchen einen Incident Response Plan – der Umfang skaliert, die Notwendigkeit nicht. Kleinere Einrichtungen sind von Vorfällen oft unmittelbarer betroffen, weil Fachwissen auf wenige Personen konzentriert ist und interne Reaktionskapazität fehlt. Zugleich werden sie als Zulieferer über Kundenanforderungen, Ausschreibungen und die Nachweispflichten größerer Auftraggeber ohnehin nach ihren Reaktionsfähigkeiten gefragt.

Praktisch tragfähig ist für diese Organisationen ein Plan von wenigen Seiten: eine Liste kritischer Systeme, benannte Verantwortliche mit Vertretung und Mobilnummer, drei bis fünf Erstmaßnahmen mit einem klaren „nicht tun“-Teil, die Meldefristen samt Adressaten, die Kontaktdaten eines Forensik-Dienstleisters und ein jährlicher Tabletop-Termin. Dieser Umfang ist deutlich wirksamer als ein umfassend geplantes Rahmenwerk, das nie fertig wird.

Zusammenfassung: Wichtige Punkte zu Incident Response Plan

Ein Incident Response Plan (IRP) legt vorab fest, wie eine Organisation Sicherheitsvorfälle erkennt, bewertet, eindämmt, behebt und nachbereitet.
Der Incident Response Plan regelt nicht die Prävention, sondern die Handlungsfähigkeit nach einem erfolgreichen Angriff – inklusive Rollen, Eskalation und Entscheidungsbefugnissen.
Verbreitete Gliederung des Notfallsplans sind die vier Phasen nach NIST SP 800-61 (Vorbereitung, Erkennung und Analyse, Eindämmung/Beseitigung/Wiederherstellung, Nachbereitung) sowie das sechsstufige SANS-Modell.
Maßgebliche Regelwerke sind NIST SP 800-61, ISO/IEC 27035, ISO/IEC 27001:2022 Anhang A 5.24 bis 5.28 und der BSI-IT-Grundschutz-Baustein DER.2.1.
Meldefristen laufen ab Kenntnis: NIS-2 verlangt Frühwarnung nach 24 Stunden, Meldung nach 72 Stunden und Abschlussbericht nach einem Monat; die DSGVO fordert eine Meldung binnen 72 Stunden.
Der Incident Response Plan grenzt sich von Disaster Recovery (technische Wiederherstellung) und Business Continuity Management (Notbetrieb der Prozesse) ab und muss mit beiden verzahnt sein.
Playbooks für Ransomware, Phishing, Kontokompromittierung, Datenabfluss, DDoS und Dienstleistervorfälle übersetzen den Plan in konkrete Handlungsschritte.
Wirksamkeit wird über MTTD, MTTA, MTTC, MTTR, Dwell Time und Fristentreue gemessen, ergänzt um Übungsabdeckung und Aktualität der Kontaktlisten.
Kommunikation ist kritisch und angreifbar: Reaktionsteams brauchen verschlüsselte, dokumentierte Kanäle, die unabhängig von der potenziell kompromittierten Infrastruktur funktionieren.
Der häufigste Fehler ist ein nie geübter Plan; ein kurzer, offline verfügbarer und jährlich getesteter Incident Response Plan ist wirksamer als ein umfangreiches, unbenutztes Dokument.