Sagen wir es direkt: Die meisten Incident Response Pläne sind Theater. Ein PDF, das irgendwann mal geschrieben wurde, in einem SharePoint-Ordner liegt und das niemand im Ernstfall finden würde, geschweige denn befolgen. Das Dokument existiert, damit man in Audits sagen kann "Ja, haben wir." Nicht, damit es funktioniert.

Harte Aussage? Vielleicht. Aber wir sehen es immer wieder. Unternehmen mit solidem Endpoint-Schutz, regelmässigem Patching, vielleicht sogar Zero Trust. (Wir haben hier darüber geschrieben, warum weniger Tools oft mehr Schutz bedeuten.) Die Prävention sitzt. Was danach kommt, wenn trotzdem etwas passiert, ist ein schwarzes Loch.

Und etwas wird passieren. Das ist keine Panikmache, das ist Statistik.

Warum verwechseln alle Prävention mit Bereitschaft?

Weil Prävention sich gut anfühlt. Jede neue Firewall-Regel, jedes Security-Awareness-Training gibt das Gefühl von Kontrolle. Man tut etwas. Man investiert. Man kann auf Dashboards zeigen.

Incident Response ist das Gegenteil. Es ist die Vorbereitung auf den Moment, in dem all das versagt hat. Das will niemand planen. Das will niemand durchdenken. Das fühlt sich an wie Defätismus.

Ist es aber nicht. Prävention senkt die Wahrscheinlichkeit eines Vorfalls. Incident Response senkt den Schaden. Beides ist nötig. Aber das Verhältnis, das wir in der Praxis sehen, ist grotesk ungleich.

Was steht eigentlich in deinem Plan, und stimmt das noch?

Falls du einen Incident Response Plan hast: Wann hast du ihn zuletzt gelesen? Wir meinen wirklich gelesen, nicht "ich weiss, dass es den gibt."

Ein Plan, der funktioniert, enthält konkrete Eskalationspfade. Nicht "die IT wird informiert", sondern: Wer genau wird angerufen? Auf welcher Nummer? Wer entscheidet, ob Systeme isoliert werden? Wer darf das ohne Rücksprache tun?

Er enthält Rollen mit Namen und Handynummern. Nicht generische Funktionsbezeichnungen. Dein Incident Commander hat letztes Jahr gekündigt? Dann ist dein Plan Altpapier.

Er enthält technische Sofortmassnahmen. Was wird zuerst heruntergefahren? Was bleibt bewusst online, um forensische Spuren zu erhalten? Wo liegen die Backups, und wie lange dauert eine Wiederherstellung realistisch?

Er enthält ein Kommunikationsprotokoll. Wie informierst du die Belegschaft, ohne Panik auszulösen? Wann sprichst du mit Kunden, Partnern, der Presse? In der Schweiz gibt es gesetzliche Meldepflichten, das NCSC muss bei bestimmten Vorfällen informiert werden. Wer in deinem Unternehmen kennt diese Fristen?

Und er enthält eine Dokumentationspflicht. Alles wird protokolliert, weil du hinterher forensisch, rechtlich und regulatorisch nachweisen musst, was wann passiert ist.

Die meisten Pläne, die wir sehen, haben davon vielleicht zwei Punkte halbwegs aktuell.

Sind 72 Stunden wirklich so entscheidend, oder ist das nur Dramatik?

Es ist keine Dramatik. In den ersten 72 Stunden nach einem Vorfall breitet sich der Schaden aktiv aus oder wird eingedämmt. Forensische Spuren sind noch frisch. Rechtliche Meldefristen beginnen zu laufen. Das Vertrauen deiner Kunden wird geformt.

Wir haben Unternehmen erlebt, die einen Ransomware-Angriff in 48 Stunden unter Kontrolle hatten. Der Plan existierte, er war geübt worden, die Kommunikation funktionierte. Und wir haben Unternehmen erlebt, bei denen der Betrieb wochenlang stillstand. Nicht wegen der Komplexität des Angriffs. Wegen der Komplexität der internen Entscheidungswege.

Wer im Ernstfall erst herausfinden muss, wer eigentlich entscheiden darf, verliert Stunden, die er nicht hat. In unserem Artikel zu Krisenentscheidungen in 15 Minuten gehen wir tiefer auf dieses Problem ein.

Wenn der Plan nie getestet wurde, hast du keinen Plan

Das ist der unbequemste Punkt. Ein ungetesteter Incident Response Plan ist kaum besser als gar keiner.

Die Handynummer des externen Forensik-Dienstleisters? Veraltet. Das Backup-System wurde migriert, aber der Plan nicht aktualisiert. Die Kommunikationsvorlage für Kunden ist juristisch heikel formuliert. All das findest du erst heraus, wenn du testest. Und der falsche Zeitpunkt zum Testen ist der Moment, in dem ein echter Vorfall läuft.

Was stattdessen hilft: Tabletop-Übungen. Strukturierte Simulationen, bei denen das relevante Team ein Szenario durchspielt. Kein Code, keine echten Systeme, aber echte Entscheidungen und echte Diskussionen. "Wir stellen uns vor, heute Morgen haben wir folgende Meldung bekommen. Was machen wir als nächstes?"

Diese Übungen kosten ein paar Stunden. Die Erkenntnisse sind fast immer überraschend. Ja, es ist unbequem, Lücken zu finden. Aber lieber unbequem im Konferenzraum als im Ernstfall.

Ein Incident Response Plan ersetzt übrigens kein technisches Monitoring und keine Grundhygiene bei Backups und Patching. Was er ersetzt: Improvisation unter Druck. Und das ist eine Menge wert. Wer den Gedanken weiterführen will, findet in unserem Artikel über Business Continuity-Pläne mehr dazu, warum auch BCP und Incident Response zusammen gedacht werden müssen.

Die ehrliche Frage

Wenn jetzt, in diesem Moment, ein Sicherheitsvorfall gemeldet wird: Weisst du, wer anruft, wer entscheidet und was in den nächsten 60 Minuten passiert? Wenn die Antwort nicht sofort kommt, ist das kein Grund zur Panik. Es ist ein Grund, diese Woche noch einen Termin einzustellen und genau das zu klären.

Wenn du nicht sicher bist, wo du anfangen sollst, ist das genau die Art von Gespräch, bei der wir helfen. Kein Verkaufsgespräch. Eine ehrliche Einschätzung, wo ihr steht und was sinnvoll wäre. Nimm gerne Kontakt auf.