Was gehört in einen Incident-Response-Plan bei einem Cyberangriff?

Ein Incident-Response-Plan legt vorab fest, wie eine Organisation auf IT-Sicherheitsvorfälle wie einen Cyberangriff reagiert: was als Sicherheitsvorfall gilt, wer entscheidet und wen informiert, wie Schäden eingedämmt, Ursachen beseitigt und Systeme sicher wiederhergestellt werden und welche Meldefristen gelten. Dazu gehören Rollen und aktuelle Kontaktlisten, Melde- und Eskalationswege, Handlungsanweisungen für typische Vorfälle, Regeln zur Beweissicherung und eine Nachbereitung. Wirksam ist der Plan nur, wenn alle Beteiligten ihn kennen, er auch bei ausgefallener IT verfügbar ist und regelmäßig geübt wird.

Stand: 22. Oktober 2026. Diesen herstellerneutralen Leitfaden veröffentlicht der Marktplatz IT-Sicherheit des Instituts für Internet-Sicherheit – if(is), gestützt auf den IT-Grundschutz-Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“ des Bundesamts für Sicherheit in der Informationstechnik (BSI), die NIST-Richtlinie SP 800-61 Rev. 3 und das BSI-Gesetz.

Was ist ein Incident-Response-Plan?

Erkannte Sicherheitsvorfälle müssen schnell und effizient bearbeitet werden, um Schäden zu begrenzen und weitere zu vermeiden. Dafür braucht es laut BSI ein vorgegebenes und erprobtes Verfahren, im Englischen Security Incident Handling oder Security Incident Response. Der Incident-Response-Plan beschreibt dieses Verfahren. Sicherheitsvorfälle sind etwa Angriffe auf Server, Diebstahl vertraulicher Informationen, Sabotage, Erpressung mit IT-Bezug oder Fehlkonfigurationen, durch die vertrauliche Daten offenliegen.

Das US-Standardinstitut NIST hat seine Empfehlungen in SP 800-61 Rev. 3 (April 2025) neu gefasst. Es empfiehlt, Incident Response in alle Aktivitäten des Cybersicherheits-Risikomanagements nach dem NIST Cybersecurity Framework 2.0 einzubeziehen: um sich auf Vorfälle vorzubereiten, ihre Zahl und ihre Auswirkungen zu verringern und Erkennung, Reaktion und Wiederherstellung zu verbessern.

Welche Phasen hat Incident Response?

Die frühere Fassung der NIST-Richtlinie SP 800-61 beschrieb einen Kreislauf aus vier Phasen: Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; Nachbereitung. Die Neufassung Rev. 3 ordnet Incident Response den sechs Funktionen des NIST Cybersecurity Framework 2.0 zu. Govern (Steuern), Identify (Identifizieren) und Protect (Schützen) dienen der Vorbereitung; Detect (Erkennen), Respond (Reagieren) und Recover (Wiederherstellen) bilden die eigentliche Reaktion. Erkenntnisse sollen oft schon geteilt werden, sobald sie vorliegen, statt bis zum Ende der Wiederherstellung zu warten.

Was gehört in einen Incident-Response-Plan?

Ablauf im Ernstfall: von der Meldung bis zur Nachbereitung

1. Erkennen und melden: Beschäftigte melden Auffälligkeiten über einen bekannten, verlässlichen Kanal. Der Service Desk sollte Sicherheitsvorfälle erkennen können.
2. Einstufen und Team einberufen: Den Vorfall nach dem festgelegten Verfahren bewerten und das Vorfall-Team zusammenrufen. Bei akutem Handlungsbedarf die Leitung sofort informieren.
3. Eindämmen und Beweise sichern: Entscheiden, ob zuerst der Schaden begrenzt oder der Vorfall aufgeklärt werden soll. Betroffene Systeme vom Netz trennen, aber nicht voreilig herunterfahren oder Dateien löschen, weil sonst Spuren verloren gehen.
4. Ursache finden und beheben: Problem eingrenzen, Ursache ermitteln, Maßnahmen auswählen und nach Freigabe durch die Leitung des IT-Betriebs umsetzen, bis ein sicherer Zustand erreicht ist.
5. Sicher wiederherstellen: Betriebssysteme und Anwendungen auf Veränderungen prüfen, Daten von schreibgeschützten Datenträgern und nur aus nicht betroffenen Sicherungen einspielen, Patches und sichere Konfigurationen aufspielen, alle Zugangsdaten ändern und die Systeme danach gezielt überwachen.
6. Informieren und melden: betroffene interne und externe Stellen zeitnah unterrichten; prüfen, ob Datenschutzbeauftragte, Betriebs- oder Personalrat und Rechtsabteilung einzubeziehen sind; gesetzliche Meldepflichten und Fristen einhalten.
7. Nachbereiten: auswerten, wie schnell der Vorfall erkannt und behoben wurde, ob Meldewege und Erkennung funktionierten, und daraus Handlungsanweisungen für ähnliche Fälle ableiten.

Wer übernimmt im Ernstfall welche Rolle?

