Krisenplan testen: die Übung, die den Plan erst gültig macht
Ende März 2026 traf ein Cyberangriff den Aschaffenburger Textilveredler ZEGO. Die Produktion stand knapp sechs Wochen still. Im Juli meldete das Unternehmen mit rund 60 Beschäftigten Insolvenz an — nicht wegen des Datenabflusses, sondern wegen des Stillstands. Ein Krisenplan lag vermutlich in irgendeiner Form vor. Entscheidend war etwas anderes: ob er unter Druck funktioniert hat.
Die kurze Antwort: Einen Krisenplan testen heißt nicht, ihn zu lesen, zu prüfen oder freizugeben. Es heißt, die im Plan beschriebenen Annahmen unter realistischem Zeitdruck gegen ein Szenario laufen zu lassen — mit den Menschen, die im Ernstfall tatsächlich entscheiden müssen. Erst diese Übung macht aus einem Dokument eine belastbare Aussage über Ihre Handlungsfähigkeit. Alles davor ist eine Hypothese.
Warum ein ungeprüfter Krisenplan nur ein Dokument ist
Ein Krisenplan ist eine Sammlung von Annahmen: dass die hinterlegten Telefonnummern stimmen, dass der Krisenstab binnen 60 Minuten arbeitsfähig ist, dass jemand befugt ist, die Produktion abzuschalten, dass die Wiederanlaufzeit von acht Stunden realistisch ist. Jede dieser Annahmen ist im Dokument eine Behauptung. Keine davon ist bewiesen.
Eine Studie der Freien Universität Berlin und der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg vom Mai 2026, die auf einer Befragung von 1.224 Unternehmen in Deutschland zwischen März 2025 und Januar 2026 beruht, zeigt das Muster deutlich: Fast jedes zweite Unternehmen war in den vergangenen fünf Jahren von IT-Ausfällen oder Lieferkettenstörungen betroffen. 91 Prozent haben Maßnahmen zur IT-Sicherheit umgesetzt. Aber die Vorsorge bleibt reaktiv — Unternehmen reagieren auf bereits erlebte Krisen und handeln zu selten vorausschauend. Für militärische oder hybride Krisenlagen verfügen laut Studie nur rund zehn Prozent der Unternehmen über entsprechende Notfallpläne, selbst in systemrelevanten Branchen wie IT, Energie oder Gesundheitswesen.
Die Lücke liegt also selten beim Schreiben. Sie liegt zwischen dem geschriebenen Plan und der geübten Fähigkeit. Wer seinen Krisenplan testen will, muss genau diese Lücke sichtbar machen — und zwar bevor sie ein Angreifer, ein Ausfall oder ein Sturm für ihn sichtbar macht.
Krisenplan testen: Übung, Test und Review sind nicht dasselbe
Drei Begriffe werden in der Praxis vermischt, obwohl sie sehr Unterschiedliches beweisen. Wer sie sauber trennt, weiß hinterher, was er tatsächlich validiert hat.
Plan-Review: prüft Vollständigkeit
Ein Review liest den Plan gegen eine Checkliste: Sind alle Rollen besetzt, alle Prozesse abgedeckt, alle Kontaktdaten gepflegt? Das ist notwendige Hygiene und deckt veraltete Angaben auf. Es sagt nichts darüber aus, ob der Plan unter Druck trägt.
Test: prüft einzelne technische Annahmen
Ein Test isoliert eine Komponente und misst sie. Läuft die Rückspielung des Backups tatsächlich in vier Stunden? Erreicht die Alarmierungskette in zwölf Minuten 90 Prozent der Empfänger? Springt das Notstromaggregat an? Tests liefern harte Zahlen — aber nur zu dem, was gemessen wurde.
Übung: prüft Zusammenspiel und Entscheidung
Eine Übung setzt Menschen unter Zeitdruck vor unvollständige Informationen und lässt sie entscheiden. Sie prüft das, was kein Review und kein Test erfassen kann: Eskalation, Priorisierung bei Zielkonflikten, Kommunikation zwischen Krisenstab, Fachbereichen und Externen. Genau hier scheitern Krisen — nicht an fehlenden Dokumenten, sondern an unklaren Zuständigkeiten und zögerlicher Eskalation.
Ein vollständiges Übungsprogramm braucht alle drei. Wer nur Reviews fährt, hat einen gepflegten Plan ohne Nachweis. Wer nur technisch testet, hat belastbare Wiederanlaufzeiten und einen führungslosen Krisenstab.
ISO 22301 als methodischer Rahmen
Der internationale Standard für Business Continuity Management, ISO 22301, macht aus dem Üben keine Kür, sondern einen festen Bestandteil des Managementsystems. Der Standard verlangt ein Übungs- und Testprogramm, das die Kontinuitätsstrategien und -pläne in geplanten Abständen validiert, dazu eine dokumentierte Auswertung nach jeder Übung und eine Bewertung, ob die Fähigkeiten und die Dokumentation weiterhin angemessen sind.
Der methodische Kern ist dabei wichtiger als die Zertifizierungsfrage: ISO 22301 zwingt dazu, vor der Übung festzulegen, was validiert werden soll, und nach der Übung festzuhalten, was tatsächlich validiert wurde. Diese beiden Sätze verwandeln eine gut gemeinte Simulation in einen prüffähigen Nachweis. Wer den Rahmen systematisch aufbauen will, findet in unserem ISO 22301 Training die passende Grundlage.
Die vier Übungsformate — vom Schreibtisch bis zur Vollübung
Nicht jede Übung muss groß sein. Der Aufwand sollte zum Prüfziel passen, nicht zum Budget.
1. Plan-Walkthrough (2–3 Stunden)
Der Krisenstab geht den Plan Schritt für Schritt gegen ein Szenario durch, ohne Zeitdruck. Ziel: Verständnis, Rollenklarheit, Auffinden offensichtlicher Lücken. Ideal für neue Teams oder nach einer Planüberarbeitung.
2. Tabletop-Übung (halber Tag)
Ein moderiertes Szenario mit Einspielungen, das die Entscheidungslogik unter Zeitdruck prüft — diskutierend, nicht handelnd. Das beste Verhältnis von Aufwand zu Erkenntnis und der übliche Einstieg für die Geschäftsleitung.
3. Funktionale Übung (1 Tag)
Einzelne Funktionen handeln real: Die Alarmierung wird ausgelöst, der Krisenstabsraum wird aktiviert, die Pressestelle formuliert ein echtes Holding Statement, die IT spielt ein Backup zurück. Hier fallen die messbaren Kennzahlen an.
4. Vollübung (1–2 Tage)
Das gesamte Szenario läuft über mehrere Ebenen und Standorte, oft mit externen Beteiligten. Hoher Aufwand, hoher Erkenntniswert — sinnvoll erst, wenn die kleineren Formate sitzen.
Eine praxistaugliche Staffel: pro Jahr mindestens eine Tabletop-Übung für die Geschäftsleitung, zwei funktionale Übungen für kritische Prozesse und alle zwei bis drei Jahre eine Vollübung. Wie sich diese Formate konkret aufsetzen lassen, zeigen unsere Krisensimulationen inhouse.
Sechs Bruchstellen, die eine Übung zuverlässig freilegt
- Alarmierung. Die Kette funktioniert im Test — aber niemand weiß, wer sie auslösen darf, wenn der Vorfall um 3:40 Uhr beginnt.
- Entscheidungsbefugnis. Der Plan nennt Rollen, keine Schwellen. Ab welchem Schaden darf die Produktion ohne Vorstandsbeschluss abgeschaltet werden?
- Informationsstand. Der Krisenstab wartet auf Vollständigkeit, statt auf Basis von 60 Prozent Information zu entscheiden.
- Wiederanlaufzeiten. Die im Plan hinterlegte RTO stammt aus einer Business Impact Analyse, die nie gegen die reale Systemlandschaft geprüft wurde.
- Kommunikation. Kunden, Aufsicht, Belegschaft und Presse werden nacheinander bedient statt parallel — die Deutungshoheit ist nach zwei Stunden verloren.
- Abhängigkeiten Dritter. Der Plan setzt auf einen IT-Dienstleister, dessen Reaktionszeiten vertraglich nie zugesichert wurden.
Keine dieser Bruchstellen findet ein Review. Alle sechs findet eine gut gebaute Übung an einem Vormittag.
Regulatorischer Rückenwind: was NIS2 tatsächlich verlangt
Das NIS2-Umsetzungsgesetz gilt in Deutschland seit Dezember 2025. § 30 BSIG verpflichtet betroffene Einrichtungen auf zehn Risikomanagementmaßnahmen. Zwei davon sind für diese Frage zentral: die Bewältigung von Sicherheitsvorfällen sowie Konzepte zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen.
Wichtig ist die genaue Lesart: Das Gesetz schreibt keine bestimmte Übungsform und keine feste Frequenz vor. Es verlangt jedoch, dass die Wirksamkeit der Maßnahmen bewertet wird — und ein geübter, ausgewerteter und nachgeschärfter Krisenplan ist der praktikabelste Weg, diese Wirksamkeit zu belegen. Ob und in welchem Umfang Ihre Organisation überhaupt in den Anwendungsbereich fällt, hängt von Sektor und Größe ab und sollte im Einzelfall geprüft werden. Wir haben die Pflichtfrage in einem eigenen Beitrag ausführlich behandelt: Ist eine Krisenübung unter NIS2 verpflichtend?
Der Ablauf: drei Phasen, von denen eine regelmäßig ausfällt
Vorbereitung. Prüfziele festlegen (maximal drei), Szenario aus dem eigenen Risikoprofil ableiten, Einspielungen mit Zeitachse bauen, Beobachterrollen besetzen. Faustregel: ein Tag Vorbereitung pro Stunde Übung.
Durchführung. Die Übungsleitung spielt ein, greift aber nicht in Entscheidungen ein. Beobachter protokollieren gegen die Prüfziele, nicht gegen ihr Bauchgefühl. Kein Debattieren über Szenariorealismus während des Laufs.
Auswertung. Das ist die Phase, die im Alltag verschwindet — und die einzige, die Wirkung erzeugt. Ein Hot Debrief unmittelbar nach der Übung sichert die frischen Eindrücke, ein strukturierter Bericht binnen zwei Wochen ordnet Beobachtungen den Prüfzielen zu und formuliert Maßnahmen mit Verantwortlichem und Termin. Ohne diesen Schritt haben Sie ein Erlebnis produziert, keinen Fortschritt.
Wie oft sollten Sie Ihren Krisenplan testen?
Es gibt keine gesetzlich festgeschriebene Zahl. Eine belastbare Praxis orientiert sich an drei Auslösern statt an einem Kalenderdatum: mindestens jährlich für die Kernszenarien; zusätzlich immer nach wesentlichen Änderungen — neue Systemlandschaft, Fusion, neuer Standort, Wechsel in der Geschäftsleitung; und immer nach einem realen Vorfall, weil dann die Bereitschaft zur Veränderung am größten ist.
Häufige Fragen
Was ist der Unterschied zwischen einem Test und einer Übung?
Ein Test misst eine einzelne technische Annahme mit einem klaren Soll-Wert, etwa die Wiederherstellungszeit eines Systems. Eine Übung prüft das Zusammenspiel von Menschen, Rollen und Entscheidungen unter Zeitdruck. Beides ist nötig; nur zusammen ergeben sie ein Bild der tatsächlichen Handlungsfähigkeit.
Muss die Geschäftsleitung an der Übung teilnehmen?
Bei allem, was Eskalationsschwellen, Produktionsstopps, Kommunikation nach außen oder finanzielle Zusagen betrifft: ja. Wird ohne die tatsächlichen Entscheider geübt, testen Sie den Plan an genau der Stelle nicht, an der er im Ernstfall am stärksten belastet wird.
Was, wenn die Übung schlecht läuft?
Dann hat sie ihren Zweck erfüllt. Eine Übung, die reibungslos verläuft, war entweder zu einfach gebaut oder zu weit im Voraus angekündigt. Der Erkenntniswert liegt in den Reibungen — nicht im guten Gefühl danach.
Reicht eine Tabletop-Übung als Nachweis?
Für die Entscheidungs- und Kommunikationsebene ist sie ein sehr guter Nachweis. Technische Wiederanlaufzeiten kann sie nicht belegen; dafür braucht es funktionale Tests. Ein Prüfer oder Auditor wird beides sehen wollen.
Lehren für Ihre Krisenorganisation
Der Fall ZEGO ist deshalb so unbequem, weil er nichts Exotisches enthält. Ein mittelständischer Betrieb, ein Angriff, ein Stillstand von sechs Wochen — und am Ende die Erkenntnis, dass die Dauer des Ausfalls, nicht der Angriff selbst, existenzbedrohend war. Genau diese Dauer ist die Größe, die eine Übung beeinflussen kann: Wer die Wiederanlaufreihenfolge einmal unter Druck durchgespielt hat, verliert die ersten 48 Stunden nicht mit Klärungsfragen.
Drei Schritte, mit denen Sie diese Woche beginnen können:
- Schlagen Sie Ihren Krisenplan auf und markieren Sie jede Zahl darin — Zeiten, Schwellen, Kapazitäten. Jede Markierung ist eine ungeprüfte Behauptung, bis sie geübt oder getestet wurde.
- Setzen Sie eine Tabletop-Übung von drei Stunden an, mit maximal drei Prüfzielen und den tatsächlichen Entscheidern im Raum.
- Legen Sie vor der Übung fest, wer den Auswertungsbericht schreibt und wann die Maßnahmen nachgehalten werden. Ohne diesen Termin verpufft die Wirkung.
Ein Krisenplan, der nie geübt wurde, ist kein Krisenplan. Er ist ein Vorschlag. Wenn Sie wissen wollen, wie belastbar Ihre Krisenorganisation unter Druck tatsächlich ist, ist die Krisensimulation inhouse der direkteste Weg dorthin — und wenn der Plan selbst noch nicht steht, beginnen Sie mit unserem Leitfaden Krisenplan erstellen: Schritt für Schritt.
Quellen
- Freie Universität Berlin / Helmut-Schmidt-Universität: Krisenresilienz deutscher Unternehmen (Pressemitteilung Nr. 055/2026, 06.05.2026)
- Security-Insider: Cyberangriff — Textilveredler Zego stellt Insolvenzantrag
- BSI: NIS-2-Risikomanagementmaßnahmen nach § 30 BSIG
- BSI: Die Lage der IT-Sicherheit in Deutschland 2025
- ISO 22301:2019 — Security and resilience, Business continuity management systems





