Operational Resilience unter DORA: Warum Incident-Prozesse oft zu langsam sind

Operational Resilience unter DORA: Warum Incident-Prozesse oft zu langsam sind

Operational Resilience klingt wie ein großes Programm. In der Praxis entscheidet sich aber sehr vieles an einer erstaunlich einfachen Frage: Wie schnell wird aus einem technischen Problem eine klare Entscheidung – und wie schnell wird aus dieser Entscheidung ein koordinierter Ablauf? Genau an dieser Stelle sind Incident-Prozesse in vielen Organisationen zu langsam. Nicht, weil Menschen nicht reagieren. Sondern weil sie im entscheidenden Moment zu viel klären müssen, was eigentlich längst geklärt sein sollte.

Wenn DORA ernst genommen wird, verschiebt sich der Blick vom „Incident als IT-Aufgabe“ hin zu „Incident als Betriebsfähigkeit“. Das ist kein kosmetischer Unterschied. Ein IT-Team kann einen Fehler beheben und trotzdem kann das Unternehmen als Ganzes langsam sein: weil Auswirkung und Priorisierung unklar bleiben, weil Kommunikation zögert, weil Dienstleister nicht sauber eingebunden werden, weil Freigaben fehlen oder weil das Thema Wiederherstellung erst dann strukturiert wird, wenn bereits wertvolle Zeit verloren ist. In Audits zeigt sich das häufig in einem typischen Muster: Prozesse sind beschrieben, Tickets existieren, aber die End-to-end-Kette ist brüchig. Und wenn die Kette brüchig ist, wird Geschwindigkeit zur Glückssache.

Warum ist das unter DORA so kritisch? Weil DORA nicht nur wissen will, ob Sie „irgendwie reagieren“, sondern ob Sie systematisch und wiederholbar reagieren – und das auch belegen können. Die unangenehme Seite daran ist: Viele Organisationen sehen erst im Audit, dass ihre Incident-Fähigkeit stärker auf Erfahrungswissen basiert als auf belastbaren Routinen. Die gute Seite ist: Sie können das relativ schnell verbessern, ohne Ihr Unternehmen in ein neues Monsterprogramm zu zwingen. Sie müssen nicht mehr dokumentieren, sondern die Engpässe im Ablauf lösen, die Entscheidungen verzögern.

Der erste Engpass ist fast immer die Einstufung. Technisch gesehen ist oft früh klar, dass etwas „nicht normal“ ist. Was dann fehlt, ist eine schnelle, gemeinsame Einordnung: Betrifft es einen kritischen Service? Welche Kunden oder Prozesse sind betroffen? Ist das ein Thema, das sofortige Eskalation braucht, oder lässt es sich im normalen Betrieb abarbeiten? Viele Prozesse sagen zwar, dass es eine Einstufung gibt, aber im realen Vorfall dauert sie zu lange. Der Grund ist selten Faulheit, sondern Unklarheit: Die Kriterien sind zu abstrakt, der Zugriff auf Service-Kritikalität ist nicht schnell genug, oder man scheut die Konsequenz, weil ein „Major“ sofort Kommunikations- und Managementpflichten auslöst. Dann bleibt man in einem Zwischenzustand hängen, der am Ende die teuerste Variante ist: viel Aufmerksamkeit, aber keine klare Führung.

Der zweite Engpass ist die Entscheidungskette. In vielen Organisationen ist „Wer macht was?“ formal beschrieben. Im Ernstfall zählt aber „Wer entscheidet was?“. Das sind nicht dieselben Fragen. Formal kann ein Team zuständig sein. Entscheiden kann es trotzdem nicht, weil Freigaben, Kommunikation oder Abschaltungen an andere Rollen gebunden sind. Wenn diese Entscheidungspunkte nicht als echte, stressfeste Routine existieren, entstehen Verzögerungen, die sich im Incident multiplizieren. Ein gutes Beispiel ist externe Kommunikation. Viele Unternehmen haben Texte, Templates, Kanäle. Und trotzdem dauert die Freigabe, weil unklar ist, wer final zeichnet, welche Fakten ausreichen und ab wann man überhaupt kommunizieren soll. Währenddessen geht die Gerüchteküche los – intern wie extern – und aus einem technischen Problem wird ein Vertrauensproblem.