Für den Ernstfall empfiehlt CISA, drei Rollen zu besetzen. Eine Vorfall-Leitung (Incident Manager) steuert Kommunikation und Aufgaben, hält Beteiligte auf dem Laufenden, achtet auf die Zeit und übernimmt selbst keine technischen Arbeiten. Eine technische Leitung holt bei Bedarf weitere interne und externe Fachleute dazu, eine Kommunikationsleitung spricht mit Presse und externen Beteiligten. Plan und Kontaktliste sollten ausgedruckt bei allen Beteiligten liegen, weil E-Mail, Chat und Dateiablage im Vorfall ausfallen können.

Typische Fehler, die Beweise vernichten

Unter Stress werden schnell falsche Entscheidungen getroffen. Das BSI nennt Beispiele: Ein infizierter Rechner wird voreilig heruntergefahren, obwohl sich die Schadsoftware nur im laufenden Zustand analysieren ließe. Ein verdächtiger Prozess wird beendet und seine temporären Dateien gelöscht, sodass sich nicht mehr klären lässt, ob Daten abgeflossen sind. Oder fehlende Updates werden aus Angst vor Konsequenzen eingespielt, bevor ein Sicherheitsteam die Einbruchsursache untersucht hat. Ein Incident-Response-Plan und eine offene Fehlerkultur beugen dem vor.

Meldepflichten und Fristen

Besonders wichtige und wichtige Einrichtungen müssen erhebliche Sicherheitsvorfälle nach § 32 BSI-Gesetz (BSIG) an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) melden:

Liegt eine Verletzung des Schutzes personenbezogener Daten vor, meldet der Verantwortliche sie nach Art. 33 Absatz 1 der Datenschutz-Grundverordnung unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der zuständigen Aufsichtsbehörde. Das entfällt, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Wer später meldet, muss die Verzögerung begründen. Hat die Verletzung voraussichtlich ein hohes Risiko für die persönlichen Rechte und Freiheiten der Betroffenen zur Folge, sind nach Art. 34 auch die betroffenen Personen unverzüglich zu benachrichtigen. Für Finanzunternehmen im Sinne der EU-Verordnung DORA gilt § 32 BSIG nicht (§ 28 Absatz 6 BSIG). Sie melden schwerwiegende IKT-bezogene Vorfälle nach Art. 19 DORA der zuständigen Behörde. Auch für bestimmte Telekommunikations- und Energieunternehmen gilt § 32 BSIG nicht (§ 28 Absatz 5 BSIG). Sie melden mit denselben Fristen nach § 168 Telekommunikationsgesetz an Bundesnetzagentur und BSI oder nach § 5d Absatz 3 Energiewirtschaftsgesetz an die gemeinsame Meldestelle. Welche Unternehmen unter das BSI-Gesetz fallen, erklärt der Leitfaden Was ist IT-Sicherheit?.

Wann ist ein Sicherheitsvorfall erheblich?

Meldepflichtig nach § 32 BSIG sind nur erhebliche Sicherheitsvorfälle. Erheblich ist ein Vorfall nach § 2 Nummer 11 BSIG, wenn er schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die Einrichtung verursacht hat oder verursachen kann. Erheblich ist er auch, wenn er andere Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann; eine Rechtsverordnung kann den Begriff noch genauer fassen.

Was in die Meldungen nach § 32 BSIG gehört

Die Erstmeldung gibt an, ob der Verdacht besteht, dass der Vorfall auf rechtswidrige oder böswillige Handlungen zurückgeht oder grenzüberschreitende Auswirkungen haben könnte. Die 72-Stunden-Meldung bestätigt oder aktualisiert diese Angaben und enthält eine erste Bewertung mit Schweregrad und Auswirkungen, gegebenenfalls auch Kompromittierungsindikatoren. Die Abschlussmeldung beschreibt den Vorfall ausführlich, die wahrscheinliche Ursache, die getroffenen und laufenden Abhilfemaßnahmen und gegebenenfalls grenzüberschreitende Auswirkungen.

Üben: Planspiele und Notfallübungen

Das BSI hält ein vorgegebenes und erprobtes Verfahren für notwendig. Es empfiehlt, die Eskalationswege in Übungen zu erproben und die Vorgehensweise regelmäßig auf Aktualität und Wirksamkeit zu prüfen. Bei erhöhtem Schutzbedarf schlägt das BSI zusätzlich angekündigte und unangekündigte Übungen sowie Planspiele vor. Dazu gehört, Messgrößen der Vorfallbearbeitung auszuwerten, etwa die Zeit von der Erstmeldung bis zur verbindlichen Bestätigung eines Sicherheitsvorfalls. Wichtig ist auch, dass Kontaktlisten, Ticketsystem und Handlungsanweisungen während eines Vorfalls verfügbar bleiben, notfalls auf Papier.

Externe Hilfe vorab klären

