Was ist Incident Response? Der Plan für den Ernstfall
Was ist Incident Response? Incident Response ist der strukturierte Prozess, mit dem eine Organisation Sicherheitsvorfälle erkennt, eindämmt, behebt und nachbereitet. Statt im Ernstfall zu improvisieren, folgt sie einem vorbereiteten Plan mit klaren Rollen, Abläufen und Playbooks. Als Referenz dient häufig der Lebenszyklus des US-Instituts NIST.
Das Wichtigste in Kürze
- Was es ist: Ein geplanter Ablauf für den Umgang mit Sicherheitsvorfällen, von der Vorbereitung bis zur Auswertung.
- Die Phasen: Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung und Wiederherstellung sowie Lessons Learned.
- Warum jetzt: Meldefristen aus NIS2, DSGVO und DORA laufen im Ernstfall parallel und lassen wenig Zeit für Abstimmung.
Die Phasen im Überblick
Der etablierte Zyklus beginnt mit der Vorbereitung: Rollen, Kontakte, Werkzeuge und Playbooks stehen bereit, bevor etwas passiert. Es folgt die Erkennung und Analyse, in der aus Alarmen und Beobachtungen ein bestätigter Vorfall wird. Hier entscheidet sich, wie schnell eine Organisation überhaupt reagieren kann.
Danach greifen Eindämmung, Beseitigung und Wiederherstellung: Der Vorfall wird begrenzt, die Ursache entfernt und der Normalbetrieb kontrolliert wieder aufgenommen. Den Abschluss bildet die Nachbereitung. In den Lessons Learned wird ausgewertet, was funktioniert hat und was der Plan künftig anders regeln muss.
Vorbereitung, Erkennung und Analyse, Eindämmung bis Wiederherstellung sowie Nachbereitung – der Lebenszyklus nach NIST SP 800-61
Quelle: NIST SP 800-61
Was ein belastbarer IR-Plan enthält
Ein Incident-Response-Plan beschreibt, wer im Ernstfall was entscheidet. Er benennt das Reaktionsteam, oft als CSIRT bezeichnet. Zugleich legt er Eskalationswege, Kommunikationskanäle und externe Ansprechpartner fest. Playbooks für typische Fälle wie Ransomware oder Datenabfluss übersetzen den Plan in konkrete Schritte.
Entscheidend ist, dass der Plan geübt wird. Eine Tabletop-Übung deckt Lücken auf, bevor ein echter Vorfall sie findet. Viele Organisationen sichern sich zusätzlich über einen IR-Retainer ab, der im Ernstfall externe Spezialisten mit garantierter Reaktionszeit bereitstellt.
Ein IR-Plan, der im Ernstfall trägt
- ✓Reaktionsteam und Entscheidungswege schriftlich festlegen
- ✓Playbooks für die wahrscheinlichsten Vorfälle vorbereiten
- ✓Meldefristen aus NIS2, DSGVO und DORA im Plan verankern
- ✓Den Plan mindestens einmal jährlich in einer Übung testen
Warum die Uhr sofort tickt
Im Vorfall laufen mehrere Fristen gleichzeitig. Nach Artikel 23 der Richtlinie (EU) 2022/2555 (NIS2) ist eine erste Frühwarnung binnen 24 Stunden vorgesehen, eine ausführlichere Meldung binnen 72 Stunden und ein Abschlussbericht innerhalb eines Monats. Artikel 33 DSGVO verlangt bei einer Verletzung des Schutzes personenbezogener Daten eine Meldung unverzüglich und möglichst binnen 72 Stunden an die Aufsichtsbehörde, sofern ein Risiko für betroffene Personen besteht.
Für Finanzunternehmen kommt die Verordnung (EU) 2022/2554 (DORA) mit gestuften Meldewegen hinzu, eine Erstinformation innerhalb von 4 Stunden nach Klassifikation eines schwerwiegenden IKT-Vorfalls und spätestens 24 Stunden nach Kenntnis, einen Zwischenbericht innerhalb von 72 Stunden nach der Erstmeldung und einen Abschlussbericht innerhalb eines Monats nach dem Zwischenbericht (RTS (EU) 2025/301). Wer diese Pflichten erst im Ernstfall nachschlägt, verliert wertvolle Zeit. Deshalb gehören die Fristen und die zugehörigen Meldeformulare direkt in den Incident-Response-Plan, nicht in ein separates Compliance-Dokument.
Die häufigsten Fehler im Ernstfall
Der teuerste Fehler passiert oft in den ersten Minuten: Betroffene Systeme werden vorschnell neu gestartet oder bereinigt, bevor Spuren gesichert sind. Damit verschwinden genau die Daten, die für die Analyse und für spätere Meldungen gebraucht werden. Ein guter Plan trennt deshalb Eindämmung von Beweissicherung und regelt, wer wann welche Systeme anfassen darf.
Der zweite verbreitete Fehler ist unklare Kommunikation. Wenn im Vorfall niemand weiß, wer die Geschäftsleitung, die Aufsichtsbehörde oder die betroffenen Kunden informiert, entstehen widersprüchliche Aussagen und verpasste Fristen. Ein Kommunikationsplan als fester Teil der Incident Response sorgt dafür, dass technische Reaktion und Information Hand in Hand laufen, statt sich gegenseitig zu blockieren.
Interne und externe Kräfte richtig kombinieren
Kaum eine Organisation hält alle Fähigkeiten für jeden Vorfall selbst vor. Die Kunst liegt darin, interne Kräfte und externe Spezialisten sinnvoll zu verzahnen. Das interne Team kennt die Systeme und entscheidet, externe Forensiker und Incident Responder bringen Spezialwissen und zusätzliche Kapazität in der akuten Phase.
Damit die Übergabe im Ernstfall funktioniert, müssen die Schnittstellen vorher geklärt sein. Wer darf externe Kräfte alarmieren, welche Zugänge brauchen sie, wo liegen die relevanten Informationen? Ein IR-Retainer mit klar definierten Abläufen verhindert, dass im Vorfall wertvolle Stunden mit Vertragsfragen und Zugangsklärung vergehen, statt mit der eigentlichen Reaktion.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Was ist der Unterschied zwischen IR und einem SOC?
Ein Security Operations Center überwacht laufend und erkennt Vorfälle. Incident Response ist der Prozess, der nach der Erkennung greift und den Vorfall strukturiert bearbeitet. Beide arbeiten eng zusammen.
Brauchen kleine Unternehmen einen IR-Plan?
Ja. Gerade ohne großes Sicherheitsteam hilft ein einfacher, geübter Plan, im Ernstfall handlungsfähig zu bleiben. Er muss nicht umfangreich sein, aber er muss existieren und bekannt sein.
Was ist ein IR-Retainer?
Eine vertragliche Vereinbarung mit einem Dienstleister, der im Vorfall mit garantierter Reaktionszeit unterstützt. Das verkürzt die Zeit bis zum Eingreifen erfahrener Spezialisten.
Welche Meldefristen sind relevant?
Je nach Organisation NIS2 mit gestuften Fristen ab 24 Stunden, die DSGVO mit 72 Stunden bei Datenschutzverletzungen und für Finanzunternehmen DORA. Häufig greifen mehrere gleichzeitig.
Wie oft sollte man den Plan üben?
Mindestens einmal im Jahr, etwa in einer Tabletop-Übung. Nach größeren Änderungen an Systemen oder Team empfiehlt sich ein zusätzlicher Durchlauf.
Lesetipps der Redaktion
LesetippNihon Kotsu: Dispatch fällt nach MalwareLesetippLegacyHive-PoC trifft frische Windows-PatchesLesetippEin signierter Treiber macht den Endpunktschutz blind
Mehr aus dem MBF Media Netzwerk
cloudmagazinWenn KI-Agenten reisen: Data-Residency als Operating-ProblemMyBusinessFutureMehr Insolvenzen, kleinere Fälle: Was zähltDigital ChiefsDie Rechnung für zehn Jahre Insellösungen
Bildquelle: KI-generiert (Juli 2026)
