Incident-Response-Plan erstellen: Schritt-für-Schritt-Anleitung mit Vorlage

Ein Incident-Response-Plan ist ein schriftliches, von der Geschäftsleitung verabschiedetes Dokument, das festlegt, wie eine Organisation einen Cybersicherheitsvorfall erkennt, eindämmt und behebt. Deutsche Organisationen, die 2026 einen solchen Plan aufbauen, stehen vor einer Vorgabe, die die meisten internationalen Vorlagen ausblenden: Das NIS2UmsuCG setzt eine gesetzliche Frist in Gang, sobald die Organisation Kenntnis von einem erheblichen Sicherheitsvorfall erlangt. Innerhalb von 24 Stunden ist eine frühe Erstmeldung an das Bundesamt für Sicherheit in der Informationstechnik (BSI) fällig, innerhalb von 72 Stunden die Meldung des Sicherheitsvorfalls mit einer ersten Bewertung. Nur 43 % der deutschen Unternehmen schätzen sich derzeit als sehr gut auf einen Cyberangriff vorbereitet ein, nach 50 % im Vorjahr, obwohl 58 % angeben, in den vergangenen 12 Monaten einen Schaden durch einen solchen Angriff erlitten zu haben (Bitkom, Wirtschaftsschutz 2026). Dieser Artikel beschreibt, welche Bestandteile ein vollständiger Plan braucht, wie sich jede Phase der Reaktion in einen Abschnitt des Plans übersetzt und welche Rollen persönlicher rechtlicher Haftung unterliegen. Er zeigt außerdem einen deutschen Meldezeitplan, der die Pflichten aus NIS2, Datenschutz-Grundverordnung der EU (DSGVO) und BSI auf einer gemeinsamen Zeitachse bündelt, sowie eine Vorlagenstruktur, die ein Team direkt übernehmen kann.

Was ist ein Incident-Response-Plan?

Ein Incident-Response-Plan ist ein schriftliches, von der Geschäftsleitung verabschiedetes Dokument, das Rollen zuweist, Reaktionsphasen definiert und Kommunikationsregeln für das Erkennen, Eindämmen und Beheben eines Cybersicherheitsvorfalls festlegt. Der Plan ist das steuernde Dokument; Incident Response ist die zugrunde liegende Disziplin, die er beschreibt. Was ist Incident Response? behandelt diese Disziplin umfassend; dieser Artikel behandelt das Dokument, das sie in einen wiederholbaren, prüfbaren Prozess überführt.

Ein Plan unterscheidet sich von einem Playbook im Geltungsbereich. Der Plan steuert das gesamte Programm: Rollen, Phasen, Eskalationskriterien und Meldepflichten. Ein Playbook ist eine szenariospezifische Handlungsanweisung innerhalb dieses Plans und deckt genau eine Angriffsart ab, etwa Ransomware oder ein kompromittiertes Konto. Die folgenden Abschnitte dieses Leitfadens behandeln beides.

Warum braucht jede deutsche Organisation 2026 einen schriftlichen Incident-Response-Plan?

Deutsche Organisationen brauchen einen schriftlichen Incident-Response-Plan, weil die meisten Unternehmen bereits angegriffen werden und die meisten ihre eigene Vorbereitung als unzureichend einstufen. 58 % der deutschen Unternehmen haben in den vergangenen 12 Monaten einen Schaden durch einen Cyberangriff erlitten, doch nur 43 % halten sich für sehr gut vorbereitet, nach 50 % im Vorjahr (Bitkom, Wirtschaftsschutz 2026). Genau diese Lücke zwischen Betroffenheit und Vorbereitung schließt ein schriftlicher Plan: Er verlagert Entscheidungen über das Isolieren eines Hosts, die Meldung an eine Behörde oder die Information der Presse aus dem Moment der Krise in ein vorab getestetes Dokument.

