DORA- aktueller Rechtsstand und Erkenntnisse aus Umsetzungsprojekten

Anastasiia Zheliabina, Finance Audit GmbH Wirtschaftsprüfungsgesellschaft, Ettlingen

Prof. Dr. Ralf Kühn, WP/CPA, Geschäftsführender Gesellschafter der Finance Audit GmbH Wirtschaftsprüfungsgesellschaft, Ettlingen

I. Regulatorische Entwicklung und Rechtslage

Das Gesetzgebungsverfahren für eine Verordnung über die digitale operationale Resilienz im Finanzsektor (sog. DORA-Verordnung) wurde Ende 2022 abgeschlossen.

Die DORA-Verordnung trat am 16. Januar 2023 (20 Tagen nach der Veröffentlichung) in Kraft und ist 24 Monate später anzuwenden. Auch die Umsetzungsfrist für die Richtlinie endet also am 17. Januar 2025.

Mit der DORA-Verordnung (Digital Operational Resilience Act) verfolgt die Europäische Kommission das Ziel, einen einheitlichen Rahmen für ein effektives und umfassendes Management von Cybersicherheits- und IKT-Risiken auf den Finanzmärkten zu schaffen. Dabei ist eindeutiger Schwerpunkt die Sicherstellung der Aufrechterhaltung eines widerstandsfähigen Betriebs im Falle einer schwerwiegenden Betriebsunterbrechung, die die Sicherheit des Netzes und der Informationssysteme gefährden könnte. Umgangssprachlich formuliert: Auch die EU nimmt (spät) zur Kenntnis, dass Klimawandel, weltpolitische Lage und die größer werdenden Unwägbarkeiten der Stabilität traditioneller Sicherheitsallianzen und -mechanismen neue, konsequenten Anforderungen in der Realität erfordern. Zum Beispiel durch steigende Cyberangriffe ist es für Finanzunternehmen notwendiger denn je, sich auf Vorfälle vorzubereiten und Maßnahmen zur Stärkung der Cyber-Resilienz einzuführen. Es ist also mit wesentlichen Anpassungen und Mehraufwänden zu rechnen, die die EU bewusst in Kauf nimmt. Sie sieht DORA gleichzeitig als große Chance für Finanzunternehmen, durch eine gestärkte Resilienz und einen konsistenten Reifegrad in Sachen Cybersicherheit zu einem signifikant höheren Sicherheitsniveau zu kommen und so massive mögliche Disruptionen bei den betroffenen Services und Infrastrukturen zu vermeiden.

Schwerpunkte der Anforderungen sind dabei insbesondere (keine fallabschließende Aufzählung):

Operational Resilience und Risikomanagement

Finanzunternehmen sind verpflichtet, ein umfassendes IKT-Risikomanagement einzurichten, einschließlich 

• Einrichtung und Pflege belastbarer IKT-Systeme und -Werkzeuge, die die Auswirkungen von IKT-Risiken minimieren,
• Schlüsselelemente wie Identifizierung, Klassifizierung und Dokumentation kritischer Funktionen,
• Kontinuierliche Überwachung aller Quellen von IKT-Risiken, um Schutz- und Präventionsmaßnahmen einzurichten,
• Sofortige Erkennung von anomalen Aktivitäten,
• Einführung spezieller und umfassender Business-Continuity-Richtlinien sowie Notfall- und Wiederherstellungspläne, einschließlich jährlicher Tests der Pläne, die alle unterstützenden Funktionen abdecken,
• Einrichtung von Mechanismen, um sowohl aus externen Ereignissen als auch aus eigenen IKT-Vorfällen zu lernen und sich weiterzuentwickeln.

Management von IKT-Vorfällen und Cyber Security

Finanzunternehmen sind verpflichtet:

• ein wirksames Verfahren zu entwickeln, um alle IKT-Vorfälle zu protokollieren/zu klassifizieren und schwerwiegende Vorfälle gemäß den in der Verordnung aufgeführten und von den europäischen Aufsichtsbehörden (EBA, EIOPA und ESMA) weiter spezifizierten Kriterien zu bestimmen,
• einen Anfangs-, Zwischen- und Abschlussbericht über IKT-bezogene Vorfälle vorzulegen,
• die Berichterstattung über IKT-bezogene Vorfälle anhand der von den ESAs entwickelten Standardvorlagen zu harmonisieren.

