Der Plan, der nie getestet wurde
Alle haben einen Incident-Response-Plan. Er liegt in einem geteilten Dokument irgendwo, vielleicht zuletzt bei der Revision des vergangenen Jahres aktualisiert. Er enthält Flussdiagramme, Rollenbeschreibungen und Kontaktlisten. Auf dem Papier sieht er vollständig aus.
Dann passiert etwas. Um 03:14 Uhr an einem Freitagabend löst das Überwachungssystem einen Alarm aus. Ransomware breitet sich durch das Netzwerk aus. Und plötzlich steht die Organisation vor Fragen, die der Plan nie beantwortet hat: Wer entscheidet über das Herunterfahren der Produktionssysteme? Wer ruft den Vorstandsvorsitzenden an? Wer spricht mit den Medien? Wo sind die Offsite-Backups — und funktionieren sie?
Die Realität: Organisationen mit einem getesteten und geübten Incident-Plan sparen durchschnittlich 2,7 Millionen EUR pro Incident im Vergleich zu denen, die nicht üben. Der Unterschied liegt nicht daran, einen Plan zu haben — es geht darum, dass der Plan unter Druck funktioniert.
Vier Säulen einer funktionierenden Bereitschaft
Ein effektiver Incident-Response-Plan geht nicht darum, ein perfektes Dokument zu haben. Es geht darum, dass alle Beteiligten wissen, was sie tun müssen, ohne das Dokument während einer laufenden Krise lesen zu müssen.
Wer wird bei welcher Art von Incident kontaktiert? Wer entscheidet über die Eskalation von einem IT-Incident zu einer Geschäftskrise? Definieren Sie klare Schwellenwerte: bei X wird der CISO kontaktiert, bei Y der CEO, bei Z wird das Krisenteam aktiviert. Keine vagen Formulierungen — konkrete Namen und Nummern.
Incident-Leiter, technischer Verantwortlicher, Kommunikationsverantwortlicher, rechtlicher Kontakt, externer Kontakt zu Behörden. Jede Rolle benötigt eine primäre Person und eine Vertretung. Rollen sollten basierend auf Kompetenz und Verfügbarkeit vergeben werden — nicht auf organisatorischer Position.
Während einer Krise gibt es keine Zeit, Nachrichten von Grund auf zu schreiben. Bereiten Sie Vorlagen für interne Kommunikation an Mitarbeiter, externe Kommunikation an Kunden, Behördenmeldungen an BSI/CSIRT und Medienstatements vor. Passen Sie die Details während des Ereignisses an — nicht die Struktur.
Wie isolieren Sie betroffene Systeme schnell, ohne das gesamte Geschäft lahmzulegen? Welche Netzwerksegmente können abgeschaltet werden? Wo sind Kill-Switches? Haben Sie Segmentierungsstrategien vorbereitet, die manuell aktiviert werden können, wenn die Automatisierung nicht funktioniert?
Übung: Der Schritt, den alle auslassen
Die meisten Organisationen bleiben bei der Dokumentation stehen. Der Plan wird geschrieben, von der Geschäftsleitung genehmigt und archiviert. Übung? “Dafür ist keine Zeit.” “Es ist zu kompliziert zu organisieren.” “Wir wissen trotzdem, was zu tun ist.”
Nein, das tun Sie nicht. Nicht unter Stress, nicht mitten in der Nacht, nicht wenn die Systeme brennen und das Telefon ununterbrochen klingelt.
Tabletop-Übungen: Hier anfangen
Eine Tabletop-Übung erfordert keine Technik. Versammeln Sie das Team, präsentieren Sie ein Szenario und diskutieren Sie Schritt für Schritt: Was machen wir zuerst? Wen kontaktieren wir? Welche Informationen brauchen wir? Wo finden wir sie?
Beispiel eines Tabletop-Szenarios:
Es ist Freitag, 16:30 Uhr. Ein Mitarbeiter meldet, dass er nicht auf den Dateiserver zugreifen kann. Die IT untersucht und findet verschlüsselte Dateien mit einer Lösegeldforderung. Die Verschlüsselung breitet sich aktiv aus. Sie haben 24 Stunden Zeit, um an das BSI zu melden.
Diskutieren Sie:
- Welche Entscheidungen werden in den ersten 15 Minuten getroffen?
- Wer wird informiert und in welcher Reihenfolge?
- Wie kommunizieren Sie intern, wenn das E-Mail-System betroffen ist?
- Welche Systeme können Sie herunterfahren, und welche müssen weiterlaufen?
- Wer schreibt die Meldung an das BSI — und was soll sie enthalten?
Tabletop-Übungen decken Lücken auf, die keine Dokumentenanalyse finden kann: dass die Kontaktliste veraltet ist, dass der Backup-Verantwortliche vor drei Monaten gekündigt hat, dass niemand weiß, wer das Root-Passwort für den Produktionsserver hat.
Vollumfängliche Übungen: Nächste Stufe
Wenn Tabletop-Übungen gut funktionieren, erweitern Sie zu vollumfänglichen Simulationen, bei denen Sie tatsächlich Ihre Prozesse aktivieren. Das testet nicht nur die Entscheidungsfindung, sondern auch die technische Kapazität: Funktioniert die Backup-Wiederherstellung? Halten die Kommunikationskanäle der Belastung stand? Können Sie wirklich Netzwerksegmente wie geplant isolieren?
Häufige Fehler in der Incident-Bereitschaft
- Der Plan ist zu kompliziert Ein 50-seitiger Incident-Response-Plan, den niemand vollständig gelesen hat, wird während einer Krise nicht verwendet werden. Machen Sie ihn kurz, konkret und handlungsorientiert. Detaillierte Verfahren können als Anhänge existieren — aber der Kernplan sollte auf zwei Seiten passen.
- Unklare Mandate Wenn der Incident-Leiter nicht das Mandat hat, kritische Entscheidungen zu treffen — Systeme herunterfahren, zum CEO eskalieren, externe Hilfe einbeziehen — wird die Entscheidungsfindung blockiert. Die Mandate sollten dokumentiert und von der Geschäftsleitung im Voraus genehmigt sein.
- Kein Plan B für Kommunikation Wenn E-Mail, Teams und das interne Netzwerk vom Incident betroffen sind — wie kommunizieren Sie? Bereiten Sie alternative Kommunikationskanäle vor: Mobiltelefone mit vorgeladenen Kontaktlisten, einen externen Chat-Service oder sogar physische Treffpunkte.
- Nie geübte Behördenmeldung Die 24-Stunden-Frist nach NIS2UmsuCG beginnt bei der Entdeckung zu laufen. Haben Sie Formulare vorbereitet? Weiß der Meldebeauftragte, welche Informationen das BSI in der frühen Warnung benötigt? Üben Sie auch den administrativen Teil.
Die Verbindung zu den Meldepflichten des NIS2UmsuCG
Incident-Bereitschaft und Incident-Meldung hängen zusammen, sind aber nicht dasselbe. Die Bereitschaft geht darum, den Incident operativ zu bewältigen. Die Meldung geht darum, die gesetzlichen Anforderungen gegenüber Behörden zu erfüllen.
Sie schaffen es nicht, den Meldeprozess während des laufenden Incidents aufzubauen. Vorlagen, Kontaktdaten zum BSI/CSIRT und ein benannter Meldebeauftragter sollten vor dem Incident vorhanden sein. Siehe unseren Leitfaden zur Incident-Meldungs-Timeline für die genauen Zeitanforderungen.
Mit dem Wichtigsten anfangen
Sie brauchen keinen perfekten Plan. Sie brauchen einen Plan, der funktioniert. Beginnen Sie mit einer Tabletop-Übung basierend auf Ihrem wahrscheinlichsten Szenario. Das deckt Ihre wichtigsten Lücken auf und gibt Ihnen konkrete Verbesserungsmaßnahmen.
Securapilots Incident-Response-Modul hilft Ihnen dabei, Ihre Incident-Bereitschaft zu dokumentieren, zu üben und nachzuverfolgen — mit fertigen Vorlagen, die an die Meldepflichten des NIS2UmsuCG angepasst sind.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Incident-Response und Incident-Meldung?
Incident-Response ist der gesamte Prozess — Erkennen, Analysieren, Eindämmen, Beheben und Lernen aus einem Incident. Incident-Meldung ist die spezifische Verpflichtung, Behörden (BSI/CSIRT) innerhalb der vom NIS2UmsuCG vorgegebenen Fristen zu benachrichtigen.
Wie oft sollten Incident-Übungen durchgeführt werden?
Tabletop-Übungen sollten mindestens halbjährlich durchgeführt werden. Vollumfängliche Übungen mindestens jährlich. Jede Übung sollte von einer Auswertung und Aktualisierung des Plans basierend auf den Erkenntnissen gefolgt werden.
Was ist eine Tabletop-Übung?
Eine Tabletop-Übung ist eine diskussionsbasierte Übung, bei der das Team ein fiktives Incident-Szenario Schritt für Schritt durchgeht. Keine Technik muss aktiviert werden — der Fokus liegt auf dem Testen von Entscheidungsfindung, Kommunikation und Zusammenarbeit.
Benötigen wir ein SOC für Incident-Response?
Nicht zwangsläufig. Das Wichtigste ist, dass Sie definierte Rollen, dokumentierte Prozesse und geübte Abläufe haben. Wie Sie die Kapazität organisieren — intern, ausgelagert oder hybrid — hängt von Ihrer Größe und Reife ab.
