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:

Manche Sicherheitsgeschichten beginnen mit einem Genie an der Kommandozeile, einem Domain-Admin im Mantel der Nacht, einem perfekt orchestrierten Angriff auf Kerberos oder KMS. Die meisten beginnen anders: mit alltäglichen Rechten, die niemand für gefährlich hält. Ein „Viewer“ in der Doku-Plattform. Ein „Reporting“-Zugang im CRM. Ein „Guest“ im Kollaborationstool. Ein Servicekonto mit Leserechten auf Logdateien. Ein Praktikanten-Account, der nur Tickets lesen darf. Diese scheinbar harmlosen Berechtigungen sind die Welt des Insider light – Personen und Prozesse innerhalb (oder knapp außerhalb) der Organisation, die keine „großen“ Rechte brauchen, um große Lücken zu reißen. Nicht, weil sie Superhacker wären, sondern weil unsere Systeme Informationen großzügig streuen, Workflows automatisch auslösen und Meta­daten verräterischer sind, als uns lieb ist. Wer Sicherheit heute ernst meint, darf das kleine Licht nicht unterschätzen, denn es beleuchtet überraschend viele Wege bis ins Herz der Organisation.

Was genau ist „Insider light“?

„Insider“ weckt oft das Bild des böswilligen Mitarbeiters mit Vollzugriff. „Light“ verschiebt die Perspektive: Es geht um Akteure mit begrenzten, formal unkritischen Rechten, die dennoch kritische Wirkung entfalten – absichtlich, fahrlässig oder weil sie selbst zum Opfer werden. Das Spektrum ist breit:

C5 hat sich leise, aber stetig vom Katalog für Cloud-Kontrollen zur Referenz für gelebte Cloud-Governance entwickelt. 2025 markiert den Punkt, an dem diese Entwicklung sichtbar wird: Nicht mehr die Frage „Welche Kriterien erfüllt der Provider?“ dominiert, sondern „Wie steuern wir als Unternehmen – nachweisbar, zeitkritisch und wiederholbar – unsere Cloud-Realität?“ Wer C5 noch als Attest versteht, verschenkt Wirkung. Wer C5 als Betriebssprache, als Schalterset und als Evidenzfundament begreift, gewinnt Tempo, Resilienz und Vertrauen. Dieser Beitrag zeichnet nach, wie C5 2025 zur Benchmark wird: in Architektur und Betrieb, in Audits und Aufsicht, in Lieferketten und Verträgen, in Daten- und KI-Domänen – und wie sich die Kultur ändert, wenn Prüfung kein Ereignis mehr ist, sondern Nebenprodukt guter Arbeit.

Warum 2025 anders ist

Cloud-Nutzung ist erwachsen geworden. Unternehmen betreiben Portfolios, nicht Einzelprojekte. Kritische Geschäftsprozesse sind in Plattformen, Automatisierung und Datenströmen verankert. Regulatorik hat den Takt erhöht: Resilienz wird in Zeiten gemessen, nicht in Reifegradfarben. Meldepflichten verlangen Belege in Stunden, nicht in Wochen. Kunden verlangen Nachweise, die die Wirklichkeit abbilden – nicht Präsentationen. In diesem Umfeld reicht es nicht, einen C5-Bericht abzuheften. Er muss anschließen: an Pipelines, an Plattformen, an Notfallpläne, an Verträge, an Kennzahlensysteme. 2025 ist das Jahr, in dem C5 dort ankommt – und dadurch vom Prüfkatalog zur Benchmark wird.

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.