Digital Operational Resilience Testing

Die Verordnung verpflichtet alle Einrichtungen, dass sie

• jährlich grundlegende Tests von IKT-Werkzeugen und -Systemen durchführen,
• Schwachstellen, Mängel oder Lücken identifizieren, abmildern und umgehend beseitigen, indem sie Gegenmaßnahmen ergreifen,
• regelmäßig fortgeschrittene bedrohungsgesteuerte Penetrationstests (TLPT) für IKT-Dienste durchführen, die sich auf kritische Funktionen auswirken. Drittanbieter von IKT-Dienstleistungen sind verpflichtet, an den Tests teilzunehmen und vollständig zu kooperieren.

Governance und Management von Drittparteien

Die Finanzunternehmen sind verpflichtet: 

• eine solide Überwachung der Risiken zu gewährleisten, die sich aus der Inanspruchnahme von IKT-Drittanbietern ergeben,
• ein vollständiges Verzeichnis aller ausgelagerten Tätigkeiten, einschließlich gruppeninterner Dienstleistungen und aller Änderungen bei der Auslagerung kritischer Dienstleistungen an IKT-Drittanbieter, zu melden,
• das IT-Konzentrationsrisiko und die Risiken, die sich aus Sub-Outsourcing-Aktivitäten ergeben, zu berücksichtigen,
• Schlüsselelemente der Dienstleistung und der Beziehung zu IKT-Drittanbietern zu harmonisieren, um eine „vollständige“ Überwachung zu ermöglichen,
• sicherzustellen, dass die Verträge mit den IKT-Drittanbietern alle notwendigen Details zur Überwachung und Erreichbarkeit enthalten, wie z. B. eine vollständige Beschreibung des Leistungsumfangs, die Angabe der Standorte, an denen die Daten verarbeitet werden, usw.
• Kritische IKT-Drittdienstleister werden einem EU-Aufsichtsrahmen unterliegen, der Empfehlungen zur Minderung festgestellter IKT-Risiken aussprechen kann. Finanzunternehmen müssen die IKT-Drittrisiken ihres Dienstleisters berücksichtigen, wenn dieser die festgelegten Empfehlungen nicht befolgt.
• das Leitungsorgan legt klare Aufgaben und Zuständigkeiten für alle IKT-bezogenen Funktionen fest,
• das Leitungsorgan ermittelt die angemessene Toleranzschwelle für das IKT-Risiko des Finanzunternehmens,
• das Leitungsorgan weist angemessene Haushaltsmittel zu und überprüft diese regelmäßig, einschließlich Schulungen zu IKT-Risiken und -Kompetenzen für alle einschlägigen Mitarbeiter,
• das Leitungsorgan genehmigt und überprüft regelmäßig die Richtlinien in Bezug auf Vereinbarungen über die Nutzung von IKT-Diensten, die von IKT-Drittanbietern erbracht werden;
• das Leitungsorgan ist ordnungsgemäß über die mit IKT-Drittanbietern zur Nutzung von IKT-Diensten getroffenen Vereinbarungen, über relevante geplante wesentliche Änderungen in Bezug auf IKT-Drittanbieter sowie über die potenziellen Auswirkungen solcher Änderungen auf die kritischen oder wichtigen Funktionen, die Gegenstand dieser Vereinbarungen sind, unterrichtet und erhält eine Übersicht über die Risikoanalyse zur Bewertung der Auswirkungen dieser Änderungen.

Im 24-Monatszeitraum bis Anfang 2025 werden ferner die in der DORA-Verordnung vorgesehenen Technischen Regulierungsstandards durch Entwürfe von den Europäischen Aufsichtsbehörden vorbereitet und später von der Kommission verabschiedet. Die ersten Technischen Regulierungsstandards liegen nach Konsultation vor, weitere befinden sich im Konsultationsprozess. Diese Technischen Regulierungsstandards zeichnen sich insbesondere durch

