Bildquelle: Pexels / Vladimír Sládek / https://www.pexels.com/photo/modern-telephone-on-a-desk-in-office-10059345/
Wer Ausfälle nur technisch übt, entdeckt Entscheidungs- und Kommunikationslücken erst im Ernstfall
Viele Unternehmen testen ihre Betriebsfähigkeit noch immer zu schmal. Ein Restore wird angestoßen, ein Failover dokumentiert, ein Monitoring-Alarm quittiert – und danach gilt die Übung als Erfolg. Für den realen Ausfallbetrieb reicht das nicht. Denn in größeren Störungen entscheidet selten nur die Technik darüber, wie teuer, lang oder reputationsschädlich ein Vorfall wird. Entscheidend ist, ob Incident Response, Fachverantwortung, Kommunikation, Dienstleistersteuerung und Management in derselben Lage denselben Takt halten. Wer nur den technischen Teil probt, entdeckt die organisatorischen Bruchstellen oft erst dann, wenn Kundschaft, Vorstand oder Aufsicht bereits Antworten verlangen.
Genau diese Lücke beschreiben etablierte Resilienzleitlinien schon seit Jahren recht deutlich. NIST SP 800-84 ordnet Test-, Trainings- und Übungsprogramme ausdrücklich den IT-Plänen und Fähigkeiten zu – nicht nur der Infrastruktur. NIST SP 800-34 verknüpft Incident Response, Contingency Planning, Disaster Recovery und Resilienz ausdrücklich miteinander. Und DORA verlangt in Artikel 24 für Finanzunternehmen ein belastbares Testprogramm, das Schwächen und Lücken identifiziert und Korrekturmaßnahmen zügig umsetzt. Übersetzt in die Praxis heißt das: Eine gute Übung misst nicht nur, ob Systeme zurückkommen, sondern ob die Organisation unter Druck entscheidungsfähig bleibt.
Technische Recovery ohne Führungsweg misst nur die halbe Realität
In vielen Übungen ist der Ablauf stillschweigend bereits geklärt: Das Technikteam kennt das Szenario, die Eskalation bleibt klein, Freigaben sind informell vorbereitet, und externe Kommunikation spielt höchstens als Randnotiz mit. So lässt sich zwar ein Runbook testen, aber kaum die wirkliche Belastbarkeit des Betriebsmodells. Im echten Vorfall kommen zusätzliche Fragen dazu: Wer priorisiert zwischen Wiederanlauf und Beweissicherung? Wer darf ein riskantes Workaround freigeben? Wer entscheidet über das Abschalten eines Kundenkanals? Wann wird der Cloud- oder Security-Dienstleister formell eingebunden? Wer informiert Fachbereiche, Kundenservice, Datenschutz oder Presse?
Gerade diese Entscheidungen kosten im Ernstfall oft mehr Zeit als der technische Fix selbst. Ein Team kann ein Datenbank-Backup erfolgreich zurückspielen und trotzdem operativ scheitern, wenn unklar bleibt, welche Datenkonsistenz als ausreichend gilt, ob Buchungen nachgezogen werden müssen oder ob ein Service vorläufig im Lesemodus weiterlaufen darf. NIST SP 800-34 ist deshalb so hilfreich, weil die Publikation Resilienz nicht als isolierte Recovery-Aufgabe beschreibt, sondern im Zusammenhang mit Incident Response, Notfallplanung und Wiederherstellung. Wer diese Disziplinen getrennt übt, trainiert zwar Teilkompetenzen, aber nicht die reale Schnittstelle zwischen ihnen.
Entscheidungsrechte sind im Ausfall oft der eigentliche Engpass
Ausfälle eskalieren selten nur wegen fehlender Technik. Sie eskalieren, weil in kritischen Minuten niemand sicher sagen kann, wer den nächsten Schritt freigibt. Darf das Infrastrukturteam einen Standort isolieren? Darf das Produktteam Features abschalten, die Umsatz kosten? Darf der Service Desk eine Störung offen bestätigen, wenn die Ursache noch unklar ist? Darf der Provider ein Failover durchführen, das Nebenwirkungen auf Reporting oder Compliance-Nachweise hat?
Solche Fragen lassen sich nicht sauber in PowerPoint lösen. Sie müssen in Übungen unter Zeitdruck sichtbar gemacht werden. Erst dann zeigt sich, ob die Verantwortungslogik wirklich trägt oder nur auf Organigrammen existiert. DORA formuliert diesen Gedanken überraschend klar: Das Testprogramm soll der Vorbereitung auf ICT-bezogene Vorfälle dienen, Schwächen und Lücken erkennen und Korrekturmaßnahmen rasch anstoßen. Außerdem verlangt die Verordnung unabhängige Tests, risikobasiertes Vorgehen und Verfahren, um festgestellte Probleme zu priorisieren, zu klassifizieren und zu beheben. Das ist mehr als ein Techniktest. Es ist ein Managementtest für digitale Betriebsfähigkeit.
Auch außerhalb regulierter Branchen ist das ein sinnvoller Maßstab. Denn die teuersten Störungen entstehen häufig dort, wo technische und fachliche Entscheidungsketten auseinanderlaufen: Das Betriebsteam wartet auf eine Geschäftsentscheidung, das Management wartet auf belastbare Technikdaten, der Kommunikationskanal wartet auf einen freigegebenen Text, und der Provider wartet auf eine formelle Anweisung. Die Übung wirkt erst dann realistisch, wenn genau diese Abhängigkeiten mitgespielt werden.
Kommunikation darf nicht als Dekoration nebenherlaufen
Viele Tabletop-Formate behandeln Kommunikation noch immer wie einen nachgelagerten Anhang. Dabei ist sie im Ernstfall Teil des Betriebssystems. Interne Lagebilder, Statusmeldungen an Führungskräfte, Aussagen gegenüber Kunden, Abstimmungen mit Partnern und Hinweise an den Service Desk beeinflussen direkt, wie stabil eine Organisation durch den Vorfall kommt. Wenn Kommunikationswege nicht geübt sind, entsteht fast immer dieselbe Dynamik: Das Technikteam liefert unvollständige Fragmente, mehrere Stellen formulieren parallel, und der Kundenkontakt erfährt die Lage zu spät oder widersprüchlich.
Genau hier lohnt es sich, Übungen breiter aufzubauen. Nicht jede Notfallübung muss eine Vollsimulation mit großem Aufwand sein. Aber selbst eine kompakte Tabletop-Runde sollte mindestens folgende Kommunikationsfragen enthalten: Wer erstellt das erste Lagebild? Nach welchem Takt werden Updates erwartet? Welche Aussagen sind freigegeben, welche bewusst noch nicht? Wer synchronisiert Statusseite, Service Desk und Management-Update? Und welche externe Stelle – vom Dienstleister bis zur Aufsicht – muss in welchem Auslösemoment eingebunden werden?
Wenn diese Fragen fehlen, wird in der Übung oft nur die technische Diagnose trainiert. Der reale Schaden entsteht dann später in der Wahrnehmung des Vorfalls: Support bekommt keine sprechfähigen Informationen, Führungskräfte eskalieren ungeordnet nach oben, Kunden erleben Schweigen oder Widersprüche, und Teams verlieren Zeit mit dem Nachschärfen von Botschaften statt mit Wiederanlauf und Priorisierung.
Eine Übung ist erst nützlich, wenn aus Befunden verbindliche Maßnahmen werden
NIST SP 800-84 ist in diesem Punkt besonders wertvoll, weil der Fokus nicht auf dem einen Test, sondern auf dem Programm liegt. Das ist der wichtige Unterschied. Einzelübungen erzeugen Erkenntnisse. Ein Übungsprogramm sorgt dafür, dass diese Erkenntnisse systematisch gesammelt, ausgewertet und in Folgearbeit überführt werden. Sonst produziert jede Organisation irgendwann dasselbe Ritual: Man simuliert einen Ausfall, identifiziert bekannte Schwächen, nickt sie im Debrief ab – und sechs Monate später tauchen dieselben Themen wieder auf.
Ein belastbarer Ablauf braucht deshalb nach jeder Übung mindestens drei Ergebnisse: erstens eine priorisierte Liste der festgestellten Lücken, zweitens einen eindeutigen Owner pro Maßnahme und drittens einen Termin oder Kontrollpunkt, an dem die Korrektur überprüft wird. DORA fordert genau diese Richtung mit Prozessen zur Priorisierung, Klassifizierung und Behebung der entdeckten Probleme. Für den Alltag heißt das: Eine Kommunikationslücke ohne Maßnahmenowner ist kein Lernfortschritt. Ein unklarer Eskalationsweg ohne Termin zur Korrektur ist nur dokumentierte Unsicherheit.
Wie ein pragmatisches Übungsmodell im IT-Betrieb aussehen kann
Organisationen müssen dafür nicht sofort ein komplexes Krisenprogramm aufsetzen. Praktischer ist ein gestuftes Modell. Erstens sollten kritische Services und ihre Abhängigkeiten sauber benannt werden: Technik, Fachverantwortung, externe Provider, Kommunikationskanäle und Freigabepunkte. Zweitens lohnt sich ein einfacher Szenariokatalog, zum Beispiel Ransomware-Ausfall, Identitätsstörung, Cloud-Region-Problem, Datenkorruption oder Drittanbieterunterbrechung. Drittens sollte jedes Szenario nicht nur technische Schritte, sondern auch Entscheidungs- und Kommunikationspunkte enthalten.
Danach kann der Rhythmus unterschiedlich aussehen: kurze Tabletop-Sessions für Rollenklärung, gezielte Techniktests für Restore oder Failover, und in größeren Abständen breitere Übungen mit Fachseite, Kommunikation und Management. Wichtig ist nicht maximale Theatralik, sondern ein wiederholbarer Lerneffekt. Ein guter Test fragt daher nicht nur: „Kam das System zurück?“ Er fragt auch: „Wussten alle Beteiligten, wer entscheidet?“, „Waren die Statusmeldungen konsistent?“, „Konnten Abhängigkeiten zum Provider sauber aktiviert werden?“ und „Sind die offenen Punkte wirklich im Maßnahmenportfolio gelandet?“
Genau dann wird aus Notfallübung eine Betriebsdisziplin. Die Organisation trainiert nicht bloß Wiederanlauftechnik, sondern ihre Fähigkeit, unter Unsicherheit koordiniert zu handeln. Und genau das trennt auf Dauer robuste Resilienz von beruhigender Übungsfolklore.
Fazit
Wer Ausfälle nur technisch übt, erhält ein zu optimistisches Bild der eigenen Resilienz. Wirklich belastbar wird der IT-Betrieb erst, wenn Übungen auch Entscheidungsrechte, Kommunikationswege, Provider-Schnittstellen und die verbindliche Nachverfolgung von Befunden einbeziehen. NIST und DORA zeigen in unterschiedlichen Kontexten dieselbe Richtung: Resilienztests sollen Vorbereitung prüfen, Schwächen sichtbar machen und Korrekturen auslösen. Für den praktischen Betrieb bedeutet das, Übungen nicht als isolierten Techniktermin zu behandeln, sondern als Probe des gesamten Führungs- und Koordinationssystems rund um kritische Services.
