Operational Resilience galt lange als Sonderdisziplin für Krisenmanager, als Notfallplan für seltene, extreme Ereignisse: Rechenzentrum brennt, Leitungen fallen aus, Angriff trifft die Kernsysteme, Lieferant stürzt ab. Dann kam die Dauerkrise – nicht als einzelner Paukenschlag, sondern als Takt: Cloud-Migrationswellen, Release-Kadenz im Wochenrhythmus, global vernetzte Lieferketten, Meldepflichten mit engen Fristen, Angreifer, die sich industrialisiert haben, und Kundenerwartungen, die Ausfallzeiten nicht mehr entschuldigen. Was früher Ausnahmefall war, ist heute Betriebszustand. Operational Resilience 360° bedeutet deshalb nicht, mehr Notfallpläne zu schreiben oder größere Firewall-Wälle zu ziehen. Es bedeutet, das Unternehmen so zu gestalten, dass Störungen einkalkuliert sind, Entscheidungen unter Druck zuverlässig fallen, Wiederanläufe geprüft sind, Beweise nebenbei entstehen und der Normalbetrieb bereits den Krisenbetrieb enthält. Es ist ein Kultur- und Architekturwechsel – vom heroischen Improvisieren zur geprobten Beherrschbarkeit; vom Projekt zur Betriebsleistung; vom Dokument zur Demonstration.

In der Praxis beginnt dieser Wandel mit einer unbequemen Ehrlichkeit: Niemand kann alle Risiken vermeiden, niemand alle Abhängigkeiten herauslösen, niemand ein „Null-Ausfall“-Unternehmen bauen. Die Illusion vollständiger Kontrolle ist selbst ein Risiko, denn sie verführt zu guten Geschichten statt zu belastbaren Fähigkeiten. Wer Operational Resilience 360° ernst nimmt, verabschiedet sich von makelloser Fassade und arbeitet an den Mechaniken dahinter: Wirkzeit statt Reifegrad, Übungen statt Versprechen, Anschlussfähigkeit statt Einkaufsfolklore, Evidenz statt Erinnerung, Reduktion statt Sammeltrieb, und eine Zeitlogik, die über Sicherheit hinaus das Geschäft führt. Das Ergebnis ist keine Organisation, die nicht mehr stolpert, sondern eine, die beim Stolpern nicht fällt – und wieder in den Lauf findet, ohne erst ihren Schuh suchen zu müssen.

A uf dem Papier klingt alles logisch: Ein europäischer Rahmen, der digitale Resilienz messbar macht, Meldewege harmonisiert, Drittparteien in die Pflicht nimmt und das Silo-Denken zwischen IT, Betrieb, Einkauf und Compliance aufbricht. In der Praxis prallen diese neuen Pflichten auf alte Strukturen – gewachsene Organisationen, komplexe Lieferketten, Legacy-Systeme, projektgetriebene Budgets, fragmentierte Verantwortungen. Das Ergebnis ist vielerorts dasselbe Bild: ernsthafte Bereitschaft, viel Aktivität, lange To-do-Listen – und trotzdem das Gefühl, dass DORA wie ein Wellenbrecher immer neue Lücken in den Damm schlägt. Dieser Beitrag seziert, wo DORA Unternehmen überfordert, warum das so ist und wie sich der Knoten lösen lässt, ohne Dutzende Parallelprojekte zu starten, die am Ende nur mehr Papier produzieren.

1) Der Kern des Problems: DORA verlangt Fähigkeiten, nicht Formulare

Die erste Überforderung beginnt im Kopf: Viele Organisationen behandeln DORA wie eine weitere Compliance-Checkliste. Das ist bequem, aber falsch. DORA verlangt Fähigkeiten – erkennen, entscheiden, melden, wiederanlaufen, nachweisen – in klaren Zeitfenstern und über Bereichsgrenzen hinweg. Genau hier reibt sich die Verordnung an alten Mustern:

Lange war C5 der pragmatische Schlüssel, um mit Hyperscalern auf Augenhöhe zu sprechen: klare Kontrollziele, nachvollziehbare Prüfberichte, eine Sprache, die Entwicklung, Betrieb, Einkauf, Recht und Revision zusammenbringt. Mit DORA – dem Digital Operational Resilience Act – verschiebt sich der Rahmen. Was zuvor „Best Practice“ oder „kundenseitige Due Diligence“ war, wird nun aufsichtliche Erwartung: belastbare Nachweise, risikobasierte Steuerung, Meldefähigkeit in Stunden, Wiederherstellbarkeit unter Druck, gelebte Lieferantenkontrolle. Kurz: Cloud-Prüfung wird regulatorisch. Dieser Beitrag zeigt, wie C5 und DORA zusammenpassen, wo sie sich ergänzen – und wie man die beiden Welten so verbindet, dass aus Compliance keine Bremse, sondern ein betriebliches Beschleunigungsprogramm wird.