Diese Lücke hat inzwischen für einen großen Teil der deutschen Wirtschaft rechtliches Gewicht. Art. 21 Abs. 2 lit. b NIS2-Richtlinie nennt die Bewältigung von Sicherheitsvorfällen als eine der Mindestmaßnahmen des Cybersicherheits-Risikomanagements, die betroffene Organisationen umsetzen müssen, neben Business Continuity, Sicherheit der Lieferkette und Multi-Faktor-Authentifizierung. Eine Organisation ohne dokumentierten Prozess zur Bewältigung von Sicherheitsvorfällen ist daher nicht einfach unvorbereitet: Sie verstößt gegen eine konkrete, ausdrücklich benannte gesetzliche Anforderung und nicht gegen eine allgemeine Best Practice.

Wie unterscheidet sich ein Incident-Response-Plan von einem IT-Notfallplan oder Business-Continuity-Plan?

Ein Incident-Response-Plan und ein IT-Notfallplan regeln unterschiedliche Probleme. Der Incident-Response-Plan behandelt gezielt Cybersicherheitsvorfälle: Angriffe auf Systeme, Datenpannen, Ransomware und ähnliche vorsätzliche oder böswillige Ereignisse. Ein IT-Notfallplan, aufgebaut auf dem Business-Continuity-Rahmenwerk des BSI, behandelt jede Störung kritischer Prozesse, etwa durch Brand, Stromausfall oder Pandemie, unabhängig von der Ursache.

	Incident-Response-Plan	IT-Notfallplan / Business-Continuity-Plan
Regelt	Gezielt Cybersicherheitsvorfälle	Jede Störung kritischer Geschäftsprozesse
Standard	BSI-Baustein DER.2.1, SANS PICERL, NIST SP 800-61	BSI-Standard 200-4, ISO 22301
Auslöser	Eine erkannte oder vermutete Kompromittierung	Jedes Ereignis, das einen kritischen Prozess unterbricht
Kernergebnis	Eingedämmter, beseitigter und gemeldeter Sicherheitsvorfall	Wiederhergestellter Geschäftsbetrieb innerhalb einer definierten Recovery Time Objective

Die Unterscheidung hat eine rechtliche Grundlage und ist nicht nur praktischer Natur. Art. 21 Abs. 2 lit. b NIS2-Richtlinie verlangt die Bewältigung von Sicherheitsvorfällen als eine Pflicht; Art. 21 Abs. 2 lit. c verlangt davon getrennt Business Continuity und Krisenmanagement, einschließlich regelmäßig getesteter Backup- und Disaster-Recovery-Verfahren. Das sind 2 eigenständige, jeweils verbindliche Pflichten derselben Richtlinie und nicht 2 Bezeichnungen für dasselbe Dokument. ISO 22301, der internationale Standard für Business Continuity, liefert den Rahmen für die Business-Continuity-Seite; dieser Artikel behandelt die Seite des Incident Response.

Welche Bestandteile enthält ein vollständiger Incident-Response-Plan?

Ein vollständiger Incident-Response-Plan enthält 8 Kernbestandteile, von denen jeder eine konkrete operative Frage während eines laufenden Sicherheitsvorfalls beantwortet.

Bestandteil	Beantwortet
Geltungsbereich und Ziele	Welche Systeme, Daten und Geschäftsbereiche der Plan abdeckt
Schweregradklassifizierung	Wie die Organisation einen Sicherheitsvorfall einstuft (kritisch, hoch, mittel, niedrig)
Rollen und Verantwortlichkeiten	Wer was tut und wer welche Entscheidung treffen darf
Kommunikationsplan	Wer was wann und über welchen Kanal erfährt
Meldezeitplan	Welche externen Fristen gelten und wer für jede davon zuständig ist
Playbooks	Schritt-für-Schritt-Anleitungen für bestimmte, wiederkehrende Szenarien
Werkzeuge	Welche Systeme den Vorfall erkennen, untersuchen und die Reaktion ausführen
Tests und Lessons Learned	Wie und wie oft der Plan geübt und aktualisiert wird

Die Schweregradklassifizierung verdient besondere Aufmerksamkeit, denn sie entscheidet, welche Sicherheitsvorfälle die NIS2-Erheblichkeitsschwelle überschreiten und die später in diesem Leitfaden behandelte 24-Stunden-Frist auslösen. Die Grundlagen für diese Entscheidung liefert eine Business Impact Analysis (BIA), wie der Beitrag Warum BIA für moderne SOCs unverzichtbar ist zeigt: Sie legt für jeden kritischen Prozess eine maximal tolerierbare Ausfallzeit (Maximum Tolerable Period of Disruption) und eine Recovery Time Objective fest. Der Incident-Response-Plan übernimmt dieselben Stufen, um zu entscheiden, wie dringlich zu reagieren ist und wer zu informieren ist.