Nach einem akuten Sicherheitsvorfall kann laut BSI die Einbindung eines qualifizierten Dienstleisters sinnvoll sein. Eine aktuelle Liste interner und externer Sicherheitsfachleute, die bei Vorfällen hinzugezogen werden können, und sichere Kommunikationsverfahren mit ihnen verlangt das BSI als Basis-Anforderung. Sinnvoll sind etwa Fachleute für IT-Forensik, Incident Response, Recht und Krisenkommunikation. Für gezielte Angriffe veröffentlicht das BSI eine Liste qualifizierter APT-Response-Dienstleister. Eine dauerhafte Überwachung bieten Dienstleister für ein Security Operations Center (SOC).

Häufige Fragen

Was ist der Unterschied zwischen Incident Response und Notfallmanagement?

Incident Response behandelt Sicherheitsvorfälle aus Sicht der IT: erkennen, eindämmen, beheben, wiederherstellen. Das Notfallmanagement sorgt dafür, dass kritische Geschäftsprozesse bei schweren Ausfällen weiterlaufen. Beide sollten nach BSI aufeinander abgestimmt sein. Ob ein Notfall vorliegt, wird nach BSI im Rahmen der Sicherheitsvorfallbehandlung entschieden.

Wer gehört in ein Incident-Response-Team?

Fachleute aus IT-Betrieb und Informationssicherheit, je nach Vorfall ergänzt um Leitung, Datenschutz, Recht, Kommunikation und Fachabteilungen. Die Mitglieder sollten vorab benannt und eingewiesen sein; neben technischem Verständnis brauchen sie Kommunikationsstärke.

Wie schnell muss ein Sicherheitsvorfall gemeldet werden?

Für besonders wichtige und wichtige Einrichtungen nach dem BSI-Gesetz gilt bei erheblichen Sicherheitsvorfällen: Erstmeldung unverzüglich, spätestens 24 Stunden nach Kenntnis; Meldung mit erster Bewertung unverzüglich, spätestens 72 Stunden nach Kenntnis; Abschlussmeldung spätestens einen Monat nach der 72-Stunden-Meldung. Verletzungen des Schutzes personenbezogener Daten meldet der Verantwortliche nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde, außer die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen.

Was tun in den ersten Minuten eines Angriffs?

Ruhe bewahren und den Vorfall sofort über den festgelegten Meldeweg melden. Beschäftigte stellen die Arbeit am betroffenen System ein, notieren ihre Beobachtungen und ergreifen Maßnahmen nur nach Anweisung; so empfiehlt es die IT-Notfallkarte des BSI. Das Vorfall-Team trennt betroffene Systeme vom Netz, ohne sie voreilig herunterzufahren oder Dateien zu löschen, und entscheidet nach dem Incident-Response-Plan über alles Weitere.

Wie oft sollte der Plan geprüft und geübt werden?

Regelmäßig und nach jedem analysierten Vorfall. Für die Prüfung nennt das BSI keinen festen Abstand. Die Richtlinie muss regelmäßig geprüft und aktualisiert werden (Basis-Anforderung). Als Standard-Anforderung empfiehlt das BSI, die Vorgehensweise regelmäßig auf Aktualität und Wirksamkeit zu prüfen und die Eskalationswege in Übungen zu erproben. Die Leitung soll jährlich über die Sicherheitsvorfälle unterrichtet werden; bei sofortigem Handlungsbedarf muss sie umgehend informiert werden.

Weitere Leitfäden des Marktplatzes IT-Sicherheit: Was ist IT-Sicherheit? · Wie funktioniert eine Firewall? · 3-2-1-Backup-Regel · Security-Awareness-Training aufbauen

Quellen

• Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kompendium, Baustein DER.2.1 Behandlung von Sicherheitsvorfällen, Edition 2023, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/05_DER_Detektion_und_Reaktion/DER_2_1_Behandlung_von_Sicherheitsvorfaellen_Edition_2023.pdf?__blob=publicationFile&v=3
• National Institute of Standards and Technology (NIST): SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, April 2025, https://csrc.nist.gov/pubs/sp/800/61/r3/final
• BSI-Gesetz (BSIG), § 2 Nr. 11 und § 32 Meldepflichten, https://www.gesetze-im-internet.de/bsig_2025/__2.html und https://www.gesetze-im-internet.de/bsig_2025/__32.html
• CISA: Incident Response Plan (IRP) Basics, https://www.cisa.gov/sites/default/files/publications/Incident-Response-Plan-Basics_508c.pdf
• Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), Art. 33 Absatz 1 und Art. 34 Absatz 1, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:02016R0679-20160504
• BSI-Gesetz (BSIG), § 28 Absatz 5 und 6, https://www.gesetze-im-internet.de/bsig_2025/__28.html
• Telekommunikationsgesetz (TKG), § 168, https://www.gesetze-im-internet.de/tkg_2021/__168.html
• Energiewirtschaftsgesetz (EnWG), § 5d Absatz 3, https://www.gesetze-im-internet.de/enwg_2005/__5d.html
• Verordnung (EU) 2022/2554 (DORA), Art. 19, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554
• BSI: Qualifizierte Dienstleister, mit Liste der qualifizierten APT-Response-Dienstleister, https://www.bsi.bund.de/dok/qualifizierte-it-dienstleister
• BSI: IT-Notfallkarte „Verhalten bei IT-Notfällen“, https://www.bsi.bund.de/dok/13035678