BLOG · GUIDE ·

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

IN KÜRZE
  • 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.

PLANABSCHNITTINHALTVERANTWORTLICH
Umfang und Aktivierungerfasste Systeme und Standorte; was als Sicherheits­vorfall gilt; wer ihn ausruftIT-Leitung
Rollen und BefugnisseIncident Manager, technische Leitung, Kommunikation, Rechts­abteilung, Datenschutz­beauftragter; Stell­vertretungen; wer Systeme herunter­fahren darfGeschäfts­leitung
Kontakte und KanäleMitarbeitende, Lieferanten, Versicherer, externe Forensiker, CSIRT, Polizei; gedruckte Exemplare; ein Out-of-Band-KanalIncident Manager
SchweregradeKriterien und Beispiele je Stufe; wer bei welcher Stufe alarmiert wirdLeitung IT-Sicherheit
PlaybooksAuslöser, erste Maßnahmen und Entscheidungen je Szenariotechnische Leitung, System­verantwortliche
Beweise und Vorfall­protokollwas gesichert wird, wo es aufbewahrt wird, wer Zugriff hattechnische Leitung
KommunikationMitarbeitende, Kunden, Lieferanten, Medien; freigegebene TexteLeitung Kommunikation
Behördliche Meldungenwer über Meldungen nach NIS2 und DSGVO entscheidet, wer sie absendetGeschäfts­leitung, Rechts­abteilung, Datenschutz­beauftragter
Start der Wieder­herstellungwann die Wieder­herstellung beginnt und der Sicherheits­vorfall abgeschlossen wird; RunbooksLeitung IT-Betrieb
Über­prüfungen und ÜbungenÜber­prüfungen nach Sicherheits­vorfällen, Übungsplan, Versions­historieIncident 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.

STUFEBEISPIELEWER ALARMIERT WIRD
NiedrigPhishing-Mail gemeldet; Schad­software auf einem Laptop blockiertService Desk, während der Arbeitszeit
Mittelein Benutzer­konto oder ein Arbeitsplatz­rechner kompromittiertLeitung IT-Sicherheit, am selben Tag
Hochein Server oder ein Administrator­konto kompromittiert; Daten verlassen das Netz; ein Dienst ausgefallenIncident Manager sofort; Geschäfts­leitung informiert
KritischVerschlüsselung breitet sich aus; Backups oder Hypervisoren betroffenalle 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.