Wie lassen sich die Phasen des Incident Response in Abschnitte des Plans übersetzen?

Jede Phase des Incident Response wird zu einem Planabschnitt, der eine Entscheidung im Voraus festlegt. Der Plan folgt dem 6-Phasen-Modell PICERL von SANS: Vorbereitung (Preparation), Identifizierung (Identification), Eindämmung (Containment), Beseitigung (Eradication), Wiederherstellung (Recovery) und Lessons Learned. Die Phasen selbst gehören zur Disziplin des Incident Response, die im oben verlinkten Grundlagenartikel erläutert wird. Der Plan hält lediglich fest, wer was bis wann und auf Grundlage welches Dokuments entscheidet.

Phase	Entscheidung, die der Plan im Voraus festlegt	Dokument, das der Plan enthalten muss
Vorbereitung	Welches Team, welche Werkzeuge und externen Partner vor einem Sicherheitsvorfall bereitstehen	Kontaktliste, Retainer-Verträge mit Forensik und Rechtsberatung, Werkzeuginventar
Identifizierung	Welche Kriterien einen Alarm zum Sicherheitsvorfall machen und welche Vorfälle nach NIS2 als erheblich gelten	Schweregradmatrix, verknüpft mit der NIS2-Erheblichkeitsschwelle
Eindämmung	Wer einen Host isolieren oder ein Konto deaktivieren darf und wann die Beweissicherung Vorrang hat	Entscheidungsmatrix für die Eindämmung, Regel zur Beweissicherung
Beseitigung	Unter welchen Bedingungen feststeht, dass der Angreifer keinen Zugriff mehr hat	Checkliste zur Beseitigung mit einer für die Freigabe verantwortlichen Person
Wiederherstellung	Welche Systeme zuerst in den Produktivbetrieb zurückkehren und wer die Rückkehr freigibt	Wiederanlaufreihenfolge, abgeleitet aus der Business Impact Analysis
Lessons Learned	Wer die Nachbereitung verantwortet und wie schnell Korrekturen in den Plan zurückfließen	Vorlage für den Bericht nach dem Sicherheitsvorfall mit fester Frist

Die Zeile zur Eindämmung enthält den schwierigsten Zielkonflikt. Das Isolieren eines kompromittierten Hosts schützt den Rest des Netzwerks, vernichtet aber auch flüchtige Beweise, die das Forensik-Team später benötigt. Ein Plan, der diese Entscheidung vor einem Sicherheitsvorfall einer benannten Rolle zuweist, nimmt den Zielkonflikt aus der Drucksituation heraus.

Das NIST hat dasselbe Themenfeld im April 2025 neu geordnet. Die Special Publication 800-61 Revision 3 hat den älteren 4-Phasen-Lebenszyklus abgelöst und ordnet die Aktivitäten des Incident Response den 6 Funktionen des NIST Cybersecurity Framework (CSF) 2.0 zu (Govern, Identify, Protect, Detect, Respond, Recover). Eine Organisation, die bereits am CSF 2.0 ausgerichtet ist, kann die Planabschnitte stattdessen mit den CSF-Funktionen benennen; die Entscheidungen in der Tabelle bleiben dieselben.

Welche Rollen und Verantwortlichkeiten gehören in einen Incident-Response-Plan?

Ein Incident-Response-Plan weist 6 Rollen zu, jeweils mit eigenem Entscheidungsbereich und in Deutschland mit eigenem Maß an rechtlicher Verantwortung.