• eine nicht immer klar erkennbare Struktur,
• zahlreiche Redundanzen,
• eine „verschachtelte Gliederung“,
• ein hohes Maß an Detailregelungen
• bei gleichzeitig hohem Anspruchsniveau

aus. DORA ist damit definitiv kein Programm zum Bürokratieabbau.

Mit Blick auf die Überlagerungen von Inhalten der DORA-VO mit bestehenden aufsichtlichen Anforderungen hatte die BaFin bereits früh angekündigt, die bestehenden Rundschreiben (BAIT, VAIT, KAIT, ZAIT) perspektivisch zu überarbeiten, um sicherzustellen, dass keine regulatorischen Dopplungen entstehen. Mittlerweile ist sogar kommuniziert worden, dass diese Rundschreiben insgesamt entfallen werden. DORA wird also tatsächlich – bei allen Abstufungen im Detail wie etwa bezüglich § 25c KWG – die zentrale Norm der IT-Regulatorik der nächsten Jahre sein.

Nicht nur direkt über EBA-Guidelines oder die Tätigkeit der Europäischen Zentralbank, sondern immer mehr branchenübergreifend über entsprechende europäische Verordnungen werden also im IT-Kontext nationale Regelungen erweitert, ersetzt oder ergänzt. Man denke hierzu an die Verordnung vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (EU-Datenschutz-Grundverordnung) oder aktuell insbesondere an den ersten EU-Rechtsrahmen für KI.

II. Praxiseinordnung und Hinweise aus der aktuellen Projektpraxis verschiedener DORA-Projekte

Aus den vorliegenden Erfahrungen einer Reihe von DORA-Programmen und DORA-Projekten ergeben sich einige aus unserer Sicht wichtige Praxistipps, Getreu dem alten menschlichen Motto, dass es besser ist, an den Fehlern anderer als an eigenen Fehlern zu lernen, seien hier die drei aus unserer Sicht wichtigsten Fehler dargestellt.

• Fehler Nr. 1: DORA als „Formal-Programm“
• Fehlende Ausstattung mit qualifiziertem Personal bei Banken im Kontext von DORA und MaRisk AT 7.1
• Das Phänomen beraterseitiger oder interessengeleiteter „Panikmache“ bei der Umsetzung von DORA

1. Fehler Nr. 1: DORA als „Formal-Programm“

Ein Projekt zur Umsetzung von DORA (Digital Operational Resilience Act) nur formal durchzuführen, indem lediglich Richtlinien geschrieben, Dokumente erzeugt und Berichte vorgelegt werden, ohne die eigentlich relevante materielle Sicherheitsebene zu berücksichtigen, ist ineffektiv und sinnlos aus mehreren Gründen. Diese können sowohl aus den Anforderungen von DORA als auch aus praktischen Erfahrungsberichten abgeleitet werden.

a) Gründe aus DORA

aa) Zweck von DORA

DORA zielt darauf ab, die operative Widerstandsfähigkeit digitaler Systeme und Netzwerke in der Finanzbranche zu stärken. Dies umfasst die Fähigkeit, Cyberbedrohungen zu erkennen, darauf zu reagieren und sich davon zu erholen. Der bloße formale Ansatz (nur Richtlinien ohne materielle Umsetzung) verfehlt den Kern dieses Ziel und kann daher auch für Prüfungszwecke keinen Mehrwert bieten – im Gegenteil. Aus Prüfersicht – und gerade aus Sicht der BaFin – sind nicht gelebte Richtlinien als regulatorisches „Schaulaufen“ in Verbindung mit materiellen Defiziten eine der gravierendsten Formen einer nicht ordnungsgemäßen Geschäftsorganisation und eines nicht wirksamen Risikomanagements. 

bb) Kernanforderungen von DORA

DORA fordert eine umfassende Risikomanagementstrategie, die nicht nur Richtlinien, sondern auch technische und organisatorische Maßnahmen umfasst. Dies bedeutet, dass Unternehmen aktive Schutzmaßnahmen implementieren und kontinuierlich überwachen müssen.

cc) Regelmäßige Tests und Bewertungen

