DORA in der Praxis – Was der Digital Operational Resilience Act für Cloud-Architekturen bedeutet

Warum DORA mehr als nur eine weitere EU-Verordnung ist

Seit dem 17. Januar 2025 ist der Digital Operational Resilience Act – kurz DORA – vollständig anwendbar. Die EU-Verordnung (EU) 2022/2554 richtet sich an den gesamten europäischen Finanzsektor: Banken, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen und deren kritische IKT-Drittdienstleister, einschließlich Cloud-Provider. Rund 22.000 Finanzunternehmen und IKT-Dienstleister in der EU fallen unter die Regelung.

Das Besondere an DORA: Es geht nicht um allgemeine IT-Sicherheit, sondern um die digitale operationelle Widerstandsfähigkeit – also die Fähigkeit, IKT-bezogene Störungen zu erkennen, darauf zu reagieren und den Geschäftsbetrieb aufrechtzuerhalten. Für Unternehmen, die ihre Infrastruktur in die Cloud verlagert haben oder gerade dabei sind, verschiebt das die Prioritäten erheblich.

Die fünf Säulen von DORA – und was sie für die Cloud bedeuten

DORA definiert fünf zentrale Handlungsfelder, die direkte Auswirkungen auf Cloud-Architekturen haben.

1. IKT-Risikomanagement

Finanzunternehmen müssen ein umfassendes Rahmenwerk für das IKT-Risikomanagement etablieren. Für Cloud-Infrastrukturen bedeutet das: Jede Komponente – von der Compute-Instanz über den Managed Service bis zum SaaS-Tool – muss in einer aktuellen Asset-Inventur erfasst und hinsichtlich ihrer Kritikalität bewertet sein.

In der Praxis erfordert das eine lückenlose Configuration Management Database (CMDB), die automatisiert aus Infrastructure-as-Code-Pipelines und Cloud-APIs befüllt wird. Wer seine Azure-Subscriptions oder AWS-Accounts noch manuell dokumentiert, steht vor einem fundamentalen Problem.

2. Behandlung, Klassifizierung und Berichterstattung von IKT-Vorfällen

DORA verlangt ein standardisiertes Incident-Klassifizierungsschema und verpflichtende Meldungen an die BaFin innerhalb festgelegter Fristen. Schwerwiegende IKT-Vorfälle müssen innerhalb von vier Stunden nach Feststellung initial gemeldet werden, gefolgt von einem Zwischenbericht innerhalb von 72 Stunden und einem Abschlussbericht innerhalb eines Monats.

Für Cloud-Architekturen bedeutet das: Observability ist keine Option mehr, sondern regulatorische Pflicht. Unternehmen brauchen ein zentrales Incident-Management-System, das Cloud-native Alerts mit Business-Impact-Bewertungen korreliert. Die Verbindung von technischem Monitoring – etwa über OpenTelemetry, Grafana oder Datadog – mit dem regulatorischen Meldewesen wird zum architektonischen Pflichtprogramm.

Eine Großbank in Frankfurt hat dieses Problem gelöst, indem sie ihre Observability-Plattform direkt mit dem internen ITSM-System verknüpft hat. Cloud-Alerts werden automatisch nach dem DORA-Klassifizierungsschema eingestuft, und bei Überschreitung definierter Schwellenwerte – etwa der Ausfall eines kundenrelevanten Service für mehr als 30 Minuten – wird der Meldeprozess automatisch angestoßen.

3. Testen der digitalen operationellen Resilienz

DORA fordert regelmäßige Resilienztests, einschließlich Threat-Led Penetration Testing (TLPT) für systemrelevante Institute. Cloud-Architekturen müssen so gestaltet sein, dass sie diese Tests unterstützen, ohne den Produktivbetrieb zu gefährden.

Konkret heißt das: Chaos Engineering wird vom Nice-to-have zur Compliance-Anforderung. Unternehmen müssen nachweisen können, dass ihre Cloud-Infrastruktur Ausfälle einzelner Availability Zones, den Verlust eines Managed Service oder die Nicht-Erreichbarkeit einer API verkraftet. Tools wie Chaos Monkey, Litmus oder Azure Chaos Studio bekommen damit eine regulatorische Dimension.

