DORA Compliance für DevOps: Was der Digital Operational Resilience Act konkret bedeutet

Seit Januar 2025 gilt DORA verbindlich für alle Finanzunternehmen in der EU und damit auch für deren Cloud-Infrastruktur, Deployment-Prozesse und externe IT-Dienstleister. Wer glaubt, das sei ein Thema nur für Compliance-Abteilungen, irrt: DORA stellt konkrete technische Anforderungen, die direkt in den DevOps-Alltag eingreifen. Was genau dahintersteckt, für wen es gilt und was sich in der Praxis ändern muss, zeigt dieser Artikel.

Was ist DORA und warum jetzt?

DORA steht für Digital Operational Resilience Act, EU-Verordnung Nr. 2022/2554. Sie wurde Ende 2022 verabschiedet, und Unternehmen hatten zwei Jahre Zeit zur Vorbereitung. Seit dem 17. Januar 2025 ist sie bindend.

Das Ziel ist klar: Der europäische Finanzsektor soll widerstandsfähiger gegen Cyberangriffe, IT-Ausfälle und operative Störungen werden. DORA schreibt dabei keine spezifischen Technologien vor, sondern definiert Anforderungen an Prozesse, Dokumentation, Tests und Verträge. Das klingt abstrakt, hat aber sehr konkrete Auswirkungen auf den Betrieb.

Der Regulierungsrahmen ergänzt bestehende Anforderungen wie die EBA-Guidelines zu IKT-Risiken und die NIS2-Richtlinie. DORA ist jedoch deutlich spezifischer und gilt direkt als Verordnung, also ohne nationalen Umsetzungsspielraum.

Für wen gilt DORA?

Der Geltungsbereich ist breiter als viele zunächst annehmen. Klar betroffen sind:

• Kreditinstitute und Banken
• Versicherungsunternehmen und Rückversicherer
• Zahlungsdienstleister und E-Geld-Institute
• Investmentfirmen und Fondsmanager
• Krypto-Asset-Dienstleister (unter MiCA)
• Handelsplätze und zentrale Gegenparteien

Besonders relevant für Cloud-Anbieter und IKT-Dienstleister: DORA erfasst auch kritische IKT-Drittdienstleister. Wer als Cloud-Provider, Rechenzentrum oder SaaS-Anbieter wesentliche Dienstleistungen für Finanzunternehmen erbringt, kann direkt durch die europäischen Aufsichtsbehörden (ESAs) überwacht werden. Das betrifft im Zweifel auch Kubernetes-Plattformen, auf denen Kernprozesse laufen.

Die fünf Kernpflichten im Überblick

DORA strukturiert die Anforderungen in fünf Hauptbereiche.

IKT-Risikomanagement

Finanzunternehmen müssen ein vollständiges IKT-Risikomanagement-Framework aufbauen und dokumentieren. Das umfasst die Identifikation kritischer Systeme, die Bewertung von Abhängigkeiten (intern wie extern) und die Implementierung von Schutz- und Wiederherstellungsmaßnahmen. Wichtig: Die Verantwortung liegt beim Leitungsorgan, also auf Vorstandsebene, nicht nur in der IT.

Incident Reporting

Erhebliche IKT-bezogene Vorfälle müssen innerhalb definierter Fristen gemeldet werden. Die erste Meldung muss innerhalb von vier Stunden nach Klassifizierung des Vorfalls erfolgen, ein Folgebericht nach 72 Stunden, ein Abschlussbericht nach einem Monat. Was als „erheblich" gilt, ist durch technische Regulierungsstandards (RTS) der ESAs definiert.

Resilienztests

Alle Unternehmen müssen regelmäßige Resilienztests durchführen – von einfachen Vulnerability Assessments bis hin zu TLPT (Threat-Led Penetration Testing) für systemrelevante Institute. TLPT ist aufwändig: Es simuliert echte Angreiferszenarien auf Produktivsysteme und muss von akkreditierten Testanbietern durchgeführt werden.

Drittanbieter-Management

Verträge mit IKT-Drittdienstleistern müssen bestimmte Klauseln enthalten: Ausstiegsrechte, Audit- und Zugriffsrechte für Regulatoren, Mindeststandards für Sicherheit und Verfügbarkeit, sowie klare Regelungen zur Datenlokation. Fehlen diese Klauseln, müssen Verträge angepasst werden, was bei großen Cloud-Providern oft mühsam ist.

Informationsaustausch

DORA fördert aktiv den freiwilligen Austausch von Bedrohungsinformationen zwischen Finanzunternehmen. Das ist weniger eine operative Pflicht als ein regulatorischer Rahmen für kollektive Abwehrmaßnahmen.

Was DORA konkret für DevOps bedeutet

Hier wird es praktisch. DORA Compliance für DevOps ist kein abstraktes Konzept – sie verändert, wie Teams ihre Pipelines aufsetzen, dokumentieren und testen.

Auditierbare Deployment-Pipelines

DORA verlangt Nachweisbarkeit. Das bedeutet konkret: Jede Änderung an produktionsrelevanten Systemen muss dokumentiert, nachvollziehbar und im Zweifelsfall gegenüber Aufsichtsbehörden darstellbar sein.

Für CI/CD-Pipelines heißt das:

• Lückenlose Logs über alle Deployments inklusive Zeitstempel, auslösender Person und geänderter Komponenten
• Verpflichtende Code-Reviews und Approval-Workflows für Produktionsdeployments
• Klare Trennung zwischen Test- und Produktionsumgebungen mit dokumentierten Übergabeprozessen
• Änderungsmanagement nach ITIL-ähnlichen Prinzipien, auch wenn das Wort im DevOps-Umfeld manchmal Unbehagen auslöst

