Incident Response
Strukturierter Prozess zur Erkennung, Eindämmung, Beseitigung und Nachbereitung von Sicherheitsvorfällen in der IT-Infrastruktur.
Incident Response bezeichnet den systematischen Ansatz, mit dem Organisationen auf Sicherheitsvorfälle reagieren — von der ersten Erkennung über die Eindämmung und Beseitigung bis hin zur vollständigen Wiederherstellung und Nachbereitung. Ziel ist es, den Schaden eines Vorfalls zu minimieren, die Ausfallzeit zu verkürzen und aus jedem Vorfall strukturiert zu lernen.
Das NIST-Framework als Leitstruktur
Das NIST SP 800-61 hat die Vorfallbehandlung über Jahre geprägt. Revision 2 definierte vier Kernphasen: Vorbereitung (Preparation), Erkennung und Analyse (Detection & Analysis), Eindämmung, Beseitigung und Wiederherstellung (Containment, Eradication & Recovery) sowie Nachbereitung (Post-Incident Activity). Diese Phasen sind nicht streng sequenziell — in der Praxis überlappen sie sich, insbesondere wenn während der Eindämmung neue Angriffsvektoren entdeckt werden, die eine erneute Analyse erfordern. Revision 3 (veröffentlicht 2025) vollzieht einen Paradigmenwechsel und ordnet Incident Response in die sechs Funktionen des Cybersecurity Framework 2.0 ein (Govern, Identify, Protect, Detect, Respond, Recover). Die klassischen Phasen bleiben als operatives Modell weiterhin praxisrelevant.
Die Vorbereitung umfasst alles, was vor einem Vorfall geschieht: Incident-Response-Pläne erstellen, Rollen und Zuständigkeiten definieren, Kommunikationswege festlegen und technische Voraussetzungen schaffen. Die Erkennung stützt sich auf Werkzeuge wie SIEM zur Log-Korrelation und EDR zur Endpoint-Überwachung. Containment bedeutet, den Angreifer einzudämmen — etwa durch Netzwerkisolation betroffener Systeme oder Sperrung kompromittierter Konten. In der Nachbereitung wird der Vorfall dokumentiert und Lessons Learned abgeleitet, die in die Verbesserung der Vorbereitung einfließen.
Dieser Wandel in Revision 3 bedeutet: Incident Response wird nicht mehr als isolierter Prozess eines dedizierten Teams betrachtet, sondern als integraler Bestandteil des unternehmensweiten Cybersecurity-Risikomanagements. Vorbereitung, Governance und präventive Schutzmaßnahmen sind damit übergreifende Aktivitäten, die auch die Vorfallreaktion tragen.
BSI IT-Grundschutz und deutsche Anforderungen
Im deutschen Kontext bildet der Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen" des BSI IT-Grundschutz-Kompendiums die zentrale Referenz. Er fordert unter anderem eine klare Definition, was als Sicherheitsvorfall gilt, eine erreichbare Meldestelle, ein Incident-Response-Team mit technischer und kommunikativer Kompetenz sowie vorab definierte Prioritäten für die Behandlung.
Die NIS2-Richtlinie verschärft die Anforderungen zusätzlich: Betroffene Unternehmen müssen Vorfälle innerhalb von 24 Stunden an die zuständige Behörde melden — ohne einen eingespielten IR-Prozess ist diese Frist in der Praxis kaum einzuhalten. Auch ISO 27001 adressiert Incident Management explizit und verlangt dokumentierte Verfahren zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen.
Playbooks, Tabletop-Übungen und Retainer
Ein Incident-Response-Plan, der in einer Schublade liegt, ist wertlos. Drei Elemente machen den Unterschied zwischen Theorie und Praxis. Playbooks definieren für wiederkehrende Vorfalltypen — Ransomware-Befall, Phishing-Kompromittierung, laterale Bewegung im Netzwerk — konkrete Handlungsschritte, Zuständigkeiten und Eskalationswege. Tabletop-Übungen simulieren Vorfälle am Konferenztisch und decken regelmäßig Lücken auf: unklare Zuständigkeiten, fehlende Kontaktdaten von Dienstleistern oder technische Abhängigkeiten, die im Ernstfall kritisch wären. Retainer-Verträge mit spezialisierten IR-Dienstleistern sichern im Ernstfall garantierte Reaktionszeiten und forensische Expertise — Kapazitäten, die im Akutfall auf dem freien Markt kaum verfügbar sind.
Abgrenzung zu SIEM, EDR und SOAR
Incident Response ist kein einzelnes Werkzeug, sondern ein Prozess, der verschiedene Technologien orchestriert. SIEM liefert die Erkennung durch Log-Analyse und Korrelation. EDR überwacht Endpunkte und ermöglicht die Isolation betroffener Geräte. SOAR automatisiert wiederkehrende Reaktionsschritte — etwa die automatische Sperrung eines kompromittierten Kontos oder die netzwerkweite Blockierung eines Indicators of Compromise.
Incident Response verbindet diese Technologien mit organisatorischen Abläufen, Entscheidungsprozessen und menschlicher Expertise zu einer koordinierten Reaktionsfähigkeit. In der Praxis finden wir regelmäßig Umgebungen, in denen zwar SIEM und EDR implementiert sind, aber kein dokumentierter Prozess existiert, der definiert, wer bei einem Alarm welche Entscheidungen trifft — die Technologie erkennt den Vorfall, doch die Reaktion stockt an organisatorischen Lücken.
Relevanz für KMUs
Auch Unternehmen ohne eigenes Security Operations Center brauchen einen Incident-Response-Plan. Der erste Schritt ist pragmatisch: dokumentieren, wer im Ernstfall welche Entscheidungen trifft, wer intern und extern informiert werden muss und welche Systeme Priorität bei der Wiederherstellung haben.
Halbjährliche Tabletop-Übungen — auch im kleinen Rahmen mit IT-Leitung und Geschäftsführung — schaffen Routine und decken Schwachstellen im Prozess auf, bevor der Ernstfall eintritt. Für die technische Forensik und Eindämmung komplexer Angriffe empfiehlt sich ein Retainer-Vertrag mit einem spezialisierten Dienstleister, der im Bedarfsfall schnell handlungsfähig ist. Die Kosten eines solchen Vertrags stehen in keinem Verhältnis zu den Folgekosten eines unkontrollierten Sicherheitsvorfalls.
Eine erste Selbsteinschätzung, wie weit Ihr IR-Plan und die flankierenden Maßnahmen den Erwartungen typischer Cyber-Versicherer entsprechen, liefert der Cyber-Versicherungs-Readiness-Check — die Fragen 3.1 bis 3.3 adressieren genau den IR-Plan, die NIS2-Meldefristen und die Übungspraxis.