Ein Versicherer aus München setzt seit Anfang 2026 auf automatisierte Resilienztests in seiner Kubernetes-Umgebung. Einmal pro Quartal werden gezielt Pods terminiert, Netzwerkpartitionen simuliert und Datenbank-Failover provoziert. Die Ergebnisse fließen direkt in den DORA-Compliance-Report, der der BaFin vorgelegt wird.

4. Management des IKT-Drittparteienrisikos

Hier wird es für Cloud-Nutzer besonders relevant. DORA verlangt ein systematisches Management der Risiken, die durch die Abhängigkeit von IKT-Drittdienstleistern entstehen. Cloud-Provider wie AWS, Azure und Google Cloud fallen explizit in diese Kategorie.

Die Anforderungen sind konkret: Finanzunternehmen müssen ein vollständiges Register aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen, einschließlich einer Bewertung der Konzentrationsrisiken. Wenn eine Bank ihre gesamte Kerninfrastruktur bei einem einzigen Cloud-Provider betreibt, muss sie dokumentieren, warum dieses Konzentrationsrisiko tragbar ist – oder Maßnahmen ergreifen, um es zu reduzieren.

Das hat direkte architektonische Konsequenzen. Multi-Cloud-Strategien, die bisher oft als unnötig komplex abgetan wurden, bekommen durch DORA eine regulatorische Berechtigung. Nicht als pauschale Forderung, sondern als risikobewusste Entscheidung: Welche Workloads sind so kritisch, dass sie Provider-unabhängig betrieben werden müssen? Wo reicht ein dokumentierter Exit-Plan?

5. Informationsaustausch

DORA fördert den freiwilligen Austausch von Informationen über Cyberbedrohungen zwischen Finanzunternehmen. Für die technische Architektur bedeutet das die Anbindung an Threat-Intelligence-Plattformen und die Fähigkeit, Indicators of Compromise (IoCs) automatisiert in die eigene Verteidigung einzuspeisen.

Exit-Strategien: Die unbequeme Pflicht

Eine der anspruchsvollsten DORA-Anforderungen betrifft Exit-Strategien für Cloud-Dienste. Artikel 28 der Verordnung verlangt, dass Finanzunternehmen für jeden kritischen IKT-Drittdienstleister einen dokumentierten Ausstiegsplan vorhalten – einschließlich konkreter Transitionszeiträume, Datenportabilitätsverfahren und der Sicherstellung der Geschäftskontinuität während des Wechsels.

Für ein Unternehmen, das seine Kernbanksysteme auf Azure betreibt, bedeutet das: Es muss einen realistischen Plan geben, wie diese Systeme innerhalb eines definierten Zeitraums zu einem alternativen Provider oder zurück in ein eigenes Rechenzentrum migriert werden können. Das ist keine theoretische Übung – der Plan muss getestet und aktualisiert werden.

In der Praxis sehen wir drei Ansätze, wie deutsche Finanzunternehmen mit dieser Anforderung umgehen:

Der erste Ansatz ist die konsequente Containerisierung. Wer seine Workloads auf Kubernetes betreibt und Infrastructure as Code nutzt, hat den größten Teil der Portabilität bereits eingebaut. Die Anwendung selbst ist Provider-agnostisch, und die Infrastruktur lässt sich mit Terraform oder Crossplane auf einem alternativen Target reproduzieren.

Der zweite Ansatz ist die Abstraktion auf Service-Ebene. Statt direkt Azure Cosmos DB oder AWS DynamoDB zu nutzen, setzen manche Institute auf Open-Source-Alternativen wie PostgreSQL oder MongoDB, die auf jedem Cloud-Provider oder on-premise betrieben werden können. Das erhöht die Portabilität, geht aber zulasten der Managed-Service-Vorteile.