Der dritte Engpass ist die Dienstleister-Integration. Unter DORA ist Third-Party Risk nicht nur eine Vertragsfrage, sondern eine operative Frage. In der Realität hängen viele kritische Services heute an SaaS, Plattformen, Cloud-Komponenten, Payment-Providern, Netzwerkdiensten oder Spezialdienstleistern. Wenn dort etwas ausfällt, ist Ihr Handlungsspielraum begrenzt. Umso wichtiger ist, dass die Zusammenarbeit im Incident funktioniert: klare Eskalationswege, definierte Ansprechpartner, abgestimmte Kommunikationsrhythmen, eine gemeinsame Zeitlinie und vor allem eine klare Übersetzung zwischen „Provider-Sicht“ und „Business-Sicht“. Häufig wird genau das erst im Vorfall improvisiert. Dann dauert es, bis man die richtige Person erreicht, bis man verlässliche Informationen bekommt, bis man weiß, ob die Störung regional, global oder nur in einem Teilservice wirkt. Und genau diese Minuten sind es, die DORA später als mangelnde Betriebsfähigkeit sichtbar macht.

Der vierte Engpass ist der Übergang von „Fix“ zu „Wiederherstellung“. Viele Incident-Prozesse sind stark auf die Behebung eines Symptoms fokussiert. DORA denkt stärker in Stabilisierung und Wiederanlauf: Was ist der minimale Betrieb, den wir schnell erreichen können? Wie stellen wir sicher, dass wir kontrolliert zurückkehren, ohne Folgefehler? Welche Abhängigkeiten müssen geprüft werden, bevor wir hochfahren? Dieser Teil ist in der Praxis oft zu wenig geübt. Das führt dazu, dass Teams zwar schnell „etwas“ reparieren, aber langsamer darin sind, das System sauber zu stabilisieren. Und genau dort entstehen Second Hits: Folgeincidents, Rückfälle, Dateninkonsistenzen, fehlerhafte Nacharbeiten. In Audits sieht das dann so aus: „Incident wurde gelöst“, aber die Wiederherstellung ist nicht klar belegt, nicht klar geführt und nicht klar abgesichert.

Wenn man diese Engpässe zusammenfasst, entsteht ein Bild: Incident-Prozesse sind nicht zu langsam, weil Menschen träge sind. Sie sind zu langsam, weil sie zu viele offene Fragen enthalten. Operational Resilience bedeutet, diese offenen Fragen vorab zu schließen – nicht theoretisch, sondern in einer Form, die unter Stress funktioniert. Das klingt nach „mehr Regeln“. In Wirklichkeit ist es meist „weniger Diskussion“. Denn jede geschlossene Frage spart im Incident Zeit und Energie.

Ein pragmatischer Weg dahin beginnt mit einer ganz simplen Designregel: Jede kritische Incident-Situation braucht drei Dinge sofort – Klarheit über Auswirkung, Klarheit über Entscheidungspunkte und Klarheit über Kommunikation. Wenn Sie diese drei Dinge früh herstellen, wird vieles andere einfacher. Auswirkung heißt nicht, dass Sie in den ersten fünf Minuten eine perfekte Analyse haben. Es heißt, dass Sie eine belastbare Erstbewertung haben, die sich später verfeinern lässt. Entscheidungspunkte heißt nicht, dass Sie ein riesiges Krisengremium starten. Es heißt, dass wenige Entscheidungen schnell getroffen werden können: Einstufung, Priorität, Kommunikationsmodus, Einbindung externer Parteien, Notbetrieb. Kommunikation heißt nicht, dass Sie sofort eine Pressemitteilung schreiben. Es heißt, dass Sie intern und gegenüber Betroffenen einen klaren Takt und eine klare Verantwortung haben, statt stille Phasen zu erzeugen.

Sehr häufig wird versucht, diese Themen über zusätzliche Dokumentation zu lösen. Das funktioniert selten. Was besser funktioniert, ist eine kleine Standardisierung im Ablauf. Stellen Sie sich vor, jeder relevante Incident erzeugt automatisch ein „Paket“, das denselben Kern enthält: eine kurze Zeitlinie, die Einstufung mit Begründung, die erste Auswirkungsabschätzung, die Entscheidungspunkte, die Kommunikationsspur, die Ticketreferenzen und die Maßnahmenliste. Das Paket muss nicht schön sein. Es muss eindeutig sein. Der Vorteil ist doppelt: Im Incident gibt es einen gemeinsamen Anker („das ist der Stand“), und im Nachgang haben Sie Evidenz, die nicht mühsam zusammengesucht werden muss. Genau das ist DORA-Logik: Betrieb und Nachweis sind dieselbe Spur.