Rolle	Verantwortung	Besonderheit in Deutschland
Incident Commander	Leitet die Reaktion, verteilt Aufgaben und überwacht die Meldefristen	Häufig die SOC-Leitung oder ein rotierender Security Manager in Rufbereitschaft
Technical Lead	Steuert Forensik, Eindämmung und Beseitigung	Arbeitet direkt mit den Konsolen von SIEM und SOAR
Communications Lead	Verantwortet interne Updates, Presseerklärungen und Kundeninformationen	Stimmt sich vor jeder öffentlichen Aussage mit der Rechtsberatung ab
Datenschutzbeauftragter (DSB)	Prüft die Meldepflicht nach Art. 33 DSGVO und erstellt die Meldung an die Aufsichtsbehörde	Für viele deutsche Unternehmen eine gesetzlich vorgeschriebene Rolle, unabhängig vom NIS2-Status
Geschäftsleitung (Geschäftsführung bzw. Vorstand)	Genehmigt den Plan und autorisiert weitreichende Entscheidungen wie das Abschalten eines Dienstes	Behält die Letztverantwortung nach § 38 BSIG, auch wenn Aufgaben an andere übertragen werden; haftet gegenüber der Gesellschaft für schuldhafte Pflichtverletzungen nach § 43 GmbHG (§ 93 AktG für den Vorstand einer AG)
Externe Rechtsberatung und Forensik	Berät zu rechtlichen Risiken, zum Umgang mit Beweismitteln und zum Kontakt mit Strafverfolgungsbehörden	Vorab über einen Retainer beauftragt, nicht erst während des Sicherheitsvorfalls gesucht

Weder die NIS2-Richtlinie noch das BSIG verlangt die Bestellung eines eigenen Chief Information Security Officers (CISO); die genannten Rollen können bei der bestehenden IT- oder SOC-Leitung liegen, sofern die Fähigkeit zur Bewältigung von Sicherheitsvorfällen selbst vorhanden ist. Alle 6 Rollen intern zu besetzen, ist unter den aktuellen Marktbedingungen schwierig: In Deutschland waren 2026 79.000 IT-Stellen unbesetzt, und 78 % der Unternehmen berichten von einem akuten Mangel an IT-Fachkräften (Bitkom, Der Arbeitsmarkt für IT-Fachkräfte, Ausgabe 2026). Kleinere Organisationen decken die technischen und kommunikativen Rollen deshalb häufig über ein Managed SOC oder einen externen CISO ab, statt ein vollständiges Team im eigenen Haus aufzubauen.

Wie bauen Sie den deutschen Meldezeitplan in den Plan ein?

Ein deutscher Incident-Response-Plan baut seinen Meldezeitplan um ein einziges Ereignis herum auf: die Kenntniserlangung von einem erheblichen Sicherheitsvorfall. Nach Art. 23 Abs. 3 NIS2-Richtlinie gilt ein Sicherheitsvorfall als erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder wenn er andere Personen durch erhebliche Schäden beeinträchtigt hat oder beeinträchtigen kann. Ab diesem Zeitpunkt laufen die Pflichten aus NIS2, DSGVO und BSI auf einer gemeinsamen Zeitachse statt auf 3 getrennten.

Zeit ab Kenntniserlangung des erheblichen Sicherheitsvorfalls	Pflicht nach NIS2UmsuCG	Pflicht nach DSGVO	Zuständig
Sofort	Der Incident Commander aktiviert den Plan	Der Datenschutzbeauftragte beginnt die Risikobewertung nach Art. 33	Incident Commander, DSB
Innerhalb von 24 Stunden	Frühe Erstmeldung an das BSI mit der Angabe, ob eine rechtswidrige oder böswillige Handlung oder eine grenzüberschreitende Auswirkung vermutet wird	Interne Risikobewertung läuft weiter; keine eigene 24-Stunden-Frist nach DSGVO	Incident Commander
Innerhalb von 72 Stunden	Meldung des Sicherheitsvorfalls an das BSI mit einer ersten Bewertung von Schweregrad und Auswirkungen und, soweit verfügbar, Kompromittierungsindikatoren (Indicators of Compromise, IoC)	Meldung an die zuständige Datenschutz-Aufsichtsbehörde nach Art. 33, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für Personen	Incident Commander, DSB
Unverzüglich nach Feststellung eines hohen Risikos	Zu diesem Zeitpunkt keine eigene NIS2-Frist	Benachrichtigung der betroffenen Personen nach Art. 34, wenn die Verletzung ein hohes Risiko für deren Rechte und Freiheiten darstellt	DSB, Communications Lead
Innerhalb eines Monats nach der 72-Stunden-Meldung	Abschlussmeldung an das BSI: Ursache, Auswirkungen und ergriffene Abhilfemaßnahmen	Zu diesem Zeitpunkt keine eigene DSGVO-Frist	Incident Commander, Technical Lead