DORA verlangt regelmäßige Tests und Bewertungen der IT-Systeme und -Kontrollen, einschließlich Penetrationstests und Ausfallsimulationen. Diese praktischen Tests sind wesentlich, um Schwachstellen zu identifizieren und zu beheben. Richtlinien allein können dies nicht leisten.

b) Praktische Erfahrungsberichte

aa) Vorherige Vorfälle und Lehren

Zahlreiche Sicherheitsvorfälle in der Vergangenheit zeigen, dass theoretische Richtlinien ohne praktische Umsetzung wenig wirksam sind. Beispielsweise haben Cyberangriffe auf große Unternehmen und Finanzinstitute oft Lücken in der tatsächlichen Sicherheitsinfrastruktur aufgedeckt, trotz bestehender Richtlinien.

bb) Kosten von Sicherheitsverletzungen

Die Kosten und Folgen von Sicherheitsverletzungen sind erheblich, einschließlich finanzieller Verluste, Reputationsschäden und regulatorischer Strafen. Unternehmen, die nur auf formale Richtlinien setzen, riskieren diese Kosten, da die materielle Sicherheit vernachlässigt wird. Beispielsweise zeigen Studien und Berichte von Unternehmen, die auf eine starke Kombination aus Richtlinien und technischen Maßnahmen setzen, deutlich höhere Widerstandsfähigkeit und schnellere Erholungszeiten nach Vorfällen. 

Ein formal orientiertes Projekt zur Umsetzung von DORA, dass nur Richtlinien schreibt und die materielle Sicherheitsebene vernachlässigt, ist ineffektiv, da es nicht den Kernanforderungen und dem eigentlichen Zweck von DORA gerecht wird. Materielle Sicherheitsmaßnahmen und regelmäßige Tests sind unerlässlich, um echte operative Widerstandsfähigkeit zu gewährleisten. Erfahrungsberichte zeigen deutlich, dass Unternehmen, die sowohl formale als auch materielle Sicherheitsmaßnahmen integrieren und diese aufeinander unternehmenspassend abstimmen, besser gegen Cyberbedrohungen gewappnet sind und somit langfristig erfolgreicher operieren.

Das aber bedeutet auch – es gilt nicht „Viel hilft viel“. Gerade DORA-Programme, die durch hohe Beraterzahlen verschiedener Beratungsunternehmen „nebeneinander“ geprägt sind, weisen oft eine Fülle, Komplexität und Widersprüchlichkeit erzeugter DORA-Policies und DORA-Dokumentationen auf, die nicht zum Unternehmen passen, nicht von den Mitarbeitenden gelebt werden können und nicht akzeptiert werden.

2. Fehlende Ausstattung mit qualifiziertem Personal bei Banken im Kontext von DORA und MaRisk AT 7.1

Die Umsetzung von DORA erfordert bei Banken qualifiziertes Personal in IT, Fachbereichen sowie bei den Informationssicherheitsbeauftragten, Datenschutzbeauftragten und der Internen Revision. „Keine Arme – keine Kekse“ ist leider auch mit DORA und mit KI noch nicht aufzulösen. Hier einige Beispiele:

a) Anforderungen an das Risikomanagement und operative Resilienz

DORA fordert, dass Banken eine umfassende digitale operative Widerstandsfähigkeit sicherstellen. Dies umfasst u. a. Risikomanagement, kontinuierliche Überwachung und Reaktionsmechanismen auf Cyberbedrohungen. Laut Art. 5 von DORA müssen Finanzinstitute „über geeignete Governance- und Kontrollstrukturen verfügen, die mit angemessenen Ressourcen ausgestattet sind, um die operative Resilienz zu gewährleisten.“ Institute, die glauben, seit Jahren gestiegene tatsächliche und regulatorische Anforderungen mit immer demselben Personalbestand abdecken zu können oder die hoffen, durch simples Outsourcing bisheriger Tätigkeiten (die oft eher Betriebsleistungen waren) die komplexen Tätigkeiten nach DORA „straffen“ zu können, unterliegen einer täuschenden Hoffnung. 

b) Durchführung regelmäßiger Tests