Jetzt wird oft gefragt: „Klingt gut, aber wir haben keine Zeit für mehr Prozess.“ Das ist der falsche Vergleich. Sie haben heute schon Prozess – nur verteilt, implizit, personenabhängig. Der Aufwand entsteht nicht durch Standards, sondern durch Improvisation. Ein sauberer Standard spart Zeit, weil er die Suche nach Zuständigkeit, Fakten, Freigaben und Ablage reduziert. Und er spart Nerven, weil er Konflikte reduziert: Wenn klar ist, wer entscheidet, gibt es weniger Machtspiele im Moment der Krise. Wenn klar ist, wie kommuniziert wird, gibt es weniger Bauchgefühl-Debatten. Wenn klar ist, wo Evidenz liegt, gibt es weniger hektische Nacharbeit.

Ein weiterer Grund, warum Incident-Prozesse unter DORA zu langsam wirken, ist das Reporting nach oben. Viele Teams schicken früh technische Statusupdates. Führung braucht aber keine Logfiles. Führung braucht einen Steuerungsimpuls: Was ist betroffen, wie ernst ist es, welche Optionen haben wir, was brauchen Sie als Entscheidung? Wenn das nicht geliefert wird, entstehen Rückfragen. Rückfragen kosten Zeit. Und Rückfragen erzeugen Unruhe. DORA bedeutet deshalb auch, dass Incident-Information in eine Form gebracht wird, die schnell entscheidungsfähig ist. Das muss nicht lang sein. Es muss klar sein. Ein Satz zur Auswirkung, ein Satz zur Lage, ein Satz zur nächsten Entscheidung – und ein Takt, wann das nächste Update kommt. Mehr braucht es am Anfang oft nicht.

In der Praxis lohnt es sich, zwischen „technischer Incident-Bearbeitung“ und „Incident-Führung“ zu unterscheiden. Technische Bearbeitung löst Probleme. Incident-Führung hält den Ablauf stabil: sie organisiert Entscheidungspunkte, Kommunikationsrhythmen, Stakeholder, Provider, Wiederanlauf. Viele Organisationen haben viel technische Kompetenz, aber zu wenig definierte Incident-Führung. Dann entsteht ein typisches Muster: Die Technik arbeitet, aber niemand „hält den Raum“. Und genau das ist die Quelle von Langsamkeit. Denn ohne Führung wird alles parallel, widersprüchlich und unkoordiniert. Die gute Nachricht ist: Incident-Führung ist keine neue Abteilung. Es ist eine Rolle im Moment, mit klaren Aufgaben. Und sie lässt sich gut trainieren.

Training ist überhaupt der unterschätzte Teil. Viele Unternehmen üben technische Wiederherstellung (Backup, Failover, Notfallhandbuch). Was sie weniger üben, sind die ersten 30 bis 60 Minuten eines realen Incidents: Einstufung, Entscheidung, Kommunikation, Provider-Eskalation, Notbetrieb. Genau dort entsteht Geschwindigkeit. Und genau dort entsteht auch die Evidenz, die DORA später sehen will. Ein Tabletop-Training, das nur diese Phase übt, kann mehr Resilienz erzeugen als eine große Übung, die am Ende in schönen Folien endet, aber keine Entscheidungspunkte härtet.

Wenn Sie solche Übungen machen, ist die wichtigste Frage nicht „Haben wir geübt?“, sondern „Sind wir besser geworden?“. Viele Übungen enden mit einem Protokoll. Reife entsteht, wenn daraus drei konkrete Maßnahmen folgen, mit Owner und Termin, und wenn es einen Re-Test gibt. Das muss nicht kompliziert sein. Aber ohne Re-Test bleibt Lernen ein Wunsch. Unter DORA wird genau dieser Unterschied sichtbar: ob Übungen als Pflichttermin laufen oder als Motor für echte Verbesserung.

Ein sehr häufiges Problemfeld ist außerdem die Schwellenlogik. Wann ist ein Incident „relevant“? Wann wird er „major“? Wann wird die Krisenorganisation aktiviert? Wenn diese Schwellen zu weich sind, diskutiert man zu lange. Wenn sie zu hart sind, aktiviert man zu oft und das System nutzt sich ab. Die Lösung ist nicht perfekte Theorie, sondern ein bewusstes, pragmatisches Set an Kriterien, das zur Organisation passt. Typischerweise hilft es, Schwellen an Services zu knüpfen: Wenn ein kritischer Service betroffen ist und die Ausfalltoleranz überschritten wird oder wahrscheinlich überschritten wird, dann ist das eine klare Eskalationsbedingung. Damit vermeiden Sie, dass die Diskussion rein technisch geführt wird („CPU hoch, aber ist das schlimm?“), sondern führen sie in der Sprache des Betriebs („Service kritisch, Zeitfenster knapp“).