Das NIS2UmsuCG, die deutsche Umsetzung der NIS2-Richtlinie, gilt für Organisationen mit mindestens 50 Beschäftigten oder mit einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Mio. € sowie für Betreiber kritischer Anlagen unabhängig von ihrer Größe. Das Bußgeld beträgt für eine besonders wichtige Einrichtung bis zu 10 Mio. € und für eine wichtige Einrichtung bis zu 7 Mio. €; bei Einrichtungen mit einem weltweiten Umsatz von über 500 Mio. € liegt die Obergrenze bei 2 % bzw. 1,4 % dieses Umsatzes.

Wie sieht ein Incident-Response-Playbook für ein konkretes Szenario aus?

Ein Incident-Response-Playbook übersetzt die allgemeinen Phasen des Plans in szenariospezifische Schritt-für-Schritt-Anleitungen für genau eine wiederkehrende Angriffsart. Ein Plan enthält üblicherweise mehrere Playbooks nebeneinander, je eines für jedes Szenario, mit dem die Organisation rechnet.

Szenario	Auslösendes Signal	Die ersten 3 Maßnahmen	Zuständige Phase
Ransomware	Massenhafte Dateiverschlüsselung, ungewöhnliche Prozesse, die Lösegeldforderungen ablegen	Betroffene Hosts isolieren, kompromittierte Konten deaktivieren, Offline-Backups aktivieren	Eindämmung
Kompromittiertes Konto	Anmeldungen mit unmöglicher Reisezeit (Impossible Travel), Rechteausweitung außerhalb eines Änderungsfensters	Aktive Sitzungen beenden, Zurücksetzen der Zugangsdaten erzwingen, Logs auf Lateral Movement prüfen	Identifizierung
DDoS	Plötzlicher Anstieg des Datenverkehrs, erschöpfte Verbindungstabellen an Edge-Geräten	DDoS-Scrubbing-Dienstleister aktivieren, Internetdienstanbieter (ISP) benachrichtigen, auf vereinbarte Notfallkapazität umschalten	Eindämmung
Datenabfluss	Große ausgehende Übertragung an eine unbekannte Domain, Alarm der Data-Loss-Prevention	Ziel blockieren, Logs als Beweismittel sichern, Meldepflicht nach Art. 33 DSGVO prüfen	Meldung

Jedes dieser Szenarien kann nach dem Auslösen weitgehend selbstständig ablaufen, sofern die Organisation die Reaktion vorab automatisiert hat. Der Beitrag SOAR-Playbooks erläutert im Detail, wie diese Automatisierung funktioniert: Anreicherung mit Threat Intelligence, Eindämmung auf Identitätsebene über den Verzeichnisdienst und die Zusammenführung von Fällen in einem einzigen Analysten-Dashboard.

Welche Rolle spielen SIEM und SOAR bei der Umsetzung des Plans?

Ein System für Security Information and Event Management (SIEM) liefert die Beweisebene, auf die der Plan angewiesen ist. Es sammelt und speichert Logs auf einer Infrastruktur, die von der Produktivumgebung getrennt ist, sodass die Logdaten erhalten bleiben, selbst wenn ein Angreifer lokale Systeme bei der Verschlüsselung zerstört. Diese Trennung macht das 72-Stunden-Meldefenster des BSI erreichbar statt bloß wünschenswert, und sie ist das praktische Rückgrat der Anforderung des BSI-Bausteins DER.2.1, die Behandlung von Sicherheitsvorfällen zu dokumentieren.

Eine Plattform für Security Orchestration, Automation and Response (SOAR) führt die Playbooks aus, die der Plan definiert. Sobald das SIEM Ereignisse zu einem bestätigten Sicherheitsvorfall korreliert, führt die SOAR-Plattform die vordefinierte Abfolge automatisch aus, isoliert Hosts und deaktiviert Konten, ohne auf eine manuelle Prüfung zu warten, und legt eine Fallakte an, die zur Zeitleiste des Sicherheitsvorfalls wird, auf die dieser Leitfaden durchgehend verweist.