DORA schreibt vor, dass Banken regelmäßige Penetrationstests und Bewertungen durchführen müssen, um Schwachstellen zu identifizieren und zu beheben. Diese Aufgaben erfordern spezialisierte Fähigkeiten, die nur durch qualifiziertes Personal sichergestellt werden können (Art. 10), auch dann, wenn die eigentlichen Tests extern vergeben werden. Wer soll sonst die Ergebnisse interpretieren und in bankindividuelle Maßnahmen überführen? 

c) Qualifikationsanforderungen

MaRisk AT 7.1 betont die Notwendigkeit, dass Institute „über eine angemessene personelle und sachliche Ausstattung verfügen.“ Dies bedeutet, dass alle relevanten Bereiche, insbesondere die Risikocontrolling-Funktion, mit qualifiziertem Personal ausgestattet sein müssen. 

d) Praktische Konsequenzen und Erfahrungsberichte

aa) Erhöhte Anfälligkeit und Risiko von Sicherheitsvorfällen

Banken, die nicht ausreichend in qualifiziertes Personal investieren, sehen sich einem höheren Risiko ausgesetzt. Studien und Berichte zeigen, dass fehlende Qualifikationen zu ineffektiven Sicherheitsmaßnahmen führen, was die Anfälligkeit für Cyberangriffe und Datenverstöße erhöht.

bb) Einhaltung regulatorischer Anforderungen

Erfahrungsberichte aus der Praxis verdeutlichen, dass Banken, die die Anforderungen von DORA und MaRisk AT 7.1 nicht erfüllen, mit hohen Strafen und regulatorischen Maßnahmen konfrontiert werden können.

cc) Sunk Costs und nachhaltige Investitionen: Ineffizienz und wiederkehrende Kosten

Projekte, die ohne qualifiziertes Personal durchgeführt werden, sind oft ineffektiv und erfordern Nacharbeit auch an vermeintlich bereits erledigten Aufgaben und bereits bestehenden Artefakten. Dies führt zu wiederkehrenden Kosten und ineffizientem Ressourceneinsatz, die als „sunk costs“ betrachtet werden können, gerade dann, wenn z. B. „halbfertige DORA-Projekte“ auf unbefriedigenden Sachständen quasi „eingefroren“ werden, weil eine angemessene nachhaltige Stellenausstattung für die aufnehmenden Linieneinheiten nicht besteht. 

3. Das Phänomen beraterseitiger oder interessengeleiteter „Panikmache“ bei der Umsetzung von DORA

Ein weiteres Problem, das bei der Umsetzung von DORA auftritt, ist „Panikmache“ durch interne Akteure oder Berater, die den Eindruck erweckt, als ob „alles neu erfunden werden müsse“. In Wirklichkeit stellt DORA eine evolutionäre, wenn auch weitreichende Weiterentwicklung bestehender Richtlinien wie BAIT (Bankaufsichtliche Anforderungen an die IT) dar.

a) Gründe aus DORA

aa) Evolution statt Revolution

DORA baut auf bestehenden Regelwerken wie BAIT auf und erweitert diese um spezifische Anforderungen zur operativen Resilienz. Artikel 1 von DORA betont, dass die Verordnung darauf abzielt, „die digitalen operationellen Risiken zu bewältigen, indem bestehende Anforderungen harmonisiert und verstärkt werden.“

bb) Kontinuierliche Weiterentwicklung

Die Anforderungen von DORA sind als kontinuierliche Weiterentwicklung bestehender Sicherheits- und Risikomanagementmaßnahmen zu verstehen. Banken, die bereits BAIT-konform arbeiten, haben viele der grundlegenden Strukturen und Prozesse bereits implementiert und müssen diese nun an die spezifischen DORA-Anforderungen anpassen. Entsprechende Einschätzungen wurden z. B. in den Fach- und Expertengremien der BaFin erarbeitet und erörtert, die zeigen, dass nur einige der im Mittelpunkt von DORA stehenden Themenfelder tatsächlich hohe Umsetzungsaufwände und Niveausteigerungen erfordern. 

b) Praktische Erfahrungsberichte

aa) Effiziente Anpassungen statt Neuanfang

