Incident Response: Was Unternehmen falsch machen
Das Wichtigste in Kürze
- Ein Incident Response Plan, der nur als Dokument in einem SharePoint-Ordner existiert, ist keine Reaktionsfähigkeit — er muss mindestens zweimal jährlich in Tabletop-Übungen geübt werden
- Unklare Rollenverteilung ist der häufigste Grund für Verzögerungen im Ernstfall: Wer entscheidet, wer kommuniziert, wer koordiniert — muss vorab schriftlich festgelegt sein
- Kommunikation wird regelmäßig vernachlässigt: Vorlagen für interne und externe Kommunikation sowie Eskalationswege müssen Teil des Plans sein
- Ein Severity-Modell mit drei bis vier Stufen gibt die Grundlage für angemessene Entscheidungen — nicht jeder Vorfall ist eine Krise
- Lessons Learned ohne verbindlichen Umsetzungsprozess verpuffen: eine verantwortliche Person, ein Zeitrahmen und eine Nachverfolgung sind Pflicht
Einen Incident Response Plan zu haben und einen wirksamen zu haben sind zwei grundlegend verschiedene Dinge. Die meisten Unternehmen, die wir beraten, verfügen über ein Dokument, das als Reaktionsplan bezeichnet wird. In der Praxis erweist sich dieses Dokument bei einem realen Vorfall häufig als unzureichend.
Das liegt selten am fehlenden Willen. Es liegt an systematischen Fehlern, die sich vermeiden lassen.
Fehler 1: Der Plan ist ein Dokument, kein Prozess
Ein Incident Response Plan, der einmal geschrieben und dann in einem SharePoint-Ordner abgelegt wird, ist kein Plan. Er ist eine Absichtserklärung. Wirksame Reaktionsfähigkeit entsteht durch regelmäßige Übung, durch klare Rollenverteilung und durch Prozesse, die unter Stress funktionieren.
Konkret bedeutet das: Mindestens zweimal jährlich sollte eine Tabletop-Übung stattfinden, bei der die beteiligten Teams einen simulierten Vorfall durchspielen. Nicht als Pflichtprogramm, sondern als ernsthaftes Training, das Schwachstellen im Prozess aufdeckt.
Fehler 2: Rollen und Verantwortlichkeiten sind unklar
Wer entscheidet, ob ein Sicherheitsvorfall vorliegt? Wer informiert die Geschäftsführung? Wer koordiniert die technische Analyse? Wer kommuniziert nach außen?
In vielen Organisationen sind diese Fragen nicht eindeutig geklärt. Das führt im Ernstfall zu Verzögerungen, Doppelarbeit und Kommunikationsproblemen. Ein wirksamer Plan definiert für jede Phase des Vorfalls klare Verantwortlichkeiten — und benennt Stellvertreter.
Fehler 3: Kommunikation wird vernachlässigt
Die technische Reaktion auf einen Sicherheitsvorfall ist nur ein Teil der Aufgabe. Mindestens ebenso wichtig ist die Kommunikation: intern gegenüber Mitarbeitenden und Führungskräften, extern gegenüber Kunden, Partnern, Behörden und gegebenenfalls der Öffentlichkeit.
Viele Pläne enthalten keine Kommunikationsvorlagen, keine definierten Eskalationswege und keine Abstimmung mit der Rechtsabteilung. Das rächt sich, wenn unter Zeitdruck formuliert werden muss.
Fehler 4: Kein definiertes Severity-Modell
Nicht jeder Vorfall erfordert die gleiche Reaktion. Ein Phishing-Versuch, der erkannt und blockiert wurde, ist keine Krise. Ein kompromittiertes Administratorkonto schon. Ohne ein klares Severity-Modell fehlt die Grundlage für angemessene Entscheidungen.
Ein pragmatisches Modell unterscheidet drei bis vier Stufen, definiert für jede Stufe die erwartete Reaktionszeit, die zu informierenden Personen und die erforderlichen Maßnahmen.
Fehler 5: Lessons Learned werden nicht umgesetzt
Nach einem Vorfall folgt in den meisten Unternehmen ein Review. Das Ergebnis wird dokumentiert, verteilt — und dann passiert nichts. Die identifizierten Verbesserungen werden nicht implementiert, weil das Tagesgeschäft Vorrang hat.
Ein wirksamer Plan enthält einen verbindlichen Prozess für die Umsetzung von Erkenntnissen. Dazu gehört eine verantwortliche Person, ein Zeitrahmen und eine Nachverfolgung.
Der pragmatische Ansatz
Ein guter Incident Response Plan muss nicht hundert Seiten lang sein. Er muss klar, aktuell und geübt sein. Die wichtigsten Elemente: ein definiertes Severity-Modell, klare Rollen mit Stellvertretern, Kommunikationsvorlagen, Eskalationswege und ein verbindlicher Übungsrhythmus.
Wenn Sie Ihren bestehenden Plan überprüfen oder einen neuen aufbauen möchten, unterstützen wir Sie gerne dabei.
Haeufig gestellte Fragen
Wie lang sollte ein Incident Response Plan sein?
Ein guter Plan muss nicht hundert Seiten lang sein — er muss klar, aktuell und geübt sein. Die Kernelemente: Severity-Modell, Rollen mit Stellvertretern, Kommunikationsvorlagen, Eskalationswege und Übungsrhythmus. Zehn bis zwanzig Seiten reichen für die meisten mittelständischen Unternehmen aus. Was zählt, ist Klarheit, nicht Vollständigkeit.
Was ist eine Tabletop-Übung und wie läuft sie ab?
Eine Tabletop-Übung ist ein simulierter Sicherheitsvorfall, den die beteiligten Teams gemeinsam durchspielen — ohne echten Systemeinsatz, aber mit realen Entscheidungssituationen. Ein Moderator führt durch ein Szenario (z. B. Ransomware-Angriff), und die Teilnehmer diskutieren, welche Maßnahmen sie ergreifen würden. Dabei werden Lücken in Prozessen und Rollenverteilung sichtbar, bevor es ernst wird.
Wer muss bei einem Sicherheitsvorfall zwingend informiert werden?
Das hängt von der Schwere des Vorfalls ab. Intern: IT-Leitung, Geschäftsführung, Datenschutzbeauftragter. Extern: bei personenbezogenen Daten möglicherweise die Datenschutzaufsichtsbehörde (DSGVO), bei NIS2-pflichtigen Unternehmen die zuständige Behörde, sowie Kunden und Partner, wenn deren Daten oder Systeme betroffen sind. Der Plan muss diese Eskalationswege vorab definieren.
Was unterscheidet einen Sicherheitsvorfall von einem Sicherheitsereignis?
Ein Sicherheitsereignis ist jedes beobachtete Ereignis, das sicherheitsrelevant sein könnte — etwa eine fehlgeschlagene Anmeldung oder ein Alarm im SIEM. Ein Sicherheitsvorfall ist ein Ereignis, das tatsächlich negative Auswirkungen hat oder haben kann. Das Severity-Modell legt fest, ab wann ein Ereignis als Vorfall klassifiziert wird und welche Reaktion das auslöst.