Die so erzielte Geschwindigkeit ist messbar. Der IBM Cost of a Data Breach Report 2026 beziffert den weltweiten durchschnittlichen Lebenszyklus einer Datenpanne, also die kombinierte Zeit bis zur Erkennung und Eindämmung eines Sicherheitsvorfalls, auf 247 Tage; das ist ein Anstieg gegenüber dem Vorjahr, nachdem sich der Wert zuvor 5 Jahre in Folge verbessert hatte. Dieselbe Herstellerstudie stellte fest, dass Organisationen, die KI und Automatisierung in der Sicherheit umfassend einsetzen, ihre durchschnittlichen Kosten einer Datenpanne um 1,93 Mio. US-Dollar senkten und diesen Lebenszyklus um 65 Tage verkürzten, verglichen mit Organisationen ohne solchen Einsatz. Der Beitrag Kontext und KI im Incident Management zeigt, wie sich diese automatisierte Reaktion weiter präzisieren lässt: Die Anreicherung eines Alarms mit Angaben zu Kritikalität und Zuständigkeit eines Assets aus einer Configuration Management Database (CMDB) senkt die Zahl der Fehlalarme, bevor ein SOAR-Playbook überhaupt ausgeführt wird.

Wie testen Sie einen Incident-Response-Plan?

Eine Organisation testet einen Incident-Response-Plan durch Tabletop-Übungen: strukturierte Gespräche, in denen ein Moderator das Reaktionsteam durch ein simuliertes Szenario führt, ohne Produktivsysteme zu berühren. Eine Tabletop-Übung prüft, ob jede Rolle des Plans ihre Aufgaben kennt und ob die Alarmierungskette tatsächlich die richtigen Personen erreicht. Diese Lücken lassen sich durch eine reine Dokumentenprüfung nicht aufdecken. Gängige Leitfäden behandeln den Plan als lebendes Dokument und empfehlen, ihn vierteljährlich zu überprüfen und anzupassen, wenn sich Personal, Infrastruktur und Geschäftsprozesse ändern.

Tests haben in Deutschland ein besonderes Gewicht als Nachweis. Betreiber kritischer Anlagen müssen dem BSI ihre Sicherheitsmaßnahmen nach § 39 BSIG alle 3 Jahre durch Sicherheitsaudits, Prüfungen oder Zertifizierungen nachweisen, wobei das BSI die erste Frist frühestens 3 Jahre nach dem erstmaligen Eintritt der Betreibereigenschaft setzt. Besonders wichtige Einrichtungen können vom BSI jederzeit zu Audits verpflichtet werden. Ein ungetesteter Plan, der in einem Dokumentenarchiv liegt, gibt einem Prüfer nichts zum Verifizieren; ein datierter Nachweis einer Tabletop-Übung dagegen schon.

Welche Nachweise erwarten Prüfer für einen Incident-Response-Plan?

Prüfer, die einen deutschen Incident-Response-Plan begutachten, erwarten Nachweise in 3 Kategorien: einen dokumentierten Prozess, eine getestete Umsetzung und aufbewahrte Aufzeichnungen. Der dokumentierte Prozess entspricht dem BSI-Baustein DER.2.1 (Behandlung von Sicherheitsvorfällen), der festlegt, wie eine Organisation die Behandlung von Sicherheitsvorfällen im Rahmen des übergeordneten IT-Grundschutzes strukturieren sollte. Mit getesteter Umsetzung sind datierte Aufzeichnungen von Tabletop-Übungen oder Live-Übungen gemeint und nicht allein das Plandokument. Mit aufbewahrten Aufzeichnungen ist das Logarchiv des SIEM gemeint, getrennt von der Produktion gehalten und auch Monate nach dem Abschluss eines Sicherheitsvorfalls lesbar, denn dieses Archiv macht aus einer NIS2-Abschlussmeldung eine dokumentierte Rekonstruktion statt einer bloßen Schätzung nach bestem Wissen.

Betreiber kritischer Infrastrukturen (KRITIS) unterliegen einer zusätzlichen Ebene: § 39 BSIG regelt diese gesonderten Nachweispflichten und ersetzt den inzwischen aufgehobenen § 8a BSIG. Der oben beschriebene 3-Jahres-Nachweiszyklus gilt nur für KRITIS-Betreiber und nicht für jede Organisation, die unter NIS2 fällt.