Erfahrungsberichte von Banken zeigen, dass Institutionen, die bereits nach BAIT arbeiten, durch gezielte Anpassungen und Erweiterungen ihrer bestehenden Systeme und Prozesse die DORA-Anforderungen erfüllen können. Dies reduziert den Aufwand und vermeidet unnötige „Panikmache“.

bb) Erfolgsbeispiele

Banken, die schrittweise Anpassungen vorgenommen haben, berichten von einer erfolgreichen und vergleichsweise stressfreien Implementierung der DORA-Anforderungen. Diese evolutionäre Herangehensweise zeigt, dass eine umfassende Neuausrichtung oft nicht erforderlich ist.

Und hierzu auch eine realistische Einstufung – DORA ist natürlich bis Januar 2025 umzusetzen. Aber: Kein reguliertes Unternehmen wird aus heutiger Sicht tatsächlich zu diesem Zeitpunkt alle DORA-Anforderungen 100 % und wirksam umgesetzt haben. Wie bei allen vorherigen regulatorischen Verschärfungen/Ergänzungen, etwa der BAIT, wird also der nötige Reifegrad über mehrere Reifegradstufen erreicht werden müssen, bei denen es mehr auf nachhaltige Konsequenz und „Dranbleiben“ als auf den einen großen, schnellen „Wurf“ mit enormem einmaligem Kraftakt ankommt. Es ist also zu vermeiden, dass DORA „als neue regulatorische Sau durchs Dorf getrieben wird“ … die dann am anderen Ortsende wieder verschwindet. Die Ziele und Themen von DORA werden (leider) ja nicht verschwinden. 

c) Nachteile der „Panikmache“

aa) Übertriebene Kosten und Ressourcenverschwendung

Die übertriebene Darstellung, dass „alles neu erfunden werden müsse“, führt zu unnötigen Kosten und einer ineffizienten Nutzung von Ressourcen. Banken investieren möglicherweise in teure Beratungsleistungen und überdimensionierte Projekte, die letztlich keine zusätzlichen Vorteile bringen.

bb) Verlust von Fokus und Prioritäten

Panikmache kann dazu führen, dass Banken den Fokus auf wesentliche Sicherheitsmaßnahmen verlieren und stattdessen Ressourcen auf unwichtige oder redundante „Pseudo-Neuerfindungen“ lenken. Dies beeinträchtigt die Effizienz und Wirksamkeit der Sicherheitsmaßnahmen.

cc) Verlust von Akzeptanz

Letztlich gilt: Nur ein effizientes und effektives Zusammenwirken von Kunden, Mitarbeitenden, Führungskräften und Management einer Bank ist in der Lage, das nötige Sicherheitsniveau tatsächlich zu erreichen. Wenn DORA zu Lasten von „Kundenservice“ oder als internes Verhinderungs-Programm gestaltet wird, ist der erforderlichen Sicherheit definitiv nicht gedient.

PRAXISTIPPS

• Führen Sie keine „Formal“-Diskussionen, sondern treffen Sie materiell und regulatorisch gut abgewogene Managemententscheidungen über Verwendung, Chancen und Risiken von DORA-Maßnahmen und legen Sie diesen Maßstab auch bei Prüfungen als Interne Revision an.
• Sichern Sie sich jetzt die nötige praktische und regulatorische Expertise und das erforderliche Personal für eine nachhaltige und dauerhafte DORA-Compliance.
• Vertragliche Regelungen und Dokumentationen zu Anforderungen, Informationsflüssen, Change Requests und Informationssicherheit/Datenschutz sind möglichst früh praxistauglich auszugestalten und erfordern sowohl juristischen als auch betriebswirtschaftlich-praktischen Sachverstand.
• DORA ist weder der Anfang noch das Ende der IT-bezogenen Regulatorik und nicht die „Neuerfindung des Rades“, sondern ein – wenn auch konsequenter – Schritt der inhaltlichen Weiterentwicklung und Harmonisierung.
• Denken Sie auch DORA in „Reifegraden“ – speziell in der Wirksamkeit und in der Schwerpunktbildung aus den vorhandenen finanziellen und personellen Ressourcen.