Auch bei Kommunikation helfen Schwellen. Viele Organisationen warten zu lange, weil sie Angst haben, „falsch“ zu kommunizieren. Die Realität ist: Stille ist fast immer schlechter als ein kontrolliertes, vorsichtiges Update. Wenn Sie einen Kommunikationsmodus haben, der in frühen Phasen mit wenigen gesicherten Fakten arbeitet, vermeiden Sie die Blockade. Und wenn Sie klare Freigabewege haben, vermeiden Sie, dass Kommunikation an einzelnen Personen hängt, die vielleicht gerade nicht erreichbar sind. Genau das ist übrigens ein Klassiker im Audit: Prüfer fragen gerne, wie Stellvertretung und Freigabe unter Abwesenheit funktioniert. Wenn die Antwort „in der Praxis ruft man halt an“ ist, wirkt das nicht belastbar.

Ein weiterer Aspekt, der Incident-Prozesse langsam macht, ist die Ablage. Das klingt klein, ist aber in vielen Organisationen der Unterschied zwischen Ruhe und Chaos. Wenn Informationen über Tickets, E-Mails, Chats und Dokumente verteilt sind, verlieren Sie Zeit, weil Teams ständig synchronisieren müssen: „Was ist der Stand?“, „Welche Version ist richtig?“, „Wer hat das entschieden?“. Ein klarer Ablageanker – ein Incident-Tickettyp, ein definierter Ordner, ein Incident-Log – reduziert diese Reibung drastisch. Und er erzeugt die Nachweisspur, die DORA später verlangt. Die Faustregel ist hart, aber praktisch: Was Sie nicht schnell finden, gilt im Ernstfall als nicht vorhanden. Das betrifft nicht nur Audits, sondern auch Ihre eigene Reaktionsfähigkeit.

Wenn man das alles zusammennimmt, ist „Operational Resilience“ im Incident-Kontext vor allem ein Thema von Zeit. Nicht von Geschwindigkeit im Sinne von hektischem Aktionismus, sondern von Zeit im Sinne von Entscheidungszeit, Kommunikationszeit, Wiederherstellungszeit. Und Zeit wird nicht durch heroische Einsätze optimiert, sondern durch klare Standards. Die beste Incident-Organisation ist die, in der niemand improvisieren muss, obwohl alle flexibel bleiben dürfen.

Was wäre ein realistischer nächster Schritt, wenn Sie das in Ihrer Organisation verbessern wollen? Nicht ein großes Redesign, sondern ein kleiner, messbarer Umbau. Sie können sich zum Beispiel drei Zielzeiten setzen, die in vielen Kontexten sinnvoll sind: Zeit bis zur ersten belastbaren Einstufung, Zeit bis zum ersten Management-Update, Zeit bis zur Aktivierung des Provider-Eskalationswegs (falls relevant). Diese Zeiten sind nicht dazu da, Menschen zu „messen“. Sie sind dazu da, die Prozessengpässe sichtbar zu machen. Wenn Sie feststellen, dass die Einstufung regelmäßig 45 Minuten dauert, ist nicht die Frage „wer war schuld“, sondern „welche Frage war offen“: Servicekritikalität? Schwellen? Zuständigkeit? Kommunikationsfreigabe? Wenn Sie diese offenen Fragen schließen, sinkt die Zeit automatisch.

Und genau damit sind wir wieder bei DORA als praktisches Konzept. DORA zwingt nicht zu mehr Bürokratie, sondern zu mehr Betriebsreife. Betriebsreife heißt: Entscheidungen sind vorbereitet, Abläufe sind wiederholbar, Nachweise entstehen nebenbei. Incident-Prozesse sind oft zu langsam, weil sie in der Theorie gut aussehen, aber in der Praxis zu viele offene Enden haben. Wenn Sie diese Enden schließen, gewinnen Sie nicht nur Auditfähigkeit. Sie gewinnen das, was im Alltag wirklich zählt: weniger Chaos, weniger Eskalationsstress, klarere Kommunikation und eine Wiederherstellung, die nicht nur schnell, sondern kontrolliert ist.

Im nächsten Beitrag können wir darauf aufbauen und noch konkreter in die Mechanik gehen: Welche Minimalartefakte eine „Incident-Akte“ enthalten sollte, damit sie sowohl im Betrieb hilft als auch in einer Prüfung auf Anhieb verständlich ist – ohne dass Teams dafür eine zweite Dokumentationswelt pflegen müssen.