Der dritte Ansatz ist die dokumentierte Akzeptanz. Nicht jeder Workload muss portabel sein. DORA verlangt keine Multi-Cloud-Architektur, sondern eine bewusste, dokumentierte Risikoentscheidung. Wenn ein Unternehmen nachweisen kann, dass es das Konzentrationsrisiko kennt, bewertet und geeignete Mitigationsmaßnahmen getroffen hat, ist das regulatorisch akzeptabel.

Cloud-Provider unter Aufsicht: Das kritische Drittparteien-Framework

DORA bringt eine weitere Neuerung: Die europäischen Aufsichtsbehörden können IKT-Drittdienstleister als „kritisch” einstufen und direkt beaufsichtigen. AWS, Microsoft Azure und Google Cloud fallen mit hoher Wahrscheinlichkeit in diese Kategorie.

Für Finanzunternehmen hat das eine positive Seite: Die Aufsichtsbehörden werden selbst Transparenz über die Sicherheitspraktiken der großen Cloud-Provider einfordern. Die von den Hyperscalern bereitgestellten Compliance-Dokumentationen – Azure Compliance Manager, AWS Artifact, Google Cloud Compliance Reports – werden damit nicht weniger relevant, aber sie werden durch eine zusätzliche, unabhängige Prüfebene ergänzt.

Gleichzeitig steigt der Druck auf Finanzunternehmen, ihre vertraglichen Vereinbarungen mit Cloud-Providern auf DORA-Konformität zu prüfen. Standardverträge der Hyperscaler erfüllen die DORA-Anforderungen nicht immer vollständig – insbesondere bei Themen wie Audit-Rechten, Sub-Contracting-Transparenz und Kündigungsmodalitäten.

Was deutsche Unternehmen jetzt konkret tun sollten

Für Unternehmen, die noch nicht vollständig DORA-konform sind, gibt es vier Sofortmaßnahmen mit direktem Bezug zur Cloud-Architektur:

Die erste Maßnahme ist ein vollständiges IKT-Asset-Inventar. Jede Cloud-Ressource, jeder Managed Service und jede SaaS-Abhängigkeit muss dokumentiert sein. Automatisierte Tools wie Azure Resource Graph, AWS Config oder Steampipe helfen, den Ist-Zustand zu erfassen.

Die zweite Maßnahme betrifft Observability mit regulatorischer Tiefe. Bestehende Monitoring-Lösungen müssen um DORA-konforme Incident-Klassifizierung und Meldeketten erweitert werden. Die Investition in eine durchgängige Observability-Pipeline – von der Metrik bis zum BaFin-Report – zahlt sich aus.

Die dritte Maßnahme sind dokumentierte Exit-Pläne. Für jeden kritischen Cloud-Service muss ein Ausstiegsszenario existieren. Das muss nicht Multi-Cloud bedeuten, aber es muss ein realistischer, getesteter Plan sein.

Die vierte Maßnahme ist die Überprüfung aller Cloud-Verträge auf DORA-Konformität, insbesondere hinsichtlich Audit-Rechten, Incident-Meldepflichten und Exit-Klauseln.

Fazit: DORA als Architektur-Treiber

DORA ist keine Checkbox-Übung, die sich mit ein paar Dokumenten abhaken lässt. Die Verordnung hat reale Auswirkungen auf die Art, wie Finanzunternehmen ihre Cloud-Infrastrukturen entwerfen, betreiben und weiterentwickeln. Wer DORA ernst nimmt, landet bei besseren Architekturen: besser dokumentiert, besser getestet, besser überwacht und mit klaren Verantwortlichkeiten.

Die deutsche Finanzbranche steht dabei vor einer besonderen Herausforderung: Viele Institute befinden sich mitten in der Cloud-Migration und müssen gleichzeitig DORA-Konformität herstellen. Das erzeugt Reibung, aber auch die Chance, Migration und Compliance-Anforderungen zusammenzudenken, statt sie als getrennte Projekte zu behandeln.

Für Cloud-Architekten und IT-Entscheider bedeutet DORA letztlich eine Professionalisierung, die ohnehin überfällig war. Die Frage ist nicht ob, sondern wie schnell Unternehmen ihre Cloud-Architekturen auf dieses Niveau heben.