EINSPIELUNGWAS SIE PRÜFTWAS FESTZUHALTEN IST
Montag 6:50, Shares gesperrtTriage, Ausrufen des Sicherheits­vorfalls, erste AlarmierungUhrzeit, angewandte Kriterien, wer entschieden hat
Backup-Jobs gelöschtBefugnis zur Isolierungwer die Isolierung angeordnet hat, wann, warum
Mail- und Verzeichnis­ausfallOut-of-Band-Kanal, gedruckte Kontaktlistewer nicht erreichbar war
Daten auf einer Leak-SeitePlaybook für Datenlecks, Prüfung nach DSGVOwer sie geleitet hat; was über die Daten bekannt war
Stunde 20, Melde­entscheidungEntscheidungen nach NIS2 und DSGVOEnt­scheidung, Begründung, Entwurf der Frühwarnung
Ein Journalist ruft anKommunikations­rollen, freigegebene Textewer geantwortet hat, mit welchem Text
Tag 2, Wieder­herstellungÜbergabe­kriterienangewandte 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?
Ein Incident-Response-Plan sollte die Rollen und Entscheidungsbefugnisse benennen, auch wer Systeme vom Netz trennen oder herunterfahren darf, dazu eine Kontaktliste, die ohne E-Mail funktioniert, Schweregrade mit Kriterien, Playbooks für wahrscheinliche Szenarien wie Ransomware, kompromittierte Konten und Datenlecks sowie Regeln für Beweissicherung, Kommunikation und behördliche Meldungen. Außerdem legt er die Kriterien für die Übergabe an die Wiederherstellung und den Abschluss des Sicherheitsvorfalls fest, ebenso den Zeitplan für Übungen und Überprüfungen nach Sicherheitsvorfällen. In ihrem Merkblatt IRP Basics, gelesen im Oktober 2026, beschreibt die CISA den Plan als schriftliches Dokument, das von der obersten Führungsebene formell genehmigt ist.
Gibt es eine Vorlage für einen Incident-Response-Plan?
NIST SP 800-61 Rev. 3 enthält keine Vorlage; die Publikation nennt die Elemente einer Incident-Response-Richtlinie, verweist für die Details auf Online-Ressourcen und überlässt Verfahren und Playbooks jeder Organisation selbst. Das Merkblatt Incident Response Plan (IRP) Basics der CISA (undatiert, gelesen im Oktober 2026) listet auf, was vor, während und nach einem Sicherheitsvorfall vorzubereiten ist, und die Leitlinie der ENISA vom Juni 2025 nennt zu jeder Anforderung an die Bewältigung von Sicherheitsvorfällen Beispiele für Nachweise. Eine brauchbare Vorlage hat Abschnitte für Umfang, Rollen und Entscheidungsbefugnisse, Kontakte, Schweregrade, Playbooks, Beweise, Kommunikation, Meldungen, die Übergabe an die Wiederherstellung und Überprüfungen.
Was unterscheidet den Incident-Response-Plan vom Incident-Response-Playbook?
Der Plan legt die Regeln fest, die für jeden Sicherheitsvorfall gelten, etwa Rollen und Entscheidungsbefugnisse, Kontakte, Schweregrade, Kommunikation, Meldungen und die Übergabe an die Wiederherstellung. Ein Playbook wendet sie auf ein Szenario an, etwa Ransomware oder ein kompromittiertes Konto, mit dem Auslöser, den ersten Maßnahmen, den Entscheidungen und den zu sichernden Beweisen, und NIST beschreibt Playbooks als umsetzbare Schritte oder Aufgaben für Personen in bestimmten Szenarien. Ein Runbook ist noch technischer und beschreibt die Schritte für ein System, etwa die Wiederherstellung eines Datenbankservers.
Was ist eine Tabletop-Übung in der Incident Response?
Eine Tabletop-Übung ist eine diskussionsbasierte Übung, in der ein Moderator ein Szenario schrittweise einspielt und die im Plan genannten Personen sagen, was sie entscheiden und tun würden, ohne ein System zu berühren. NIST SP 800-84 beschreibt sie als Diskussion über Rollen, Verantwortlichkeiten, Koordination und Entscheidungsfindung, und die Tabletop Exercise Packages der CISA enthalten, Stand Oktober 2026, Szenarien, Diskussionsfragen und eine Vorlage für den After Action Report. Halten Sie fest, wann Entscheidungen fielen, wer sie traf, welche Kontakte versagten und welche Teile des Plans geändert werden müssen.
Wie oft sollte ein Incident-Response-Plan getestet werden?
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 Denial of Service, und die Rollen und Verfahren mindestens jährlich zu überprüfen. Die Durchführungsverordnung (EU) 2024/2690 verlangt von den erfassten Anbietern, diese Verfahren in geplanten Zeitabständen zu testen und die Rollen und Verfahren des Konzepts auch bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken zu testen und zu überprüfen. Ergänzen Sie nach größeren Änderungen eine Übung, etwa bei einem neuen Identity Provider, Backup-System oder Hosting-Anbieter.
Schreibt NIS2 einen Incident-Response-Plan vor?
Artikel 21 Absatz 2 Buchstabe b der NIS2-Richtlinie zählt die Bewältigung von Sicherheitsvorfällen zu den Risikomanagementmaßnahmen im Bereich der Cybersicherheit, die wesentliche und wichtige Einrichtungen mindestens umsetzen müssen; diese Maßnahmen gelten über das nationale Recht. Für DNS-, Cloud- und Rechenzentrumsanbieter, Anbieter verwalteter Dienste und die übrigen erfassten digitalen Anbieter verlangt die Durchführungsverordnung (EU) 2024/2690 ein Konzept für die Bewältigung von Sicherheitsvorfällen mit Rollen, Verfahren, einem Kategorisierungssystem, Kommunikationsplänen und Dokumenten wie Anleitungen für die Reaktion bei Sicherheitsvorfällen, Eskalationsschemata und Kontaktlisten, wobei die Verfahren in geplanten Zeitabständen getestet werden. Ob NIS2 für Ihr Unternehmen gilt, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

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 sprechen
Mit einem Experten sprechen

Wir antworten innerhalb eines Werktages

Mit dem Absenden stimmen Sie zu, dass wir Ihre Angaben zur Beantwortung Ihrer Anfrage verarbeiten – siehe unsere Datenschutzerklärung.

request@eurokommerz.at
Jordangasse 7, 1010 Wien