Das ist kein Hexenwerk, aber es erfordert, dass Teams ihre Toolchain gezielt darauf ausrichten, nicht erst dann, wenn ein Auditor fragt.

Recovery-Ziele: RTO und RPO unter regulatorischem Druck

DORA fordert definierte und getestete RTO (Recovery Time Objective) und RPO (Recovery Point Objective) für kritische Systeme. Die konkreten Werte schreibt die Verordnung nicht vor – aber sie müssen dokumentiert, regelmäßig getestet und nachweislich eingehalten werden.

Für DevOps-Teams bedeutet das: Disaster-Recovery-Szenarien dürfen nicht mehr nur in Konzeptpapieren existieren. Sie müssen regelmäßig geprobt werden, vorzugsweise automatisiert. Wer Kubernetes einsetzt, hat hier strukturelle Vorteile: Automatisches Failover, rollierende Updates und deklaratives State-Management helfen dabei, Recovery-Prozesse reproduzierbar zu machen.

Das Konzentrationsrisiko: Warum drei Hyperscaler ein Problem sind

Einer der bemerkenswertesten Aspekte von DORA ist die explizite Adressierung des Konzentrationsrisikos. Die Aufsichtsbehörden erkennen an, was in der Branche lange unausgesprochen war: Wenn nahezu die gesamte europäische Finanzinfrastruktur auf denselben zwei oder drei US-amerikanischen Cloud-Plattformen läuft, entsteht ein systematisches Risiko.

Fällt AWS in einer Region aus oder unterliegt einem US-Regierungszugriff, sind gleichzeitig Hunderte von Finanzdienstleistern betroffen. DORA verlangt keine sofortige Abkehr von den großen Anbietern, aber es verlangt, dass Unternehmen dieses Risiko aktiv managen: durch Diversifikation, durch Exit-Szenarien und durch eine ehrliche Bewertung ihrer Abhängigkeiten.

Cloud in Deutschland und Europa: DORA-Compliance durch Standortwahl

Ein Bereich, in dem lokale und europäische Cloud-Anbieter strukturell im Vorteil sind, ist das Drittanbieter-Management. DORA verlangt Audit-Rechte, die gegenüber großen Hyperscalern in der Praxis schwer durchsetzbar sind. AWS und Azure haben Standard-Verträge, individuelle Verhandlungen über Zugangsrechte für Regulatoren sind dort die Ausnahme, nicht die Regel.

Bei europäischen Anbietern, die ihren Betrieb in deutschen oder europäischen Rechenzentren führen, ist die Situation eine andere. Verträge können individuell gestaltet werden. Audit-Zugänge lassen sich konkret und rechtssicher vereinbaren. Und die physische Kontrolle über Daten und Infrastruktur liegt, im Gegensatz zu Angeboten unter dem CLOUD Act, ausschließlich im europäischen Rechtsraum.

Für Unternehmen, die DORA-konform aufgestellt sein müssen, ist das kein Detailpunkt. Es ist ein struktureller Unterschied in der Risikobewertung.

Exit-Strategien als Pflichtübung

DORA schreibt ausdrücklich vor, dass Unternehmen Exit-Strategien für ihre IKT-Dienstleister entwickeln und dokumentieren müssen. Das klingt nach Verwaltungsaufwand, ist aber technisch anspruchsvoll: Wer tief in proprietäre Cloud-Dienste integriert ist, kann nicht einfach wechseln.

Hier zahlt sich Container-basierte Infrastruktur aus. Workloads, die auf standardisierten Kubernetes-Manifesten laufen, sind portabler als solche, die tief auf proprietäre Managed Services eines einzelnen Providers aufsetzen. Das ist kein Argument gegen die Nutzung von Managed Services per se – aber es ist ein Argument dafür, Portabilität als Designprinzip zu behandeln, nicht als nachträglichen Gedanken.

Konkret: Wer heute schon Helm Charts, GitOps-Workflows und Cloud-agnostische Storage-Abstraktionen einsetzt, hat morgen weniger Probleme, einen regulatorisch geforderten Exit-Plan tatsächlich umzusetzen.

Fazit: DORA ist kein Bürokratiethema

DORA zwingt den Finanzsektor, etwas zu tun, das viele Teams längst hätten tun sollen: ihre IT-Resilienz ernsthaft zu dokumentieren, zu testen und zu diversifizieren. Die Verordnung schafft keinen neuen Aufwand aus dem Nichts – sie macht sichtbar, wo Lücken bestehen.

Für DevOps-Teams ist das eine Chance. Wer seine Deployment-Prozesse auditierbar macht, seine Recovery-Szenarien regelmäßig testet und seine Cloud-Abhängigkeiten bewusst gestaltet, baut ohnehin bessere Systeme. DORA gibt dafür jetzt auch einen regulatorischen Rahmen.

Die eigentliche Arbeit liegt in den Details: Vertragsklauseln, Dokumentationsprozesse, Test-Frequenzen, Dienstleister-Auswahl. Wer das strategisch angeht, statt nur eine Compliance-Checkliste abzuhaken, kommt gestärkt heraus.

Kubernetes-native, europäische Infrastruktur für regulierte Umgebungen

Wer nach einer Cloud-Plattform sucht, die DORA-Anforderungen strukturell unterstützt, mit klaren Audit-Rechten, deutschem Rechenzentrum und vollständiger Kubernetes-Portabilität, findet auf der lowcloud-Plattform eine praxistaugliche Grundlage. Keine Lock-in-Mechanismen, keine Graubereiche bei der Datensouveränität.