Häufig gestellte Fragen

Ist ein Incident-Response-Plan in Deutschland gesetzlich vorgeschrieben? Ja, für Organisationen, die unter NIS2 fallen, ist ein Incident-Response-Plan in Deutschland faktisch vorgeschrieben. Art. 21 Abs. 2 lit. b NIS2-Richtlinie nennt die Bewältigung von Sicherheitsvorfällen als eine der Mindestmaßnahmen des Cybersicherheits-Risikomanagements, die besonders wichtige Einrichtungen und wichtige Einrichtungen umsetzen müssen; KRITIS-Betreiber unterliegen zusätzlich gesonderten Nachweispflichten nach § 39 BSIG. Organisationen außerhalb des NIS2-Anwendungsbereichs unterliegen keiner vergleichbaren gesetzlichen Pflicht, doch die 72-Stunden-Meldefrist nach Art. 33 DSGVO lässt sich ohne einen solchen Plan nur schwer einhalten.

Was ist der Unterschied zwischen einem Incident-Response-Plan und einem Incident-Response-Playbook? Ein Incident-Response-Plan ist das vollständige steuernde Dokument: Rollen, Phasen, Kommunikationsregeln und der Meldezeitplan. Ein Incident-Response-Playbook ist eine szenariospezifische Handlungsanweisung innerhalb dieses Plans und deckt genau eine Angriffsart ab, etwa Ransomware oder ein kompromittiertes Konto. Ein Plan enthält üblicherweise mehrere Playbooks, je eines für jedes wichtige Szenario, mit dem die Organisation rechnet.

Wie oft sollte ein Unternehmen seinen Incident-Response-Plan aktualisieren? Ein Unternehmen sollte seinen Incident-Response-Plan mindestens einmal im Jahr aktualisieren sowie unmittelbar nach jedem erheblichen Sicherheitsvorfall, jeder Änderung der Infrastruktur und jeder neuen regulatorischen Pflicht. Organisationen, die den Aufwand tragen können, überprüfen den Plan vierteljährlich und behandeln ihn als lebendes Dokument statt als statische Datei.

Wer ist in einem deutschen Unternehmen für den Incident-Response-Plan verantwortlich? Die Verantwortung für den Incident-Response-Plan liegt bei der Geschäftsleitung, in der GmbH also bei der Geschäftsführung, auch wenn die laufende Zuständigkeit in der Regel bei der IT- oder SOC-Leitung liegt. Nach § 38 BSIG behält die Geschäftsleitung die Letztverantwortung für die zugrunde liegende Pflicht zum Risikomanagement, auch wenn sie die Aufgaben an andere überträgt, und Geschäftsführer, die diese Pflicht schuldhaft verletzen, haften gegenüber ihrer eigenen Gesellschaft für den entstandenen Schaden nach § 43 GmbHG bzw. nach § 93 AktG für den Vorstand einer Aktiengesellschaft.

Zusammenfassung

Ein deutscher Incident-Response-Plan funktioniert nur, wenn er 2 Dinge verbindet, die die meisten Vorlagen getrennt halten: die operativen Phasen Vorbereitung, Identifizierung, Eindämmung, Beseitigung, Wiederherstellung und Lessons Learned sowie einen Meldezeitplan, der die Pflichten aus NIS2, DSGVO und BSI innerhalb derselben 24- und 72-Stunden-Fenster erfüllt. Nur 43 % der deutschen Unternehmen bezeichnen sich derzeit als sehr gut auf einen Cyberangriff vorbereitet, und 58 % haben bereits einen Schaden durch einen solchen erlitten, so die Studie Wirtschaftsschutz 2026 des Bitkom. Den Plan zu schreiben, ist der erste Schritt. Belastbar wird er erst, wenn Rollen mit echtem rechtlichem Gewicht zugewiesen, der Plan in Tabletop-Übungen erprobt und die Log-Nachweise des SIEM außerhalb der Reichweite eines Angriffs gehalten werden, sowohl im laufenden Sicherheitsvorfall als auch bei einer behördlichen Prüfung.