Was ein guter Incident-Response-Plan nicht leisten kann

Ein Incident-Response-Plan löst keine Krise. Er beschreibt, wie sie idealerweise ablaufen sollte — und genau darin steckt der Denkfehler, den wir in Beratungsprojekten am häufigsten sehen.

Der Plan ist geschrieben. Die Rollen sind definiert. Die Eskalationswege stehen sauber im Dokument. Bis der Druck da ist.

Wo der Denkfehler beginnt

Plan-Vollständigkeit wird zu oft mit Krisenfähigkeit verwechselt. „Wir haben einen IR-Plan” ist im Vorstandsmeeting beruhigend, im Audit-Bericht pflichterfüllend und in der Risikomatrix abgehakt. Aber ein Dokument auf dem Server ist kein Verhalten unter Druck.

Wir treffen das Muster regelmäßig. Eine Organisation hat in den Plan investiert, externe Beratung dazu eingekauft, vielleicht sogar nach ISO 27001 zertifiziert. Und entdeckt im ersten echten Vorfall, dass sie zwei Eskalationspfade hat: den dokumentierten und den realen.

Was im Ernstfall wirklich passiert

Unter Stress reagieren Menschen anders, als sie glauben. Informationen kommen zu spät, fragmentiert, oder gar nicht. Zuständigkeiten werden unscharf, besonders an den Schnittstellen. IT meldet an Sicherheit, Sicherheit an Geschäftsführung, Geschäftsführung an Kommunikation, alle warten auf Legal. Niemand will die falsche Entscheidung treffen, also fällt sie verspätet.

Die typischen Bruchstellen sind nicht technisch. Sie sind organisatorisch. Wer entscheidet, ob Kunden informiert werden? Wer hat die Befugnis, Systeme abzuschalten? Wer ruft die Cyber-Versicherung an, und wann? Im Plan steht das. In der Realität fragen sich vier Leute gleichzeitig, ob jemand anderes das übernimmt.

Warum nur Übung den Plan testet

Erst in der Übung wird sichtbar, ob Rollen verstanden sind, ob Eskalation funktioniert, ob Führung greift, ob die Organisation handlungsfähig bleibt. Eine Tabletop-Übung von 45 bis 60 Minuten deckt typischerweise drei bis fünf Schwachstellen auf, die jeder schriftliche Review übersehen hätte.

Das ist auch der Grund, warum die NIS2-Risikomanagementmaßnahmen Krisenmanagement und das Testen von Notfallplänen verlangen. In Österreich gilt das über das NISG. Der Gesetzgeber hat verstanden, was wir in der Praxis sehen: Die Schwächen eines Plans liegen nicht im Text, sondern an seinen Berührungspunkten mit echten Menschen unter echtem Stress.

Was wir konkret prüfen

Wenn wir einen IR-Plan im Rahmen eines Security Assessments testen, fragen wir nicht „Steht es im Plan?”. Wir fragen vier andere Dinge.

Sind die Rollen unter Druck wirklich eindeutig? Eine Person muss wissen, dass sie jetzt entscheidet — nicht, dass sie laut Dokumentation entscheiden könnte.

Funktioniert die Kommunikation an den Schnittstellen? IT, Geschäftsführung, Legal, Kommunikation, externe Forensik, Versicherung, Aufsichtsbehörde — wer hört wen, wann, mit welchem Inhalt.

Sind die schwierigen Entscheidungen vorab geklärt? Wer entscheidet über Kundeninformation, Systemabschaltung, Lösegeldfrage. Wer übernimmt, wenn die zuständige Person nicht erreichbar ist.

Sind die externen Kontakte tatsächlich getestet? Eine Cyber-Versicherung hat eine 24/7-Hotline. Hat jemand sie schon einmal angerufen? Den Forensik-Dienstleister? Den Kommunikationsberater? Wenn nein, wird es im Ernstfall zu spät sein, das herauszufinden.

Fazit

Ein Incident-Response-Plan ist notwendig, aber nicht ausreichend. Krisenfähigkeit ist ein Verhalten, kein Dokument. Wer seinen Plan ernst nimmt, übt regelmäßig — und überarbeitet ihn auf Basis der Findings, nicht nach Compliance-Frist. Die ehrliche Frage lautet nicht, ob euer Plan gut formuliert ist, sondern wann ihr ihn das letzte Mal wirklich getestet habt.