Von der Komfortzone in den Ernstfall: Was sich mit DORA ändert

C5 hat Unternehmen befähigt, die Provider-Seite systematisch zu prüfen: Mandantentrennung, Kryptostrategien, physische und logische Sicherheit, Logging-Optionen, Incident-Prozesse, Subprozessoren, Notfallkonzepte. DORA dreht die Kamera und zentriert die Kundenseite: Wie sind kritische Prozesse definiert? Welche Zeiten gelten (Erkennen, Entscheiden, Begrenzen, Wiederherstellen)? Wie laufen Vorfälle durch die Organisation – und durch die Lieferkette? Welche Evidenz liegt wann vor? Wie werden Risiken bei IKT-Dritten gesteuert? Wie werden Tests geplant, durchgeführt, ausgewertet? Damit reicht es nicht mehr, „einen C5-Bericht im Ordner zu haben“. DORA erwartet, dass Cloud-Einsatz in die Resilienz-Mechanik eingebaut ist – prüfbar, wiederholbar, anschlussfähig.

Am Tag, an dem DORA anwendbar wurde, endete kein Projekt – es begann ein Dauerzustand. Kaum irgendwo wird das deutlicher als bei der Resilienz von Drittparteien. Die Jahre zuvor hatten viele Häuser in Fragebögen, Vertragsanhängen und Zertifikaten einen hinreichenden Nachweis gesehen, dass ihre Auslagerungen „unter Kontrolle“ seien. Heute weiß jeder, der operative Verantwortung trägt: Kontrolle beginnt nicht im PDF, sondern im Betrieb. Sie beginnt dort, wo Informationsflüsse, Schnittstellen, Protokolle, Wiederanläufe, Meldungen und Entscheidungen sich tatsächlich bewegen. Und sie endet nicht mehr an der Unternehmensgrenze. „Third Party Resilience“ ist zur Kernkompetenz geworden – fachlich, technisch, organisatorisch, juristisch. Der Satz „Nach DORA ist vor der Prüfung“ bringt es auf den Punkt: Wer jetzt nicht in einen belastbaren Betriebsmodus wechselt, wird die nächste Aufsichtsrunde nicht nur als Formalie, sondern als Stresstest erleben.

Von der Auslagerung zur Abhängigkeit: Warum die Messlatte gestiegen ist

Die Modernisierung der Finanz-IT hat drei Bewegungen zusammengeführt: Cloudifizierung kritischer Kernprozesse, Spezialisierung entlang der Wertschöpfungskette und ein exponentielles Wachstum an Software-as-a-Service in Fachbereichen. Was als Effizienz- und Innovationsmotor begann, hat die Systemkopplung dramatisch erhöht. Eine Authentifizierungsstörung in einem globalen IAM-Dienst, eine Aktualisierung im Zahlungs-Gateway, eine veränderte Drosselungslogik in einer API-Plattform – schon kleine Ereignisse strahlen heute weit in Geschäftsprozesse hinein. DORA hat diese Realität nicht geschaffen, aber sie hat sie regulatorisch sichtbar gemacht: Verantwortlichkeit bleibt im Institut, auch wenn Leistung extern erbracht wird. Das ist keine Drohung, es ist eine Einladung zur Professionalität. Wer die Kaskaden versteht, steuert; wer sie ignoriert, hofft.

Lieferketten sind das Kreislaufsystem der digitalen Finanzwirtschaft: durch sie fließen Rechenleistung, Software, Daten, Identitäten, Beratung, Rechenzentrumsfläche, Cloud-Services, Zahlungsplattformen, Support. Lange wurde über sie gesprochen, als ginge es um Einkaufskonditionen oder Service Levels. Heute stehen sie im Mittelpunkt zweier Aufsichtswelten, die sich nicht mehr ignorieren lassen: digitale Resilienz nach DORA und Nachhaltigkeit nach ESG-Regimen wie CSRD, CSDDD, Lieferketten- und Umweltauflagen. Was früher zwei parallele Gespräche waren – Sicherheit hier, Nachhaltigkeit dort –, verwandelt sich in eine einzige Führungsaufgabe. Denn dieselben Lieferanten, die Kernprozesse am Laufen halten, sind zugleich Ursprung von CO₂-Fußabdrücken, Menschenrechts- und Umwelt­risiken, Daten- und KI-Fragen.

Dieser Beitrag zeigt, warum die beiden Welten sich gerade ineinander verschrauben, weshalb klassische Third-Party-Checklisten scheitern, wie ein integriertes Steuerungsmodell für DORA- und ESG-Pflichten aussieht, welche Metriken zählen, wie Verträge zu Führung werden, welche Anti-Patterns sicher ins Aus führen – und wie sich in 180 Tagen ein Fundament legen lässt, das Prüfungen besteht und Betriebe stabilisiert. Kurz: Wie man Lieferketten im Stress in eine belastbare, prüfbare, zukunftsfähige Architektur überführt.