DORA-Verordnung für CTO und IT-Leitung: Konsequenzen für Architektur, Dienstleister und Roadmap
Was die EU-Verordnung zur digitalen operationalen Resilienz für Architektur, IKT-Dienstleister und Modernisierungs-Roadmap bedeutet. Für CTOs und IT-Leitungen im Finanzsektor, mit Abgrenzung zu den DORA-Metriken aus DevOps.
In vielen Finanzunternehmen liegt DORA bei Compliance und Informationssicherheit. Dort entstehen Richtlinien, Register und Nachweise. Die Folgen landen trotzdem beim CTO und bei der IT-Leitung. Ein Informationsregister ist nur so gut wie das Wissen über die eigene Systemlandschaft. Eine Exit-Strategie ist nur so gut wie die Schnittstellen, über die ein Anbieter ersetzt werden kann. Und eine Meldefrist von vier Stunden setzt voraus, dass der Betrieb einen Vorfall in dieser Zeit erkennt und einordnet.
Dieser Artikel übersetzt die Verordnung in Anforderungen an Architektur, Betrieb und Modernisierungsplanung. Er ersetzt keine rechtliche Beratung.
Zwei Abkürzungen, zwei Themen
Auf dieser Website steht DORA in vielen Artikeln für die vier Kennzahlen aus der DevOps-Forschung: Deployment-Frequenz, Durchlaufzeit, Fehlerrate und Wiederherstellungszeit. Hier geht es um etwas anderes. Der Digital Operational Resilience Act ist die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor. Sie gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten.
Erfasst sind unter anderem Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherungen, Kapitalverwaltungsgesellschaften und Handelsplätze. Für Leasing- und Factoringinstitute hat der deutsche Gesetzgeber den Anwendungsbereich mit dem Finanzmarktdigitalisierungsgesetz über § 1a Absatz 2a KWG erweitert. Die meisten Pflichten gelten dort erst ab dem 1. Januar 2027. Die Meldepflichten für IKT-Vorfälle gelten für diese Häuser aber schon seit dem 17. Januar 2025. Statt des vollen Risikomanagementrahmens aus Artikel 5 bis 15 gilt für sie der vereinfachte Rahmen nach Artikel 16, und bedrohungsgeleitete Penetrationstests entfallen. Prüfen Sie Stichtag und Umfang für Ihr Haus mit Ihrer Compliance, bevor Sie Prioritäten setzen.
Die beiden Themen hängen enger zusammen, als die Namensgleichheit vermuten lässt. Wer Wiederherstellungszeit und Fehlerrate misst, hat einen Teil der Nachweise für die Verordnung bereits in der Hand.
Was die Verordnung von der Technik verlangt
Die Pflichten der Verordnung verteilen sich auf fünf Bereiche. Für jeden Bereich gibt es eine technische Frage, die Compliance allein nicht beantworten kann.
| Bereich der Verordnung | Artikel | Was die Technik liefern muss |
|---|---|---|
| IKT-Risikomanagement | 5 bis 16 | Inventar der Systeme, Funktionen und Abhängigkeiten; Wiederherstellungspläne; jährliche Bewertung der Altsysteme |
| Behandlung und Meldung von IKT-Vorfällen | 17 bis 23 | Erkennung, Einstufung und Meldung innerhalb der Fristen |
| Tests der digitalen operationalen Resilienz | 24 bis 27 | Testprogramm; bedrohungsgeleitete Penetrationstests bei ausgewählten Unternehmen |
| IKT-Drittparteienrisiko | 28 bis 30 | Informationsregister, Vertragsklauseln, Exit-Strategien, Bewertung des Konzentrationsrisikos |
| Informationsaustausch | 45 | Freiwilliger Austausch über Bedrohungen; wer teilnimmt, zeigt das der Aufsicht an |
Artikel 31 bis 44 regeln daneben die Überwachung kritischer IKT-Drittdienstleister durch die europäischen Aufsichtsbehörden. Das betrifft die großen Cloud-Anbieter direkt. Ihre eigenen Pflichten ändert es nicht.
Das Leitungsorgan trägt nach Artikel 5 die Verantwortung für den gesamten Rahmen. Für Vorstand und Geschäftsführung heißt das: Technische Risiken sind Vorstandsthemen. Die Technik muss sie in einer Form liefern, die dort entschieden werden kann.
Das Informationsregister braucht eine Abhängigkeitskarte
Nach Artikel 28 Absatz 3 führen Finanzunternehmen ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen. Das Register unterscheidet, welche Dienstleistungen kritische oder wichtige Funktionen unterstützen. Die Aufsicht kann das vollständige Register jederzeit anfordern. Die BaFin sammelt es seit 2025 jährlich ein, zuletzt im März 2026 mit Stand 31. Dezember 2025.
Die Pflicht klingt nach Vertragsverwaltung. In der Praxis scheitert sie an einer anderen Stelle: Welche Funktion hängt an welchem System, und welcher Anbieter steckt darunter? Ein Kernsystem nutzt die Datenbank eines Herstellers, läuft auf der Infrastruktur eines Hosters, bezieht Marktdaten über eine Schnittstelle und schickt Dokumente an einen Archivdienst. Jede dieser Abhängigkeiten gehört ins Register. Trägt sie eine kritische oder wichtige Funktion, wird sie dort gesondert gekennzeichnet, und für sie gelten die strengeren Vertrags- und Exit-Pflichten. Bei einem über Jahre gewachsenen System weiß das oft niemand vollständig.
Artikel 8 verlangt deshalb ausdrücklich, dass Funktionen, Informationsbestände, IKT-Assets und ihre Abhängigkeiten identifiziert und dokumentiert werden. Diese Karte ist die Grundlage für das Register, für die Bewertung von Vorfällen und für jede Modernisierungsentscheidung. Wie Sie sie für ein undokumentiertes System erstellen, beschreibe ich im Artikel über die Architektur-Rekonstruktion mit KI-Agenten.
Exit-Strategien brauchen austauschbare Schnittstellen
Für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, verlangt Artikel 28 Absatz 8 Ausstiegsstrategien. Sie müssen dokumentiert, getestet und regelmäßig überprüft werden. Ein Ausstieg muss ohne Unterbrechung der Geschäftstätigkeit und ohne Verstoß gegen aufsichtsrechtliche Pflichten möglich sein. Artikel 30 ergänzt die Vertragsinhalte, darunter Kündigungsrechte, Unterstützung beim Übergang und Zugang zu den eigenen Daten.
Ob eine Exit-Strategie trägt, zeigt sich an drei Fragen.
- Wie tief ist der Anbieter im Kern verankert? Eine Datenbank hinter einer eigenen Datenzugriffsschicht lässt sich ersetzen. Fachlogik in herstellerspezifischen Workflow-Werkzeugen oder in den gespeicherten Prozeduren eines Produkts lässt sich nur mit einem Neubau ablösen.
- In welchem Format kommen die Daten zurück? Ein SaaS-Anbieter, der nur Bildschirmmasken und ein PDF-Archiv anbietet, lässt keinen Wechsel in vertretbarer Zeit zu. Verlangen Sie einen vollständigen, dokumentierten Export und testen Sie ihn vor Vertragsschluss.
- Wer kann den Wechsel durchführen? Ein Exit, den nur der bisherige Anbieter selbst umsetzen kann, ist keine Strategie.
Die Architekturmuster dafür sind bekannt: eine eigene Schnittstellenschicht vor fremden Systemen, offene Datenformate und Fachlogik im eigenen Code. Der Artikel zur API-First-Strategie beschreibt den Anti-Corruption Layer, der genau diese Trennung herstellt. Dass Abhängigkeiten auch im Open-Source-Bereich entstehen, zeigt die Kommerzialisierung von .NET-Bibliotheken.
Artikel 29 verlangt zusätzlich eine Bewertung des Konzentrationsrisikos. Wer Cloud, KI-Dienste und Identitätsverwaltung beim selben Hyperscaler bezieht, hat eine Abhängigkeit, die in der Risikobewertung sichtbar sein muss. Welche Funktionen beim Hyperscaler liegen und wie der Rückweg aussieht, gehört in diese Bewertung. Die Hybrid-Cloud-Strategie und die Einordnung von Azure AI Foundry mit EU-Datenresidenz behandeln diese Abwägung.
Meldefristen brauchen Observability
Schwerwiegende IKT-Vorfälle sind nach Artikel 19 zu melden. Die technischen Regulierungsstandards in der Delegierten Verordnung (EU) 2025/301 legen die Fristen fest. Die Erstmeldung ist innerhalb von vier Stunden nach der Einstufung als schwerwiegend fällig, spätestens 24 Stunden nachdem das Unternehmen von dem Vorfall Kenntnis erlangt hat. Der Zwischenbericht folgt spätestens 72 Stunden nach der Erstmeldung, der Abschlussbericht einen Monat nach dem Zwischenbericht. Fällt eine Frist auf ein Wochenende oder einen Feiertag, darf bis zwölf Uhr des nächsten Arbeitstags gemeldet werden. Für Kreditinstitute, zentrale Gegenparteien, Handelsplätze und Einrichtungen unter NIS2 gilt diese Erleichterung bei Erst- und Zwischenmeldung nicht. Erkennung und Einstufung müssen dort also auch samstags um drei Uhr funktionieren.
Diese Fristen setzen voraus, dass ein Vorfall innerhalb von Stunden erkannt und nach den Kriterien aus Artikel 18 eingestuft werden kann. Dazu gehören die Zahl der betroffenen Kunden, die Dauer, die geografische Ausbreitung, Datenverluste, die Kritikalität der betroffenen Dienste und die wirtschaftlichen Auswirkungen. Ein Betrieb, der erst durch Kundenbeschwerden von einer Störung erfährt, kann diese Einstufung nicht leisten.
Die technische Antwort darauf verbessert zugleich die Lieferfähigkeit. Sie besteht aus Monitoring je Geschäftsfunktion statt je Server, zentralen Protokollen, definierten Schweregraden und einem eingeübten Vorfallsprozess mit klarer Verantwortung. Wie sich die Ausbreitung eines Vorfalls begrenzen lässt, beschreibt der Artikel über resiliente Systeme. Mit Wiederherstellungszeit und Fehlerrate liefern die DORA-Metriken aus DevOps zwei Kennzahlen, die auch gegenüber der Aufsicht belegen, dass der Prozess funktioniert.
Artikel 11 und 12 verlangen zusätzlich Wiederherstellungspläne je kritischer oder wichtiger Funktion, die mindestens jährlich getestet werden, sowie Sicherungs- und Wiederherstellungsverfahren, deren Wiederherstellbarkeit geprüft wird. Für die Architektur heißt das: Je Geschäftsfunktion sind Wiederanlaufzeit und tolerierbarer Datenverlust festgelegt, und die Rücksicherung ist mindestens einmal im Jahr mit echten Datenmengen geprobt. Ein Altsystem, dessen Sicherung noch nie zurückgespielt wurde, fällt hier als Erstes auf.
Artikel 24 bis 27 verlangen außerdem ein Testprogramm. Für Unternehmen, die die Aufsicht dafür bestimmt, kommen mindestens alle drei Jahre bedrohungsgeleitete Penetrationstests hinzu. Ein Altsystem, das sich nicht gefahrlos testen lässt, wird in diesem Programm zum Befund.
Altsysteme sind in der Verordnung ausdrücklich benannt
Die Verordnung definiert in Artikel 3 den Begriff des Legacy-IKT-Systems. Gemeint ist ein System, das das Ende seines Lebenszyklus erreicht hat. Es lässt sich aus technischen oder kommerziellen Gründen nicht mehr aktualisieren oder korrigieren, oder der Hersteller unterstützt es nicht mehr. Trotzdem trägt es weiterhin Funktionen des Unternehmens.
Für solche Systeme verlangt Artikel 8 Absatz 7 eine eigene IKT-Risikobewertung, mindestens jährlich und zusätzlich vor und nach jeder Anbindung neuer Technologien, Anwendungen oder Systeme. Kleinstunternehmen und die über das KWG einbezogenen Institute mit vereinfachtem Rahmen sind von dieser Vorschrift ausgenommen. Für sie bleibt die jährliche Bewertung eine Empfehlung, die ich trotzdem gebe, weil die Aufsicht dieselben Fragen stellt. Für alle anderen wird der Weiterbetrieb eines nicht mehr unterstützten Kernsystems zu einem Vorgang mit Dokumentations- und Nachweispflicht. Wer bisher mit dem Argument gearbeitet hat, dass das alte System doch stabil läuft, braucht ab jetzt eine jährlich erneuerte Begründung mit Risikobewertung.
Das verschiebt die Abwägung aus dem Artikel .NET Framework weiterbetreiben oder migrieren? nicht grundsätzlich. Ein unterstütztes System bleibt eine Option. Support und Aktualisierbarkeit sind jetzt aber Kriterien mit aufsichtsrechtlichem Gewicht. In den Business Case gehört deshalb eine Zeile für die Kosten dieser Nachweise und für das Risiko, dass ein Prüfer den Weiterbetrieb nicht mehr akzeptiert.
Was das für die Modernisierungs-Roadmap bedeutet
Aus meiner Sicht ergeben sich daraus vier Prioritäten für die Planung.
- Beginnen Sie mit der Karte. Welche Systeme tragen kritische oder wichtige Funktionen, welche Anbieter stecken darunter, und welche davon sind Legacy im Sinne der Verordnung? Diese Übersicht brauchen Register, Vorfallsbewertung und Roadmap gleichermaßen. Ein Architektur-Review liefert sie als Arbeitsergebnis.
- Ordnen Sie Modernisierungsschritte nach der Kritikalität der Funktion. Ein unterstütztes Randsystem kann warten. Ein nicht mehr unterstütztes System hinter einer kritischen oder wichtigen Funktion bekommt den ersten Pilot.
- Bauen Sie Austauschbarkeit in jede neue Komponente ein. Die Muster dafür stehen oben. Bei neuen Komponenten sind sie günstig, nachträglich teuer. Das Strangler-Fig-Pattern erlaubt, diese Trennung schrittweise einzuziehen.
- Verbinden Sie Betriebskennzahlen mit den Nachweisen. Wiederherstellungszeit, Fehlerrate, Testabdeckung und die Ergebnisse des Testprogramms gehören in denselben Bericht an das Leitungsorgan.
Im Projektbericht zur Modernisierung einer Finanzplattform sehen Sie, wie Organisationsänderungen und Plattformmodernisierung bei einem regulierten Finanzierer zusammenwirkten. Die dort gemessenen Verbesserungen bei Wiederherstellungszeit und Fehlerrate sind genau die Werte, die auch gegenüber der Aufsicht zählen.
Was dieser Artikel nicht leistet
Drei Fragen entscheiden Sie mit Compliance und Recht, bei Bedarf mit Ihrer Aufsicht: Ist eine Funktion kritisch oder wichtig? Gehört ein Anbieter in das Register? Ist ein Vorfall schwerwiegend? Die verbindlichen Quellen sind die Verordnung (EU) 2022/2554 und die ergänzenden technischen Standards, etwa die Delegierte Verordnung (EU) 2025/301 zu den Meldefristen. Ein Architektur-Review bestätigt keine regulatorische Konformität. Er liefert die technische Grundlage, auf der diese Bestätigung möglich wird.
Nächster Schritt
Wenn das Register oder die Exit-Strategie an fehlendem Wissen über die eigene Systemlandschaft hängt, ist ein Architektur-Review der passende Einstieg. Für eine Beteiligung oder Übernahme im Finanzsektor prüft die Technical Due Diligence dieselben Fragen aus Käufersicht. Wenn Sie als CTO die Priorisierung mit Vorstand und Compliance abstimmen müssen, bietet sich das CTO-Sparring an.