Incident-Response-Plan: was er enthalten muss, welche Playbooks er braucht und wie Sie ihn testen
Eurokommerz, Wien, seit 2006: Private AI/ML · IT Managed Services · Enterprise Training · KI-Hardware & Software
- Ein Incident-Response-Plan legt fest, wer die Reaktion leitet und wer Systeme vom Netz trennen oder herunterfahren darf, und enthält die Kontaktliste, die Schweregrade, die Playbooks sowie die Regeln für Beweissicherung, Kommunikation, Meldungen und die Übergabe an die Wiederherstellung
- NIST SP 800-61 Rev. 3 (April 2025) hat den Lebenszyklus aus vier Phasen von Rev. 2 durch ein Profil ersetzt, das auf den sechs Funktionen des CSF 2.0 aufbaut, und beschreibt nicht mehr, wie jede Tätigkeit auszuführen ist, wobei die Publikation die Leser auf Online-Ressourcen und auf ihre eigenen Verfahren und Playbooks verweist
- Für die digitalen Anbieter, die sie erfasst, verlangt die Durchführungsverordnung (EU) 2024/2690 ein Konzept für die Bewältigung von Sicherheitsvorfällen mit einem Kategorisierungssystem, Kommunikationsplänen für Eskalation und Meldung, zugewiesenen Rollen und Dokumenten wie Anleitungen für die Reaktion, Eskalationsschemata, Kontaktlisten und Vorlagen
- Die Leitlinie der ENISA vom Juni 2025 schlägt vor, die Verfahren zur Reaktion auf Sicherheitsvorfälle mindestens jährlich zu testen, mit verschiedenen Arten von Vorfällen wie Ransomware, Phishing, Datenleck und DoS und, wo nötig, unter Einbeziehung der Leitungsorgane
- Eine Tabletop-Übung führt die im Plan genannten Personen durch ein schrittweise eingespieltes Szenario, ohne ein System zu berühren; halten Sie fest, wann jede Entscheidung fiel, wer sie traf und welche Kontakte oder Schritte versagten
Eurokommerz × Vixen.UNO: Cyber-Resilienz Experten kontaktieren →
Was ein Incident-Response-Plan enthalten muss
Ein Incident-Response-Plan legt fest, wer die Reaktion auf einen Sicherheitsvorfall leitet und wer Systeme vom Netz trennen oder herunterfahren darf. Er enthält die Kontaktliste, die Schweregrade, Playbooks für wahrscheinliche Szenarien und die Regeln für Beweissicherung, Kommunikation, behördliche Meldungen und die Übergabe an die Wiederherstellung. Die CISA, die Cybersecurity and Infrastructure Security Agency der USA, beschreibt ihn in einem undatierten Merkblatt (gelesen im Oktober 2026) als „ein schriftliches Dokument, das von der obersten Führungsebene formell genehmigt ist“, zur Verwendung vor, während und nach einem Sicherheitsvorfall. Die Tabelle dient als Gliederung für eine Vorlage, mit dem Verantwortlichen, den wir je Abschnitt vorschlagen.
| PLANABSCHNITT | INHALT | VERANTWORTLICH |
|---|---|---|
| Umfang und Aktivierung | erfasste Systeme und Standorte; was als Sicherheitsvorfall gilt; wer ihn ausruft | IT-Leitung |
| Rollen und Befugnisse | Incident Manager, technische Leitung, Kommunikation, Rechtsabteilung, Datenschutzbeauftragter; Stellvertretungen; wer Systeme herunterfahren darf | Geschäftsleitung |
| Kontakte und Kanäle | Mitarbeitende, Lieferanten, Versicherer, externe Forensiker, CSIRT, Polizei; gedruckte Exemplare; ein Out-of-Band-Kanal | Incident Manager |
| Schweregrade | Kriterien und Beispiele je Stufe; wer bei welcher Stufe alarmiert wird | Leitung IT-Sicherheit |
| Playbooks | Auslöser, erste Maßnahmen und Entscheidungen je Szenario | technische Leitung, Systemverantwortliche |
| Beweise und Vorfallprotokoll | was gesichert wird, wo es aufbewahrt wird, wer Zugriff hat | technische Leitung |
| Kommunikation | Mitarbeitende, Kunden, Lieferanten, Medien; freigegebene Texte | Leitung Kommunikation |
| Behördliche Meldungen | wer über Meldungen nach NIS2 und DSGVO entscheidet, wer sie absendet | Geschäftsleitung, Rechtsabteilung, Datenschutzbeauftragter |
| Start der Wiederherstellung | wann die Wiederherstellung beginnt und der Sicherheitsvorfall abgeschlossen wird; Runbooks | Leitung IT-Betrieb |
| Überprüfungen und Übungen | Überprüfungen nach Sicherheitsvorfällen, Übungsplan, Versionshistorie | Incident Manager |
Abschnitte nach der Durchführungsverordnung (EU) 2024/2690, Anhang, Nummern 3.1 bis 3.6, nach NIST SP 800-61 Rev. 3 (Abschnitte 2.2 und 2.3) und nach dem Merkblatt Incident Response Plan (IRP) Basics der CISA (undatiert, gelesen im Oktober 2026); die Spalte „Verantwortlich“ ist unser Vorschlag.
NIST SP 800-61 Rev. 3 und die EU-Regeln zur Vorfallbewältigung
NIST SP 800-61 Rev. 3, veröffentlicht im April 2025, hat Rev. 2 vom August 2012 und deren Lebenszyklus aus vier Phasen abgelöst. Die Publikation ist jetzt ein Community Profile des Cybersecurity Framework (CSF) 2.0, in dem Govern, Identify und Protect auf Sicherheitsvorfälle vorbereiten, Detect, Respond und Recover sie bewältigen und die Lehren aus allen sechs Funktionen in die Kategorie Improvement einfließen. NIST beschreibt nicht mehr jede Tätigkeit Schritt für Schritt, weil sich solche Details zu oft ändern, um sie in „einer einzigen statischen Veröffentlichung“ zu erfassen. Zu den Elementen einer Incident-Response-Richtlinie, die NIST aufzählt, gehören aber Definitionen von Sicherheitsvorfällen, Leitlinien zur Einschätzung ihres Schweregrads und die Festlegung, „welche Rollen befugt sind, IT-Assets zu beschlagnahmen, vom Netz zu trennen oder abzuschalten“.
Artikel 21 Absatz 2 Buchstabe b der NIS2-Richtlinie nennt die Bewältigung von Sicherheitsvorfällen unter den Mindestmaßnahmen für wesentliche und wichtige Einrichtungen. Die Durchführungsverordnung (EU) 2024/2690 verlangt von DNS-, Cloud- und Rechenzentrumsanbietern, Anbietern verwalteter Dienste und den übrigen digitalen Anbietern aus ihrem Artikel 1 ein Konzept für die Bewältigung von Sicherheitsvorfällen, das mit dem Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs im Einklang steht. Nach den Nummern 3.1.1 und 3.1.2 des Anhangs umfasst es ein Kategorisierungssystem, Kommunikationspläne „auch für die Eskalation und Meldung“, an kompetente Mitarbeitende zugewiesene Rollen und Dokumente „wie Anleitungen für die Reaktion bei Sicherheitsvorfällen, Eskalationsschemata, Kontaktlisten und Vorlagen“. Die Verordnung bindet nur diese Anbieter; die ENISA, die Agentur der Europäischen Union für Cybersicherheit, schreibt jedoch, ihre Leitlinie vom Juni 2025 für diese Anbieter könne auch für andere Stellen nützlich sein. Ob NIS2 für Ihr Unternehmen gilt, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.
Rollen, Entscheidungsbefugnisse und Out-of-Band-Kontakte
Das Merkblatt der CISA nennt drei Rollen: einen Incident Manager, der die Reaktion leitet und „keine technischen Aufgaben wahrnimmt“, einen Tech Manager, der als Fachexperte fungiert, und einen Communications Manager für Journalisten und externe Interessenträger. NIST ergänzt das Führungsteam, das „Entscheidungsbefugnis über Reaktionsmaßnahmen mit großer Tragweite haben kann, etwa das Abschalten oder den Neuaufbau kritischer Dienste“, sowie Rechtsexperten und Asset-Verantwortliche. Jede Rolle braucht eine namentlich benannte Stellvertretung und eine Besetzung für Nächte und Feiertage.
Listen Sie die Entscheidungen auf, jeweils mit der Rolle, die sie trifft: einen Sicherheitsvorfall ausrufen, einen Standort isolieren, einen Geschäftsdienst abschalten, alle privilegierten Zugangsdaten zurücksetzen, externe Forensiker hinzuziehen, Kunden informieren, die Polizei einschalten und an das CSIRT oder die Behörde melden. NIST trennt die Eskalation, die sich „im Allgemeinen auf die Erhöhung von Ressourcen oder Zeitrahmen bezieht“, von der Elevation, also der Einbindung einer höheren Managementebene, und der Plan legt für beide einen Auslöser fest.
Bewahren Sie die Kontaktliste außerhalb der Systeme auf, die ein Angreifer verschlüsseln könnte, etwa des Dateiservers und des Verzeichnisdienstes. Die CISA rät, den Plan und die Kontaktliste auszudrucken und ein Exemplar allen zu geben, „von denen Sie erwarten, dass sie bei einem Vorfall eine Rolle spielen“. Ergänzen Sie Mobilfunknummern, externe Kontakte und einen Out-of-Band-Kanal, der weder vom Verzeichnisdienst des Unternehmens noch von seinem Mailsystem abhängt; Artikel 21 Absatz 2 Buchstabe j der NIS2-Richtlinie zählt „gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung“ zu den Mindestmaßnahmen.
Im Rahmen unserer Leistung Cyber-Resilienz schreiben wir den Incident-Response-Plan mit Rollen, Maßnahmen und Fristen. Nennen Sie uns, wer heute entscheidet, ob Systeme vom Netz getrennt werden, und wie sich Ihr Team bei ausgefallener E-Mail gegenseitig erreichen würde.
Schweregrade und Eskalation
Für die von der Verordnung erfassten Anbieter verlangt ihr Anhang in Nummer 3.4.2 Buchstabe a, Ereignisse „auf der Grundlage vorab festgelegter Kriterien“ zu bewerten, mit einer Triage, welche die Priorisierung von Eindämmung und Beseitigung bestimmt. Die Leitlinie der ENISA nennt Klassen wie „niedriger, mittlerer, hoher oder kritischer Schweregrad“; geben Sie jeder Stufe Beispiele aus Ihrer eigenen Umgebung.
| STUFE | BEISPIELE | WER ALARMIERT WIRD |
|---|---|---|
| Niedrig | Phishing-Mail gemeldet; Schadsoftware auf einem Laptop blockiert | Service Desk, während der Arbeitszeit |
| Mittel | ein Benutzerkonto oder ein Arbeitsplatzrechner kompromittiert | Leitung IT-Sicherheit, am selben Tag |
| Hoch | ein Server oder ein Administratorkonto kompromittiert; Daten verlassen das Netz; ein Dienst ausgefallen | Incident Manager sofort; Geschäftsleitung informiert |
| Kritisch | Verschlüsselung breitet sich aus; Backups oder Hypervisoren betroffen | alle Rollen über den Out-of-Band-Kanal |
Beispielhafte Stufen: unser Vorschlag, angelehnt an die Klassen der ENISA-Leitlinie (Juni 2025).
Jeder Sicherheitsvorfall, der erheblich sein oder personenbezogene Daten betreffen könnte, geht unabhängig von seiner Stufe in die Prüfung der Meldepflichten nach NIS2 und DSGVO; die Schwellenwerte nennt unser Leitfaden zur Meldung von Sicherheitsvorfällen nach NIS2. Legen Sie fest, wer außerhalb der Bürozeiten Alarme erhält und was diese Person allein tun darf. Unser Vergleich von EDR, XDR, SIEM und MDR behandelt die Werkzeuge und wer sie überwacht.
Playbooks für Ransomware, kompromittierte Konten und Datenlecks
NIST beschreibt Playbooks als „umsetzbare Schritte oder Aufgaben, die Personen in verschiedenen Szenarien oder Situationen ausführen“. Die ENISA schlägt Playbooks oder Runbooks für häufige Arten von Sicherheitsvorfällen vor, „zum Beispiel Ransomware, Phishing, Daten- oder Geräteverlust oder Brand“. Jedes Playbook nennt seinen Auslöser, die ersten Maßnahmen und wer sie ergreift, die Entscheidungen, die der Geschäftsleitung vorbehalten sind, die zu sichernden Beweise und den Zeitpunkt, an dem der Vorfall in die Wiederherstellung übergeht.
Das Ransomware-Playbook deckt die erste Stunde ab: wer welche Netzsegmente isoliert, wer entscheidet, ob Hosts ausgeschaltet werden, wie das Backup-System vor den Konten des Angreifers geschützt wird und wann die Geschäftsleitung hinzugezogen wird. Die Schritte danach beschreibt unser Leitfaden zu den ersten 72 Stunden der Wiederherstellung nach Ransomware.
Das Playbook für kompromittierte Konten beginnt mit einer Meldung des Benutzers, einem Anmeldealarm oder einer unbekannten Mailregel. Das Konto wird gesperrt oder sein Passwort zurückgesetzt, seine Sitzungen werden beendet, Anmeldemethoden, die der Benutzer nicht registriert hat, werden entfernt, und die Weiterleitungsregeln werden geprüft. Solche Regeln richten Kriminelle laut dem britischen National Cyber Security Centre (NCSC) ein, damit ihnen „eine Kopie aller E-Mails, die an Ihr Konto gesendet werden“, zugeht. Protokolle zu Authentifizierung, Zugriffen und Kontoänderungen (Anhang, Nummer 3.2.3 Buchstaben b bis d) zeigen, wohin der Angreifer sonst noch gelangt ist und was er verändert hat.
Das Playbook für Datenlecks beginnt, wenn Unternehmensdaten außerhalb auftauchen oder ausgehender Datenverkehr auffällig ist, und klärt zuerst, was abgeflossen ist, aus welchem System und wessen Daten es sind. Sind personenbezogene Daten betroffen, folgt die Prüfung nach der DSGVO, mit dem Datenschutzbeauftragten, sofern es einen gibt. Jede Verletzung des Schutzes personenbezogener Daten wird nach Artikel 33 Absatz 5 dokumentiert. Nach Artikel 33 Absatz 1 wird sie unverzüglich und möglichst binnen 72 Stunden, nachdem sie bekannt wurde, der Aufsichtsbehörde gemeldet, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Hat sie voraussichtlich ein hohes Risiko für die betroffenen Personen zur Folge, werden diese nach Artikel 34 Absatz 1 benachrichtigt.
Incident-Response-Szenarien mit Rollen, Kommunikation und Meldefristen gehören zu unserer Leistung Cyber-Resilienz. Schreiben Sie uns, welche Szenarien Sie am meisten beschäftigen und was Ihr Team in der ersten Stunde tun würde.
Beweise, Kommunikation und die Übergabe an die Wiederherstellung
Anbieter im Anwendungsbereich der Verordnung müssen die Tätigkeiten zur Reaktion auf Sicherheitsvorfälle protokollieren und Nachweise sammeln (Anhang, Nummer 3.5.4). Die Liste der ENISA für das Vorfallprotokoll umfasst die Zeitpunkte von Erkennung, Eindämmung und Beseitigung, Kompromittierungsindikatoren, die Ursache und „ob das CSIRT oder die zuständige Behörde benachrichtigt wurde“. NIST merkt an, dass formale Verfahren zur Beweismittelkette (Chain of Custody) „möglicherweise nicht bei jedem Vorfall durchgeführt werden“, gesammelte Daten aber dennoch Beweismittel sind. Der Plan legt deshalb fest, wer Abbilder von Arbeitsspeicher und Datenträgern erstellen darf, wo sie außerhalb der betroffenen Domäne gespeichert werden, wie ihre Hashwerte berechnet werden und wer darauf zugreifen darf.
Nummer 3.5.3 verlangt Kommunikationspläne für das CSIRT oder die Behörde, für das Personal und für externe Interessenträger. Bereiten Sie freigegebene Texte für Mitarbeitende, Kunden und Lieferanten vor, dazu die vorläufige Stellungnahme (Holding Statement) für Journalisten, die die CISA im Voraus vorzubereiten empfiehlt. Für wesentliche und wichtige Einrichtungen ist die Frühwarnung nach NIS2 unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls fällig; der Plan legt daher fest, wer entscheidet und wer sie absendet.
Der Plan nennt die Kriterien für den Beginn der Wiederherstellung, wobei er „die mögliche Störung des Betriebs durch die Wiederherstellungsmaßnahmen“ abwägt, sowie die anzuwendenden Runbooks, wie sie unser Leitfaden zum Disaster-Recovery-Runbook beschreibt. Im Profil von NIST endet die Wiederherstellung nach festgelegten Kriterien mit einem After Action Report über den Sicherheitsvorfall, die ergriffenen Maßnahmen und die gezogenen Lehren.
Den Plan mit einer Tabletop-Übung testen
Nummer 3.5.5 des Anhangs verlangt von den Anbietern, die unter die Verordnung fallen, ihre Verfahren zur Reaktion auf Sicherheitsvorfälle in geplanten Zeitabständen zu testen, und Nummer 3.1.3 ergänzt Tests und Überprüfungen der im Konzept festgelegten Rollen und Verfahren bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken. Die ENISA schlägt vor, die Verfahren „mindestens jährlich“ zu testen, mit „verschiedenen Arten von Sicherheitsvorfällen, zum Beispiel Ransomware, Phishing, Datenleck und DoS“, unter Einbeziehung anderer Abteilungen, der Lieferanten und, wo nötig, der Leitungsorgane. Zu ihren Testmethoden für das Konzept gehören eine Tabletop-Übung, ein simulierter Sicherheitsvorfall, eine Red-Team- und Blue-Team-Übung und das Durchgehen eines früheren Sicherheitsvorfalls.
In NIST SP 800-84 ist eine Tabletop-Übung rein diskussionsbasiert, und ein Moderator präsentiert ein Szenario und stellt Fragen, die „eine Diskussion unter den Teilnehmern über Rollen, Verantwortlichkeiten, Koordination und Entscheidungsfindung“ anstoßen. Die Tabletop Exercise Packages der CISA (CTEPs, undatierte Seite, gelesen im Oktober 2026) bieten „vorgefertigte Übungsziele, Szenarien und Diskussionsfragen“, darunter Szenarien zu Ransomware, Insider-Bedrohungen und Phishing, mit einem Feedbackformular und einer Vorlage für den After Action Report. Passen Sie diese US-Pakete an Ihr CSIRT, Ihre Behörde und die DSGVO an, und spielen Sie das Szenario schrittweise ein.
| EINSPIELUNG | WAS SIE PRÜFT | WAS FESTZUHALTEN IST |
|---|---|---|
| Montag 6:50, Shares gesperrt | Triage, Ausrufen des Sicherheitsvorfalls, erste Alarmierung | Uhrzeit, angewandte Kriterien, wer entschieden hat |
| Backup-Jobs gelöscht | Befugnis zur Isolierung | wer die Isolierung angeordnet hat, wann, warum |
| Mail- und Verzeichnisausfall | Out-of-Band-Kanal, gedruckte Kontaktliste | wer nicht erreichbar war |
| Daten auf einer Leak-Seite | Playbook für Datenlecks, Prüfung nach DSGVO | wer sie geleitet hat; was über die Daten bekannt war |
| Stunde 20, Meldeentscheidung | Entscheidungen nach NIS2 und DSGVO | Entscheidung, Begründung, Entwurf der Frühwarnung |
| Ein Journalist ruft an | Kommunikationsrollen, freigegebene Texte | wer geantwortet hat, mit welchem Text |
| Tag 2, Wiederherstellung | Übergabekriterien | angewandte Kriterien; Runbooks benannt oder fehlend |
Beispielhafte Einspielungen und Aufzeichnungen: unser Vorschlag; Übungsformat nach NIST SP 800-84 (September 2006) und den Tabletop Exercise Packages der CISA (undatierte Seite, gelesen im Oktober 2026).
Bestimmen Sie einen Datenerfasser, der in NIST SP 800-84 „Informationen über die Handlungen festhält, die während der Übung stattfinden“, und schließen Sie mit einer Nachbesprechung darüber ab, welche Bereiche des Plans aktualisiert werden sollten. Failover-Tests am Ausweichstandort sind eine eigene Übung, die unser Leitfaden zu Disaster-Recovery-Tests beschreibt.
Überprüfungen nach Sicherheitsvorfällen und die Pflege des Plans
Soweit angemessen, führen dieselben Anbieter Überprüfungen nach Sicherheitsvorfällen durch, die, soweit möglich, die Ursache ermitteln und die gezogenen Lehren dokumentieren (Anhang, Nummer 3.6.1). Die Leitlinie der ENISA ergänzt Lehren, „begleitet von Empfehlungen und deren Verantwortlichen“, ein Überprüfungsteam aus IT, Sicherheit, Rechtsabteilung und Leitungsorganen sowie Lücken, die „in die Risikobewertung und den Risikobehandlungsplan zurückfließen“. Erkenntnisse aus Übungen werden ebenso behandelt.
Das Merkblatt der CISA schlägt vor, den Plan vierteljährlich zu überprüfen, die Leitlinie der ENISA mindestens jährlich. Aktualisieren Sie den Plan außerdem, wenn sich etwas ändert, das er nennt, etwa der Identity Provider, das Backup-System, ein Lieferant oder die Personen in seinen Rollen; die ENISA zählt Aktualisierungen von Verfahren mit Versionshistorie zu ihren Beispielen für Nachweise.
Was wir tun
Im Rahmen unserer Leistung Cyber-Resilienz schreibt unser Engineering-Partner Vixen.UNO den Incident-Response-Plan mit Rollen, Maßnahmen und Fristen, damit das Team am Tag X einem Plan folgt, statt zu improvisieren. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments, das Ihnen eine Risikokarte und einen priorisierten Maßnahmenplan liefert, steht vor Beginn fest. Ein laufender Vorfall wird in einem eigenen Arbeitsmodus bearbeitet; schreiben Sie uns in diesem Fall sofort.
FAQ
Was gehört in einen Incident-Response-Plan für Cyberangriffe?
Gibt es eine Vorlage für einen Incident-Response-Plan?
Was unterscheidet den Incident-Response-Plan vom Incident-Response-Playbook?
Was ist eine Tabletop-Übung in der Incident Response?
Wie oft sollte ein Incident-Response-Plan getestet werden?
Schreibt NIS2 einen Incident-Response-Plan vor?
Schicken Sie uns, ob ein Incident-Response-Plan oder ein Runbook existiert und wann das Dokument zuletzt aktualisiert wurde, wer heute über das Trennen von Systemen und über Meldungen entscheidet sowie Datum und Szenario Ihrer letzten Übung. Wir antworten innerhalb eines Werktages mit einem Termin für ein erstes Gespräch, aus dem Sie zwei oder drei mögliche Lösungsszenarien mitnehmen. Das erste Gespräch ist kostenlos.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages