DORA – Regulation der Technologien im Finanzsektor

Key Facts

• Mit dem Digital Operational Resilience Act (DORA) will die EU den Finanzsektor widerstandsfähiger gegen IT-Störungen und Cyberangriffe machen
• DORA liegt im Entwurf vom 23. Juni 2022 vor, Trilog Verfahren noch nicht abgeschlossen, Inkrafttreten zum Jahreswechsel erwartet
• DORA wird bestehende Anforderungen an Risikomanagement moderner Technologien EU-weit harmonisieren
• IKT-Drittanbieter wie beispielsweise Hyperscaler oder Corebanking-Provider werden zukünftig in gleicher Art geprüft, wie bisherige Aufsichtsobjekte Banken und Versicherungen
• Hyperscaler werden zentral durch ESA und die nationale Aufsicht geprüft und zahlen für Aufsichtstätigkeit
• DORA wird mehr MINT-Expertise in den Leitungs- und damit auch Aufsichtsgremien einfordern
• Zertifizierungsfähige Informationssicherheitsmanagementsysteme (ISMS) werden europäische Best Practice im Finanzsektor
• Zukünftig erhöhte Verwaltungsaufwände durch neue Berichtspflichten und Genehmigungsverfahren
• Als kritisch deklarierte Finanzunternehmen werden turnusmäßig ihre digitale Betriebsstabilität durch bedrohungsorientierte Penetrationstests gemäß TIBER EU beweisen Hybride IT-Prüfung als Standard für manuell-automatisierbare Prüfungshandlungen zu etablieren
• Der Vergleich der Entwurfsversion vom 26.09.2020 und vom 23.06.2020 gibt Hinweise auf Lobbytätigkeiten und weißt große Änderungen auf. 

Einleitung

Mit dem „Digital Operational Resilience Act” (DORA) wird ein EU-Rechtsrahmen „über die Betriebsstabilität digitaler Systeme des Finanzsektors“ erschaffen. Grundsätzlich fasst DORA bestehende Regelungen zu Sicherheitsmaßnahmen, Meldewesen und Überprüfung von Auslagerungen zusammen, erweitert und vertieft diese jedoch an ausgewählten Stellen. IKT -Drittanbietern werden inkludiert, womit der so genannten federführenden Aufsichtsinstanz (je nach Art des Aufsichtsobjekts EBA, ESMA oder EIOPA) durch Möglichkeiten der Intervention wie bspw. Zwangsgeldern die nötigen Mittel zu Durchsetzung von Standards in der Finanzmarktstabilität an die Hand gegeben werden. Als umfassendes Regelwerk für die Informationssicherheit wird DORA in den drei Dimensionen Organisation, Regulatorik und IT in Finanzunter-nehmen eine vergleichbar große Wirkung entfalten wie die DSGVO im Schutz persönlicher Daten seit ihrer Geltung im Mai 2018. Während die DSGVO für die gesamte Wirtschaft und Verwaltung gilt, aber nur den Schutz personenbezogener Daten adressiert, wird DORA „nur“ für alle Finanzunternehmen und IKT-Drittanbieter gelten – hierunter fallen auch diverse Verwaltungsentitäten, allerdings hat DORA den Schutz aller Informationen zum Ziel, die personenbezogenen Daten einge-schlossen. Abbildung 1 spannt illustrativ den Rahmen in den drei Dimensionen Organisation, Regulatorik und IT für die drei Entitäten Versicherung, Regulator und Neobank auf.

Abbildung 1: DORA greift in Reifegrad einer Organisation in den drei Dimensionen Organisation, Regulatorik und IT ein

Es gelten zwar die europäischen Vorschriften mit Regelungen zur IKT-Sicherheit und Meldewesen im Finanzsektor wie NIS-Richtlinie, DSGVO, PSD 2 inklusive diverser RTS (Regulatory Technical Standards) in jedem Mitgliedsland des europäischen Wirtschaftsraums, jedoch legen eine Vielzahl von Ländern, so auch Deutschland, diese Vorgaben national aus. In Deutschland muss der Finanzsektor legale Anforderungen rund um die Informationssicherheit sowie das Risikomanagement aus MaRisk , XAIT  (BAIT  / KAIT  / VAIT  / ZAIT ), GeschGehG , FISG  und IT-SiG  2.0 erfüllen (siehe Abbildung 2). Diese „Mehrfachregulierung“ der gleicher IKT in verschiedenen Regelwerken provoziert Ineffizienzen bis hin zu Ineffektivität aufgrund von Überschneidungen, Inkonsistenzen, mehrfachen und sogar sich widersprechenden Vorgaben zur Sicherheit der IKT. 

Intendiert scheint, dass DORA europäische und nationale Vorschriften harmonisieren sowie potenziell obsolet machen soll. Es wird sich zeigen, ob die Mitgliedsstaaten auf eigene Regelungen verzichten, da Verwaltungsstrukturen einmal erreichte Machtgefüge selten widerstands-los aufgeben. Hier setzt DORA an und ermöglicht grenzüberschreitend tätigen Finanzunter-nehmen durch vergleichbare Vorschriften und die EU-weite Anerkennung von Prüfungen das internationale Geschäft erleichtern. Daher ist der DORA-Entwurf aus Perspektive einer weiter-gehenden europäischen Integration sowie der Steigerung der Wettbewerbsfähigkeit der Teilnehmer im europäischen Finanzplatz zu unterstützen.

Abbildung 2: Regulierungsrahmen für den Finanzsektor, Sicherheit (Zeile 7) im Fokus, DORA im Zentrum

Im Folgenden wird der Inhalt der DORA eingehend vorgestellt. Es werden Herausforderungen für den Finanzsektor aus Sicht der Autoren aufgezeigt. Folgend sind Hinweise zur Herstellung der Compliance zu DORA angerissen. DORA subsummiert Anforderungen an die Sicherheit im Finanzsektor, weitet den Kreis der Aufsichtsobjekte aus und stellt in einzelnen Sicherheitsbereichen neue und höhere Anforderungen auf.

Inhalt der DORA

Während die drei Artikelblöcke „Anforderungen an IKT-Risikomanagement“, „Meldung von IKT-Vorfällen“ sowie „Prüfung der digitalen Betriebsstabilität“ Finanzunternehmen  adressieren, reguliert der Artikelblock „Prüfung des Risikos durch IKT-Drittanbieter“ auch die Technologieanbieter. Mit 15 Artikeln werden detailliert die Anforderungen an IKT-Drittanbieter wie beispielsweise Hyperscaler formuliert. Auch Funktionsanbieter für Kernbankensystemlösungen  werden in den Geltungsbereich einbezogen.

Kapitel I „Allgemeine Bestimmungen (Artikel 1 bis Artikel 3)Geltungsbereich (Artikel 2)

Artikel 1 erfährt in der Version von DORA vom 24.09.2020 mit Absatz 2a eine interessante Ergänzung zur Version der DORA vom 26.09.2020: Demnach soll DORA nicht die Zuständigkeit der Mitgliedstaaten für wesentliche staatlichen Aufgaben in den Bereichen öffentliche Sicherheit, Verteidigung und nationale Sicherheit berühren. Es ist das gute Recht eines Staates sich auch im digitalen Raum zu verteidigen. Interessant ist diese Regelung aber aus einem ganz anderen Grund: Aus der Entwicklung der DSGVO13 über die Rechtsprechung des EuGH zur Verarbeitung von personenbezogenen Daten europäischer Bürger in den USA – Stichwort Schrems 2 – kann
sozusagen live beobachtet werden, welche Zerwürfnisse die Frage der nationalen Sicherheit im transatlantischen Verhältnis erzeugen kann. Nicht wenige Datenschützer sind der Auffassung, dass Europa im Datenschutz von den USA etwas verlangt, was es von sich selbst nicht verlangt. Der politische Streit im Datenschutz ist weiterhin nicht gelöst und hängt als Damoklesschwert der Datenschutzaufsicht weiterhin über der deutschen Wirtschaft. Es bleibt abzuwarten wie sich Artikel 1 Abs. 2a sicherheitspolitisch und wirtschaftlich auswirken wird.

Geltungsbereich (Artikel 2)

DORA weitet den Regulierungsrahmen von den „klassischen“ Regulierungsobjekten Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen und Versicherungs- und Rückversicherungsunternehmen auf ca. 21 verschiedene Arten von Finanzunternehmen  auf. Besonders bedeutsam ist dabei das neue Regulierungsobjekt „IKT-Drittanbieter“.Erst mit der im Trilog verabschiedeten Version wird der endgültige Adressatenkreis feststehen. Aber eine interessante Entwicklung kann bereits jetzt gesehen werden: Während in der Version vom 24.09.2020 „Abschlussprüfer und Prüfungsgesellschaften“ noch Aufsichtsobjekt waren, sind sie das in der aktuellen Entwurfsversion vom 23.06.2022 nicht mehr. Das ist angesichts der schützenswerten Informationen welche Abschlussprüfer und Prüfungsgesellschaften generieren und verarbeiten nicht nachvollziehbar. Ab jetzt wird die Version von DORA vom 24.09.2022 „Version 2020“ und die Version vom 23.06.2022 entsprechend „Version 2022" genannt.

Das Feld der Aufsichtsobjekte wird deutlich vergrößert und stellt die Aufsichtsstrukturen vor neue quantitative und qualitative Aufgaben. Zudem müssen Finanzunternehmen, die als bedeutend eingestuft werden, so genannte „bedrohungsorientierte Penetrationstests“ durchführen (siehe Ausführungen zu Artikel 23). Mit Artikel 3a kodifiziert die Version 2022 das für BaFin-Aufsichtsobjekte lang bekannte Proportionalitätsprinzip. 
Abbildung 3 zeigt zusammengefasst die wesentlichen Inhalte des Entwurfs von DORA .

Abbildung 3: Themengebiete DORA nach Artikeln gruppiert 

Kapitel II "IKT-Risikomanagement" Abschnitt (Artikel 4, Steuerung und Organisation)

DORA hebt die Bedeutung der IKT durch eine optimierte Abstimmung der Geschäftsstrategien von Finanzunternehmen mit dem IKT-Risikomanagement an. Zweckdienlich werden die Leitungsorgane der Aufsichtsobjekte eine entscheidende und aktivere Rolle bei der Steuerung des IKT-Risikomanagements übernehmen müssen. Es wird der Begriff der Cyberhygiene eingeführt, die durch die Leitungsorgane durchzusetzen ist. In letzter Konsequenz wird die Geschäftsleitung für die Steuerung von IKT-Risiken verantwortlich gemacht. Dies ist kein neuer Umstand, denn aus Sicht der Aufsicht ist das Wesen eines Finanzunternehmens das Management von Risiken, jedoch wird nun mit IKT-Risiken eine Risikoart exponiert.

Das Leitungsorgan ist vollständig über IKT-Risiken zu informieren. Finanzunternehmen überwachen IKT-Drittanbieter inklusive der damit verbundenen Risikoexposition. Zudem müssen die Mitglieder des Leitungsorgans regelmäßig Fachschulungen absolvieren, um ausreichende Kenntnisse und Fähigkeiten zu erwerben. Ebenso ist dieses Wissen aktuell zu halten, damit IKT-Risiken und deren Auswirkungen auf die Geschäftstätigkeit des Finanzunternehmens verstanden und bewertet werden können. Auf der Seite des Leitungsorgans wird die DORA zusammenfassend mehr MINT -Expertise erzwingen. Diese Entwicklung wird sich in die Aufsichtsgremien fortschreiben. die Version 2022 erfährt im Artikel 4 mit Absatz 2a eine einzige Ergänzung: Das Leistungsorgan muss Strategie einführen, die darauf abzielen, die Aufrechterhaltung eines hohen Standards für Vertraulichkeit (C). Integrität (I) und Verfügbarkeit (A) von Daten zu gewährleisten. Das ist ein starker Hinweis auf das ISMS und angesichts dessen Streichung aus Artikel 5 eine Regulierungs-Burleske.

Kapitel II "IKT-Risikomanagement" Abschnitt II (Artikel 5 bis Artikel 14)

Die Anforderungen an das IKT-Risikomanagement orientieren sich an einschlägigen internationalen, nationalen und branchenspezifischen Normen, Leitlinien und Empfehlungen und betreffen spezifische Funktionen des IKT-Risikomanagements (Identifizierung, Schutz und Prävention, Erkennung, Gegenmaßnahmen und Wiederherstellung, Lernen sowie Weiterentwicklung und Kommunikation). Diese 10 Artikel umfassen Themengebiete operativer Betriebssicherheit (hier „stabile IKT-Systeme und Instrumente“ genannt), welche Auswirkungen von IKT-Risiken minimiert, kontinuierlich Ursachen von IKT-Risiken ermittelt, Schutz- und Präventionsmaßnahmen ergreift, anormale Aktivitäten umgehend aufdeckt, Strategien für die Fortführung des Geschäftsbetriebs sowie Notfall- und Wiederherstellungspläne einrichtet. Ferner erstrecken sich diese Anforderungen auf die Sicherheit und Robustheit physischer Infrastrukturen und IKT-Drittanbieter von Finanzunternehmen. 

Doch einige Anforderungen verdienen eine genauere Betrachtung: 

Während die Version 2020 noch ein ISMS forderte, wurde dies aus Artikel 5 im Absatz 4 entfernt. Diese Streichung ist nicht nur operativ irreführend, sondern auch ein
Widerspruch zur Regulierung in Deutschland aus XAIT18 heraus: Die BaFin verpflichtet die Aufsichtsobjekte zurecht auf ein ISMS in BAIT (Vorbemerkung 3) für Kreditinstitute resp. für Kapitalverwaltungsgesellschaften (Vorbemerkung 2 der KAIT), Versicherungen (Vorbemerkung 6 der VAIT) und für Zahlungs- und E-Geld-Institute (Vorbemerkung 3 der ZAIT). Ein vollumfängliches ISMS ist in der Praxis selten implementiert. Diesem Umstand wird DORA durch die europäische Harmonisierung von IKT-Anforderungen begegnen , was der Durchsetzung von ISMS förderlich sein wird. Und hier wird der Widerspruch schlagend, denn DORA fokussiert auf:

• Risikomanagement
• Meldung von schwerwiegenden IKT-Vorfällen
• Digitale Betriebsstabilität und ihre Prüfung durch bedrohungsorientierte Penetrationstests und 
• Steuerung der IKT-Drittanbieter

Das sind wesentliche Elemente eines ISMS, die zu ihrer Umsetzung Vorarbeiten und ergänzender Arbeiten bedürfen wie bspw. Kryptographie und physische Sicherheit. Diese additiven Arbeiten sind auch Bestandteile eines ISMS. Summa sumarum verlangt DORA in praxi ein umgesetztes ISMS, ohne es explizit im Gesetzestext zu fordern. Trotz Streichung von Artikel 5 Abs. 4 und des zweiten Teils des Erwägungsgrundes 39, der auf Nutzung von „international anerkannten technischen Normen (z B I O)“ verwies, wurden genügend Hinweise auf ein ISMS in der Version 2022 beim Streichen übersehen wie z.B. im Erwägungsgrund 36. Schlagend ist wie gesagt die Notwendigkeit operative Risiken durch ein Managementsystem zu ordnen.

Die Autoren postulieren, dass ein ISMS im Rahmen einer nächsten Regulierungsrunde in 3 bis 5 Jahren für wichtige Prozesse zertifiziert werden muss. Diese Entwicklung wird durch die geforderten bedrohungsorientierten Penetrationstests begünstigt, denn damit steigen die Anforderungen an den Schutz von Informationen und damit das Management der Schutzmaßnahmen.

Artikel 5 und Absatz 9a fordern mit der „Strategie für digitale Resilienz“ die Erstellung einer Strategie und stellt gleichzeitig Vorgaben für deren Mindestinhalte auf. Die Strategie wird mit Indikatoren zur Messung und Überwachung der festgelegten strategischen Ziele auszustatten sein. Damit erfährt die IKT eine enorme Aufwertung im Vergleich zu bisherigen strategischen Zielen wie Geschäft in der Geschäftsstrategie, Auslagerung resp. Ausgliederung in der Outsourcing-Strategie und Risiken in der Risikostrategie. Diese neue Strategie muss auch die Nutzung mehrerer IKT-Drittanbieter für wesentlichen Abhängigkeiten begründen. Eine resiliente IKT ist nun als gleichwertige notwendige Bedingung für das Geschäft des Finanzsektors anerkannt und muss in einer separaten Strategie behandelt werden. Im Lichte der IKT als bestimmenden Faktor im Finanzgeschäft ist das eine begrüßenswerte Entwicklung.

Artikel 5 Absatz 10 ermöglicht die Überprüfung der Einhaltung der Anforderungen an das IKT-Risikomanagement an Dritte zu delegieren. Die in der Version 2020 noch enthaltene Genehmigung der Delegation durch die zuständige Behörde ist in der Version 2022 entfallen, was im Sinne der Bürokratie zu begrüßen ist. Diese Delegation birgt eine interessante Zuspitzung: 

• Finanzunternehmen lagern unter Bedingungen eine sehr sensible 2nd LoD-Funktion aus. Hier muss national abgewartet werden wie sich das mit dem Verbot der Auslagerung der ISB-Funktion für Banken (BAIT II Tz. 4.6), Kapitalverwaltungsgesellschaften (KAIT Tz. 29), Versicherungen (VAIT II Tz. 4.7) und für Zahlungs- und E-Geld-Instituten (ZAIT II Tz. 4.6) sowie der Risikocontrolling-Funktion gemäß MaRisk AT 4.4.1 „verträgt“.

Artikel 6 (IKT-Systeme, -Protokolle und -Instrumente) hebt gesamthaft auf die Anwendung des Standes der Technik ab und formuliert insofern keine Neuen Anforderungen. Jedoch kann der Begriff „technologisch stabil“ (Absatz 1 lit. d) als unscharf formuliert angesehen werden.  Unter Beachtung der Ausführungen in Artikel 6 als „Beachtung stabiler Lieferketten“ gedeutet, da nicht nur das Schutzziel Verfügbarkeit, auch die Schutzziele Authentizität und Integrität (bei Software) adressiert werden, dürfte der Regelungsraum und das einhergehende Rational hinreichend exakt beschrieben sein. Mit Absatz 2 in der Version 2022 wurde der Hinweis auf ein ISMS der Version 2020 entfernt. 

Artikel 7 (Identifizierung) fordert mit detaillierten Ausführungen eine Strukturanalyse/ Prozesslandkarte (Absatz 1), ein Risikomanagement (Absatz 2), Risikoanalysen bei jeder wesentlichen Änderung (Absatz 3), die Kenntnis aller Ressourcen, teilweise in Verzeichnissen (Absatz 6), wie Konten, Netze, Hardware, kritische physische Ausrüstung, Konfigurationen, Verbindungen und Interdependenzen (in Absatz 4) und der Prozesse bei IKT-Drittanbietern (in Absatz 5). Absatz 7 fordert die regelmäßige, jedoch mindestens jährliche Bewertung des IKT-Risikos von IKT-Altsystemen, ohne den Begriff „IKT-Altsysteme“ näher zu beschreiben. Die Forderung nach Kenntnis aller Ressourcen aus Absatz 4 und 5 sollten Finanzunternehmen bereits im Rahmen der Strukturanalyse/Prozesslandkarte (Absatz 1) erfüllen.

Artikel 8 (Schutz und Prävention) fordert die Überwachung und Kontrolle der Funktionsweise der IKT-Systeme und -Instrumente (in Absatz 1), die Gewährleistung von Resilienz, Kontinuität und Verfügbarkeit von IKT-Systemen sowie die CIA -Schutzziele der Daten in der kompletten Verarbeitungskette - Speicherung, Verwendung und Übermittlung (in Absatz 2), den Einsatz von Kryptographie (in Absatz 3), eine „Policy für Informationssicherheit“ zur Erreichung der CIA-Schutzziele (in Absatz 4 lit. a), ein mit dem Need-to-know-Prinzip arbeitendes Identity Access Management (in Absatz 4 lit. c), den Schutz von kryptografischen Schlüsseln (in Absatz 4 lit. d), ein Änderungsmanagement (in Absatz 4 lit. e) und eine Strategie für Patches und Updates. Hinzu kommen noch die Netzwerksegmentierung und ein Änderungsmanagement für den Notfall inklusive Berichtslinien. Die o.g. „Policy für Informationssicherheit“ adressiert das klassische Management von Vermögenswerten (‚asset management‘) im Rahmen der Themen „Informationsklassifizierung“ und „Informationskennzeichnung“ (‚labeling‘); dieses muss um den Schutz der Informationen entlang ihres Lebenszyklus und der sie verarbeitenden Anwendungen und Systeme ergänzt werden, am besten durch ein IT-Betriebshandbuch. 

Artikel 9 (Erkennung) widmet sich der Erkennung von Anomalien bei der Leistungserbringung von IKT-Netzen und von IKT-Vorfällen. Die Fähigkeit zur Erkennung muss mit angemessenen Ressourcen und Kapazitäten ausgestattet sein. Speziell Kreditinstituten wird mit der Anomalienerkennung von Handelsauskünften eine besondere Anforderung zuteil (in Absatz 4). Speziell "genehmigten Veröffentlichungssystem" oder "APA" und "Bereitsteller konsolidierter Datenträger" oder "CTP" müssen gemäß Absatz 4 Handelsmeldungen besonders schützen. 

Artikel 10 (Gegenmaßnahmen und Wiederherstellung) führt in Absatz 1 eine „IKT-Strategie zur Fortführung des Geschäftsbetriebes“ ein und detailliert diese in den Inhalten in Absatz 2 als Mischung aus Incident Management und Business Continuity Management aus. Dabei ist aus der Version 2022 die Anforderung aus Ansatz 2a nach der Aufzeichnung "aller IKT-bezogenen Vorfälle" entfernt worden. Das ist aus Sicht der Autoren zu begrüßen, da in der operativen Praxis als auch in der Prüfungspraxis die Festlegung auf "alle" IKT-Vorfälle zu unüberwindbaren Dissensen führen würde. Absatz 3 führt einen „IKT-Plan für die Wiederherstellung im Notfall" ein, der einer unabhängigen Prüfung zu unterziehen ist. Gemeint ist ein IKT-Plan für den IKT-Risikomanagementrahmen aus Artikel 5 Absatz 1, d.h. das „Management von Risiken“ und ein „hohes Maß an digitaler Betriebsstabilität“. Im Klartext muss der Risikomanagementprozess mindestens durch die Interne Revision überprüft werden. Auch die Jahresabschlussprüfung ist eine geeignete Prüfung. Die Prüfung der „digitalen Betriebsstabilität“ kann am besten durch eins der großen zwei neuen Themen der DORA realisiert werden: die bedrohungsorientierten Penetrationstests (siehe Ausführungen zu Artikel 23).

Absatz 4 leitet zu Plänen zur Fortführung des Geschäftsbetriebes über. Diese müssen zusammen mit den Kommunikationsplänen gemäß Absatz 5 mindestens jährlich überprüft werden. Version 2022 führt mit Absatz 4a nun auch die BIA (Business Impact Analysis) im Gesetzestext ein. Es folgen die Verpflichtungen eine Krisenkommunikationsfunktion (Absatz 6) festzulegen, Aufzeichnungen zu Störungen anzufertigen (Absatz 7), die Anforderung speziell an Zentralverwahrer Testergebnisse an die Aufsicht zu übermitteln (Absatz 8) und wiederum an alle Finanzunternehmen Kosten und Verluste aus IKT-Vorfällen an die zuständige Behörde zu melden (Absatz 9). Dafür müssen die ESAs über den gemeinsamen Ausschluss Leitlinien für die Schätzung der aggregierten jährlichen Kosten und Verluste entwickeln (neuer Absatz 9a der Version 2022).

Kurzum: Finanzunternehmen müssen ein Business Continuity Management System (BCMS) einführen. Dieses sollten sie nach Ansicht der Autoren mit Hilfe des BSI-Standards 200-4 angehen. Auch zu diesem Absatz eine Anmerkung: Was macht die zuständige Behörde mit den gemeldeten Kosten und Verlusten? Diese Datenbank ist ein lohnendes Ziel für die Organisierte Kriminalität und somit ein exponiertes Angriffsziel.

Artikel 11 widmet sich den „Strategien für Datensicherung und Wiederherstellungsverfahren“ und legt Zentralen Gegenparteien (Absatz 3) und Zentralverwahrern (Absatz 4) besondere Pflichten bei den Wiederherstellungsplänen resp. dem sekundären Bearbeitungsstandort (Absatz 5) auf.

Artikel 12 behandelt „Lernprozesse und Weiterentwicklung“ nach IKT-Vorfällen und verpflichtet in Absatz 2 Finanzunternehmen zur Meldung von Änderungen an die zu-ständigen Behörden. Hierbei werden allerdings keine Kriterien für die Meldung genannt. Version 2022 ergänzt mit Absatz 7t die Version 2020 um den Passus der Überwachung der technologischen Entwicklungen auf deren Auswirkungen auf die IKT-Sicherheitsanforderungen und die digitale betriebliche Widerstandsfähigkeit.
Dazu halten sich Finanzunternehmen über die neuesten IKT-Risikomanagementverfahren auf dem Laufenden, um aktuellen oder neuen Formen von Cyberangriffen wirksam begegnen zu können.

Artikel 13 „Kommunikation“ birgt keine Überraschungen und verpflichtet Finanzunter-nehmen über Kommunikationspläne zu verfügen (Absatz 1), welche zwischen internen und externen Empfängern unterscheiden, wobei die internen weiter unterteilt werden in Wissende zum IKT-Risikomanagement und allen anderen Personen sowie der Beauftragung von mindestens einer Person als Umsetzer der Kommunikationsstrategie und als Sprecher nach extern.

Artikel 14 (Weitere Harmonisierung von Instrumenten, Methoden, Prozessen und Strategien für IKT-Risikomanagement) führt zum ersten Mal „Technische Regulierungsstandard“ (RTS) ein, welche die ESA in Kooperation mit der ENISA erarbeiten sollen. Diese sollen die in Artikeln 8, 9 und 10 benannten Strategien, Verfahren, Protokolle, Instrumente, Komponenten, Prüfungen und Elemente für IKT-Sicherheit weiter detaillieren. Im Vergleich zur Version 2020 wurden in der Version
2022 zwei Buchstaben – a) allgemeine CIA-Maßnahmen und b) eingebaute Netzwerksicherheit – gestrichen und mit dem Buchstaben ha) – Inhalt und Format des Berichts zum IKT-Risikomanagementrahmen– ein neuer hinzugefügt. Des Weiteren wurde Artikel 14a (Vereinfachter Rahmen für das IKT-Risikomanagement) hinzugefügt, mit dem Kapitel 2 „IKT-Risikomanagement“ (Artikel 4 bis Artikel 14) für einige genannte Finanzunternehmen nicht gelten sollen, gleichwohl werden den Ausgenommenen in Absatz 1 Buchstaben (a) bis (h) so viele einzelne Bestandteile aus diesen Artikeln auferlegt, dass die Frage gestellt werden muss, wo eine Erleichterung gegeben sein soll.

Eine Zusammenstellung aller zu erstellender RTS aus DORA findet sich in Abbildung 44.

Abbildung 4: aus DORA resultierende Regulatory Technical Standards (RTS)

Kapitel III "IKT-bezogener Vorfälle - Bewältigung Qualifizierung und Berichterstattung" (Artikel 15 bis 20)

Das Meldewesen wurde ergänzt. In nachfolgenden sechs Artikel werden die Anforderungen an Meldungen von IKT-Vorfällen detailliert:  

Artikel 15 legt Finanzunternehmen eine „Vorgehensweise für die Bewältigung IKT-bezogener Vorfälle“ auf. Diese muss u.a. die Aspekte Frühwarnindikatoren integrierte Überwachung, Handhabung und Weiterverfolgung von IKT-Vorfällen, ihre Verfolgung, Protokollierung, Kategorisierung und Klassifizierung entsprechend Schwere und Kritikalität, bis hin zu Kommunikationsplänen für intern/extern und einem Meldewesen enthalten. Diese Themenstellung zum Management von Sicherheitsvorfällen wird in einem ISMS übli-cherweise im gleichnamigen Segment bearbeitet.

Artikel 16 (Klassifizierung IKT-bezogener Vorfälle) stellt auf Klassifizierungskriterien IKT-bezogener Vorfälle ab: diese sind Zahl betroffener Nutzer, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität betroffener Dienste und wirtschaftliche Auswirkungen. Auch werden aus diesem Artikel drei RTS  erstellt (siehe Abbildung 4).

Artikel 17 definiert u.a. Fristen für die „Meldung schwerwiegender IKT-bezogener Vorfälle“ an die zuständige Behörde (Abs. 3) – unterteilt in Erstmeldung, Zwischenberichte und Abschlussbericht. Finanzunternehmen dürfen Meldepflichten an Dritte delegieren (Abs. 4). Die zuständige Behörde informiert die sachgerechte ESA-Behörde, bei Finanzunternehmen auch die EZB,  die so genannte „zentrale Anlaufstelle“ gemäß der NIS-Richtlinie - in Deutschland das BSI. die Abwicklungsbehörden (Single Resolution Board, SRB) sowie andere nach nationalem Recht zuständige Behörden (Abs. 5). Absatz 6 legt den ESAs, der EZB und EIOPA Mitteilungspflichten zum IKT-Vorfall an andere zuständige Behörden auf. Der in der Version 2022 hinzugefügte Absatz 7 beschleunigt die Mitteilung aus Absatz 6 im Falle von betroffenen Zentralverwahrern. KRITIS-Unternehmen, welche bereits heute aus dem BSIG24 schwerwiegende IKT-Vorfälle melden müssen, werden in Zukunft diese nur nach den Vorgaben der DORA melden müssen, um eine Doppelregulierung zu vermeiden.

Artikel 18 (Harmonisierung von Inhalt und Vorlagen von Meldungen) gemäß dieses Artikels erarbeiten ESA , ENISA und EZB ein RTS aus Absatz 1 Buchstabe a zu Inhalt von Berichten über schwerwiegende IKT-Vorfälle, Fristen für die initiale Meldung und Inhalt der Meldung für erhebliche Cyberbedrohungen unter Beachtung etwaiger Regelungen aus der kommenden NIS 2-Richtlinie und die Bedingungen zur Delegation der Meldepflichten an Dritte sowie aus Absatz 1 Buchstabe b ein ITS zu Standard-Formularen, Vorlagen und Verfahren zur Meldung eines größeren IKT-bezogenen Vorfalls und erheblicher Cyber-Bedrohung.

Artikel 19 (Zentralisierung Berichterstattung über schwerwiegende IKT-Vorfälle) beschreibt die Aufgabe für ESA, EZB  und ENISA , einen Bericht zur Prüfung der Einrichtung einer einheitlichen EU-Plattform für die Meldung schwerwiegender IKT-Vorfälle zu erstellen. Der Bericht soll an das Europäische Parlament und den Rat 2 Jahre nach Inkrafttreten von DORA übermittelt werden. Mit dieser zentralisierten Meldeplattform taten sich schon die deutschen KRITIS-Betreiber zu Zeiten des UP KRI-TIS  und des IT-SiG 1.0 in den Jahren 2008 bis 2015 schwer; es bleibt somit abzuwarten, wie dieses Vorhaben auf europäischer Ebene aufgegriffen wird, denn diese zentrale Datenbank stellt ein hoch motivierendes Ziel für Angreifer dar.

Mit dem in der Version 2022 eingeführten Artikel 20a wird der Geltungsbereich des Kapitels III (Artikel 15 bis Artikel 20) für operative oder sicherheitsrelevante Vorfälle im Zahlungsverkehr bei Kreditinstituten, Zahlungsinstituten, Kontoinformationsdienstleistern und E-Geld-Instituten betont. Man kann nur spekulieren welche Einflussnahme von Lobbyisten den Artikel willentlich oder unwillentlich befördert hat.

Prüfung der digitalen Betriebsstabilität - Artikel 21-24

Kapitel IV (Artikel 21 bis 24) bildet zusammen mit Kapitel V (Artikel 25 bis 39)  die prüfungsrelevanten Artikel und sie spannen den Rahmen für die Prüfung der IKT bei Finanzunternehmen allgemein und IKT-Drittanbietern im Speziellen weit auf - Abbildung 5.

Abbildung 5: Prüfungsrelevante Artikel für Finanzunternehmen und IKT-Drittarbeiter

Kapitel IV stellt mit den Artikeln 21 bis 24 die Prüfung der digitalen Betriebsstabilität dar. Neu und damit besonders erwähnenswert zu Artikel 21 (Allgemeine Anforderungen für Prüfungen der digitalen Betriebsstabilität) ist die Etablierung eines Programms zur jährlichen Prüfung der digitalen Betriebsstabilität aller kritischen IKT-Systeme und -Anwendungen; dieses umfasst Inhalte aus den Artikeln 22 und 23 und eine Risikogesteuerte Prüfung der Betriebsstabilität inklusive der Mitigation aller Feststellungen. Die Beschreibung des Geltungsbereichs als „digitale Betriebsstabilität“ umfasst alle Anwendungen, Komponenten, Systeme und Informationen und ist in diesem Umfang neu. Bisher reduziert die Regulierung die Aufwände durch Ausdrücke wie „wesentliche Auslagerungen“, „kritische Systeme“ oder auch „wichtige Systeme“. Nun muss das Finanzunternehmen vollumfänglich digital betriebsstabil sein.

Artikel 22 (Prüfung von IKT-Instrumenten und -Systemen) gibt durchzuführende Tests gemäß Artikel 21 vor und eröffnet eine Vielzahl an Anforderungen an Analysen, Überprüfungen und Bewertungen. Speziell Zentralverwahrer und Zentrale Gegenparteien müssen die Anfälligkeit von Änderungen an kritischen Funktionen, Anwendungen und Infrastrukturkomponenten bewerten.Der in der Vresion 2022 neu hinzugefügte Absatz 3 schränkt für Kleinunternehmen den Umfang aus Absatz 1 ein. 

Nach Artikel 23 (Erweiterte Prüfungen von IKT-Instrumenten, -Systemen und -Prozessen auf Basis bedrohungsorientierter Penetrationstests) müssen kritische Finanzunternehmen (Festlegung welche kritisch sind siehe Artikel 23 Absatz 3) alle 3 Jahre bedrohungsorientierte Penetrationstests durchführen. Neu in der Version 2022 ist die mögliche Reduktion der Testfrequenz durch die BaFin in Absatz 1. Gemäß Absatz 2 umfassen die Penetrationstests zumindest kritische Funktionen, auch die ausgelagerten, und werden an Live-Produktionssystemen durchgeführt. Die zuständige Behörde muss den Umfang des Penetrationstests genehmigen und nach Durchführung auch die ordnungsgemäße Durchführung bescheinigen. 

Eine weitere Neuerung der Version 2022 schreibt bei Nutzung interner Tester den Einbezug von externen Testern alle 3 Jahre vor. „Bedeutende Banken“29 dürfen nur Tester nutzen, die den Anforderungen aus Artikel 24 Abs. 1 Buchstaben a) bis e) genügen. Die neu eingeführten Absätze 3a und 3b ermöglichen den Mitgliedsstaaten die Benennung einer einzigen Behörde, die auf nationaler Ebene für bedrohungsorientierte Penetrationstests im Finanzsektor zuständig ist. Ernennt ein Staat keine nationale Behörde gemäß Absatz 3a, so darf die nationale zuständige Behörde (in Deutschland BaFin) alle oder einige Aufgaben aus den Artikeln 23 und 24 an eine andere
Behörde delegieren. In beiden Fällen dürfte das in Deutschland das BSI werden.

Die zuständige Behörde ermittelt Finanzunternehmen, die bedrohungsorientierte Penetrationstests durchzuführen haben mit Hilfe der Faktoren aus Absatz 3 Buchstaben a) bis c). ESA und EZB erstellen zusammen ein RTS für Penetrationstests gemäß TIBER-EU zu den Aspekten 

• Umfang der bedrohungsorientierten Penetrationstests aus Absatz 3,
• Anforderungen an interne Tester (Buchstabe aa) in Absatz 4 der Version 2022 
• Anforderungen zum Umfang der Penetrationstest, Testmethodik und Ergebnisse, Abschluss und Korrekturphasen für Penetrationstests 
•  Art der aufsichtlichen Zusammenarbeit bei Finanzunternehmen, die in mehreren Mitgliedsstaaten tätig sind

Mit der Einholung der Genehmigung des vorgesehenen Penetrationstests und der Genehmigung der internen Tester bei der BaFin kommt weiterer neuer Verwaltungsaufwand auf Finanzunternehmen zu. Auch die BaFin muss ob der Zahl der neu hinzukommenden Aufsichtsobjekte sowie der Vielzahl erweiterter IT-fachlicher Anforderungen weitere Kapazitäten aufbauen. 

Eine weitere Herausforderung ist die Anforderung Penetrationstests im Produktivsystem durch-zuführen, da dies verschiedene Risiken birgt (siehe Kasten „Risiken von Penetrationstests in Live-Umgebung“). Hier plädieren die Autoren für Penetrationstests in Staging-Umgebungen und der Begründung der Vergleichbarkeit zu einem Penetrationstest in der Live-Umgebung in Form einer Risikoanalyse.  Eine Randnotiz zu TIBER-DE: Im Jahre 201930 durch die Bundesbank auf freiwilliger Basis eingeführt werden mit Anwendung der DORA Penetrationstests gemäß TIBERDE nun zur Pflicht. Es zeigt sich, dass das freiwillige Anwenden von regulatorischen Angeboten auf den Ernstfall der Pflicht gut vorbereiten kann.
 

 
Artikel 24 (Version 2022 neuer Titel: "Anforderungen an Tester für den Einsatz von bedrohungsorientierten Penetrationstests) definiert die Bedingungen an Tester für bedrohungsorientierte Penetrationstests. So müssen sie durch eine Akkreditierungsstelle zertifiziert sein oder sich an formale Verhaltenskodizes oder ethische Rahmenregelungen halten. Sie müssen zudem eine unabhängige Gewähr oder ein Bestätigungsvermerk für zuverlässige Steuerung von Risiken inkl. Schutz vertraulicher Informationen und einen Versicherungsschutz (Berufshaftpflicht und gegen Fehlverhalten/Fahrlässigkeit) nachweisen. 

Version 2022 ergänzt Artikel 24 um den Absatz 1a), der drei Bedingungen an interne Tester setzt:

• i) ihr Einsatz muss von der zuständigen Behörde bzw. von der einzigen gemäß Artikel
• 23 Absatz 3a benannten Behörde genehmigt werden;
• ii) die zuständigen Behörden haben überprüft, dass das Finanzunternehmen über ausreichende
• Ressourcen verfügt und sichergestellt hat, dass Interessenkonflikte während
• der gesamten Planungs- und Durchführung des Tests vermieden werden;
• iii) der „Threat Intelligence“-Anbieter ist nicht mit dem Finanzunternehmen verbunden

Geklärt werden muss welche Verhaltenskodizes und ethische Rahmenregelungen den Anforderungen genügen und welche Institution die Einhaltung testieren darf. Gleiches gilt für die Ge-währ und den Bestätigungsvermerk. Zu vermeiden gilt, dass im Zweifel formale Kriterien mit neuen verwaltungstechnischen Hürden vor gewachsenen vertrauensvollen Geschäftsbeziehungen zwischen Finanzunternehmen und Penetrationstestern stehen. 

Kapitel V "Steuerung des Risikos durch IKT-Drittanbieter", Abschnitt I: Grundsätze für eine zuverlässige Steuerung des Risikos durch IKT-Drittanbieter ( Artikel 25 bis Artikel 27)

Das große Kapitel V zu IKT-Drittanbietern besteht aus den 15 Artikeln 25 bis 39 und ist in zwei Abschnitte unterteilt – Abschnitt I (Grundsätze für eine zuverlässige Steuerung des Risikos durch IKT-Drittanbieter) mit den Artikeln 25 bis 27 und Abschnitt II (Aufsichtsrahmen für kritische IKT-Drittanbieter) mit den Artikeln 28 bis 39 – siehe Abbildung 55.

Artikel 25 (Allgemeine Grundsätze) spannt den Rahmen der Risikosteuerung durch IKT-Drittanbieter auf und fordert in Absatz 3 die Entwicklung einer „Strategie für das Risiko durch IKT-Drittanbieter“ als Teil des IKT-Managementrahmens. Diese muss u.a. ein Register zu Ver-trägen mit IKT-Drittanbietern enthalten. Ferner unterrichten IKT-Drittanbieter die zuständige Behörde über die geplante Vergabe von Aufträgen für kritische oder wichtige Funktionen (auch nachträglich bei Hochstufung einer Funktion), was in Deutschland bereits das FISG fordert. Unter anderem müssen Finanzunternehmen die Erhöhung des IKT-Konzentrationsrisikos (siehe Ausführungen zu Artikel 26 weiter unten) bewerten. Absatz 9 fordert neben umfassenden und dokumentierten Ausstiegsszenarien „gegebenenfalls“ auch deren „ausreichende“ Testung und regelmäßige Überprüfung. Hier besteht Klärungsbedarf: wann müssen Finanzunternehmen Ausstiegsszenarien und in welcher Form prüfen? Reicht eine Planbesprechung oder muss es ein Funktionstest sein? Zur Präzisierung sollte festgestellt werden, dass XAIT (BAIT / KAIT / VAIT / ZAIT) keine Anforde-rung der vollständigen Test-Übertragung und Test-Inbetriebnahme der gesamten IT-Systemlandschaft von einem Dienstleister zu einem zweiten Dienstleister stellt.

Artikel 26 (Vorläufige Bewertung des IKT-Konzentrationsrisikos ) legt Finanzunternehmen weitere neue Bewertungs- und Entscheidungspflichten auf. Bei der Ermittlung des IKT-Konzentrationsrisikos müssen sie berücksichtigen, ob sie IKT-Drittanbieter nutzen die „nicht ohne Weiteres ersetzbar sind“ oder „mehrfach vertragliche Vereinbarungen mit demselben/eng verbundenen IKT-Drittanbieter“ schließen. Hierbei müssen Finanzunternehmen Alternativen untersuchen. Auch müssen sie die Risiken bei Auslagerung von wichtigen Funktionen durch IKT-Drittanbieter an Unterauftragnehmer bewerten. Das ist bereits aus der Datenschutzregulierung bekannt, findet jetzt aber Eingang in die europäische Finanz-Regulierung. 
Schließlich dürfen Finanzunternehmen mit einem IKT-Drittanbieter aus einem Drittland nur dann einen Vertrag schließen, wenn die Einhaltung des Datenschutzes und die wirksame Durchsetzung des Rechts gewährleistet sind. Diese Forderungen entspringen der Rechtsprechung des EuGH zum Privacy Shield vom 16.07.2020 – besser als Schrems II bekannt – und suggerieren, dass diese Problematik bei IKT-Drittanbietern in Europa gelöst sei. Dem ist nicht so:  die Verarbeitung von personenbezogenen Daten in Hyperscalern US-amerikanischer Provenienz – in den USA oder in Europa als Tochter eines US-amerikanischen Unternehmens – ist derzeit nicht konform zur DSGVO möglich, denn hierzu müsste das europäische auslagernde Unternehmen beweisen, dass die USA ein dem europäischen vergleichbares Datenschutzniveau aufweisen. Diesen Beweis kann das europäische Unternehmen regelmäßig nicht führen.

Bedeutsam ist ferner die Anforderung, Ketten von Unterauftragnehmern hinsichtlich Überwachbarkeit durch das Finanzunternehmen selbst als auch die zuständige Behörde zu evaluieren. Hierzu müssen die Finanzunternehmen genaue Kenntnisse zu den Fähigkeiten der zuständigen Behörden erlangen, um „mitgestalten“ zu können. Dazu sollte es ebenfalls einen „Gemeinsamen Ausschuss“ (analog zum gleichnamigen Ausschuss der ESA) aus Finanzunternehmen und BaFin geben; hier böte sich das weiter zu entwickelnde „Fachgremium IT“ der BaFin an.

Artikel 27 (Wesentliche Vertragsbestimmungen) beschreibt im Detail die Mindestinhalte des Vertrages zwischen Finanzunternehmen und IKT-Drittanbieter. Dabei wurden in der Version 2022 viele Mindestvertagsinhalte im neuen Absatz 2a kodifiziert. Erwähnenswert aus dem Entwurf ist ein Detail aus Absatz 2 Buchstabe j, wonach die Kündigungsrechte und die damit zusammenhängenden Mindestkündigungsfristen „den Erwartungen der zuständigen Behörden“ entsprechen müssen. Dazu sollten diese Erwartungen den Finanzunternehmen vorher bekannt sein – Stichwort „Fachgremium IT“. Wenn vorhanden, sollen gemäß Absatz 3 Finanzunternehmen und IKT-Drittanbieter Standardvertragsklauseln verwenden. Auch aus diesem Artikel her-aus wird ein RTS entstehen, das gemäß Absatz 2 Buchstabe a eine klare und vollständige Beschreibung aller Funktionen und Dienstleistungen, die der IKT-Drittanbieter zu erbringen hat, vornimmt. Es bleibt abzuwarten, ob und wie sich die Aufsicht der IKT-Drittanbieter auf die Bereitschaft der beispielsweise Hyperscaler auswirkt, mehr auf die Vorstellungen und Wünsche der Finanzunternehmen einzugehen. Bisher liegt die Verhandlungsmacht trotz Moderation der Regulation bei den Hyperscalern.

Kapitel V "Steuerung des Risikos durch IKT-Drittanbieter", Abschnitt II: Aufsichtsrahmen für kritische IKT-Drittanbieter (Artikel 28 bis Artikel 29)Zentral für die DORA ist Artikel 28 mit den Regelungen zur „Benennung von kritischen IKT-Drittanbietern“. Vereint ein IKT-Drittanbieter eine bestimmte Höhe an Vermögenswerten von Finanzunternehmen, die ihn nutzen, stellt die ESA (und nicht die nationale zuständige Behörde) die „federführende Aufsichtsinstanz“ des IKT-Drittanbieters. Im „Gemeinsamen Ausschuss“ (die Zusammenarbeit von EBA, EIOPA und ESA im Rahmen der ESA an DORA) benennt die ESA IKT-Drittanbieter unter Beachtung der Kriterien aus Absatz 2. Besondere Erwähnung bedarf die „systematische Auswirkung auf Stabilität, Kontinuität oder Qualität der Erbringung der Finanz-Dienstleistungen bei Betriebsstörung des IKT-Drittanbieters“. Dabei ist die Zahl der Finanzunter-nehmen zu berücksichtigen, für die der IKT-Drittanbieter Dienstleistungen erbringt. Hier muss darauf hingewiesen werden, dass Hyperscaler mit der technisch gesehen unlimitierten Skalierbarkeit und der weltweit verteilten Verfügbarkeit durch „Availability Zones“ diesen Risiken wirkungsvoll begegnen. Der in den Buchstaben b) und c) des Absatzes 2 formulierte Mechanismus aus „systemrelevanten Instituten“ (G-SRI) sowie „anderer systemrelevanter Institute“ (A-SRI) in ihrer Nutzung von IKT-Drittanbietern soll ebenfalls bei der Benennung kritischer IKT-Drittanbieter berücksichtigt werden. Gleiches gilt für die Wechselbeziehung untereinander und im restlichen Finanzsektor. 

Es kann hinterfragt werden, wie die ESA dies bewerkstelligen und dabei die Balance aus freiem Wettbewerb, Wettbewerbsbeschränkungen und technologische Übersicht behalten will. Absatz 2 Buchstabe d thematisiert den Grad der Substituierbarkeit des IKT-Drittanbieters: hier wäre eine Entwicklung ungünstig, nach der die ersten Hyperscaler nutzende Finanzunternehmen diese weiter nutzen dürfen - Finanzunternehmen die später Hyperscaler nutzen wollen dies wegen zu hoher Marktanteile der IKT-Drittanbieter nicht mehr dürfen. Die in Version 2022 neu aufgenommenen Absätze 2a) und 2b) adressieren Verbundinterne IKT-Drittanbieter. Der ebenfalls neue Absatz 2c) detailliert den Prozess der Benennung eines IKT-Drittanbieters als überwachtes Unternehmen in Informationspflichten der federführenden Aufsichtsinstanz, Fristen und Einspruchsmöglichkeiten für den IKT-Drittanbieter aus. Als kritisch eingestufte IKT-Drittanbieter müssen ihre Kunden, die Finanzunternehmen sind, darüber informieren. Absatz 5 schafft in der Version 2022 einige Ausnahmen für die Benennung. Diese gilt nicht für

• Finanzunternehmen die IKT-Dienstleistungen für andere Finanzunternehmen erbringen
• (Buchstabe i);
• IKT-Dienstleister innerhalb der Gruppe (Buchstabe iii) und
• IKT-Drittdienstleister, die IKT-Dienstleistungen ausschließlich in einem Mitgliedstaat für
• Finanzunternehmen erbringen, die nur in diesem Mitgliedstaat tätig sind (Buchstabe iv)

Nach Absatz 8 können IKT-Drittanbieter die Aufnahme in die Liste kritischer IKT-Drittanbieter beantragen. Denn nicht gelistete IKT-Drittanbieter werden es schwer am Markt haben. Nach Absatz 9 dürfen Finanzunternehmen einen in einem als kritisch eingestuften Drittland ansässigen IKT-Drittanbieter nur nutzen, wenn dieser innerhalb der von 12 Monaten nach der Bennenung der Tochtergesellschaft in der Europäischen Union gegründet hat. Der neue Absatz 9a) legt dem IKT-Drittdienstleister die Informationspflicht über Änderungen in der Struktur der Geschäftsführung der in der Europäischen Union ansässigen Tochtergesellschaft vor. 

Artikel 29 (Struktur des Aufsichtsrahmens) birgt ein interessantes Detail in Absatz 3: Das „Aufsichtsforum“ (ein Unterausschuss der ESA, der vorbereitende Arbeiten für Einzelentscheidungen und gemeinsame Empfehlungen für kritische IKT-Drittanbieter durchführt) legt umfassende Benchmarks kritischer IKT-Drittanbieter vor. Was bedeutet diese Aussage konkret? Er-stellt die ESA eine „Best-of-Liste“ von IKT-Drittanbietern mit den besten Benchmarks? Was würde das für weniger performante IKT-Drittanbieter bedeuten? 

Version 2022 führt im Artikel 29 zwei neue Absätze31 3a) und 3b) ein und erlaubt dem Aufsichtsforum Unterstützung durch „unabhängige Experten“ (neu hinzugefügter letzter Satz in Absatz 3), regelt die Benennung der zuständigen Behörde (Abs. 3a) und stellt Anforderungen an die unabhängigen Experten (Abs. 3b).

Die „Aufgaben der federführenden Aufsichtsinstanz“ im Artikel 30 bergen keine Überraschungen bei der Bewertung der Qualität der Steuerung der IKT-Risiken durch die IKT-Drittanbieter als ihre Hauptaufgabe. In Absatz 3 ist der Anspruch der federführenden Aufsichtsinstanz niedergeschrieben, die kritischen IKT-Drittanbieter mit Hilfe eines jährlich aktualisierten Plans zu beaufsichtigen. Die zuständige Behörde (in Deutschland die BaFin) darf nur in Absprache mit der federführenden Aufsichtsinstanz Maßnahmen beim IKT-Drittanbieter ergreifen. Das stellt eine bisher nicht normierte Machtteilung zwischen nationalen Aufsichten und der europäischen ESA dar. Heute kann die BaFin autonom agieren.
Version 2022 führt den neuen Artikel 30 a (Operative Koordinierung zwischen den ESAs) ein, der die Zusammenarbeit zwischen EBA, EIOPA und ESMA regelt u a sollen die ESAs ein ‚ Joint Oversight Network‘ (JON) gründen und bei Bedarf EZB und ENISA für technische Expertise einbinden.

Artikel 31 regelt die „Befugnisse der feder-führenden Aufsichtsinstanz“: Diese kann alle benötigten Informationen und Unterlagen vom IKT-Drittanbieter anfordern, Untersuchungen durchführen, die ergriffenen Mitigationsmaßnahmen überprüfen und Empfehlungen zu allen Inhalten des Artikel 30 Absatz 2 abgeben. Diese „Empfehlungen“ sind als Auflagen zu verstehen und also mandatorisch umzusetzen. Unter anderem kann die federführende Aufsichtsinstanz die Nutzung eines Drittland-IKT-Drittanbieters für kritische oder wichtige Funktionen des Finanzunternehmens untersagen. Für die Bekanntheit des Artikels wird Absatz 4 mit der Möglichkeit der Verhängung eines in regelmäßigen Abständen zu zahlenden Zwangsgeldes bei Zuwiderhandlung zu Absatz 1 Buchstaben a bis c sorgen, d.h. wenn der IKT-Drittanbieter bei der Untersuchung nicht kooperiert. Die Version 2022 ergänzt Absatz 6 zur Bestimmung der Höhe des Zwangsgeldes um Kriterien wie Kooperationsgrad oder Vorsatz und Fahrlässigkeit des IKT-Drittanbieters.  Gemäß Absatz 8 kann die ESA die Zwangsgelder unter Bedingungen veröffentlichen. 

Version 2022 wurde Artikel 31a hinzugefügt. Dieser kodifiziert die „Befugnisse der federführenden Aufsichtsinstanz außerhalb der Union“ bei Aufsichtsobjekten, die nicht in der Europäischen Union beaufsichtigt werden können.

Die weiteren drei Artikel detaillieren die Befugnisse der federführenden Aufsichtsinstanz aus Artikel 31 Absatz 1 Buchstaben a und b aus: 

• Artikel 32 „Informationsersuchen“ (gemäß Artikel 1 Buchstabe a)
• Artikel 33 „Allgemeine Untersuchungen“ (gemäß Artikel 1 Buchstabe b Stichwort „Untersuchungen“)
• Artikel 34 „Vor-Ort-Prüfungen“ (gemäß Artikel 1 Buchstabe b Stichwort „Inspektionen“)

Zu Artikel 33 ist anzumerken, dass sich die Befugnisse der federführenden Aufsichtsinstanz wie eine polizeiliche Vorladung lesen, inklusive der Aushändigung von Aufzeichnungen von Telefongesprächen.

Artikel 35 (Laufende Aufsicht) führt ein „gemeinsames Untersuchungsteam“ ein. So ein Team wird für jeden kritischen IKT-Drittanbieter eingerichtet und es wird gespeist aus federführender Aufsichtsinstanz und der zuständigen Behörde, der für die NIR-Richtlinie zuständigen Behörde (in Deutschöand das BSI) auf freiwilliger Basis und eine zuständige nationale Behörde des Mitgliedsstaats, in dem der kritische IKT-Drittdienstleister niedergelassen ist, auf freiwilliger Basis (diese vierte Möglichkeit ist primär für Mitgliedsstaaten bestimmt, die keine zentrale Behörde für IT-Sicherheit eingerichtet haben wie es Deutschland mit dem BSI vorweist). Alle Mitglieder müssen über Fachwissen in den Bereichen IKT und operationellen Risiken verfügen, koordiniert wird das Team durch einen Mitarbeitenden der ESA. Gemäß Absatz 4 übermittelt die federführende Aufsichtsinstanz binnen 3 Monaten nach Untersuchungsabschluss Empfehlungen an den kritischen IKT-Drittanbieter und die zuständigen Behörden. Artikel 36 dient der „Harmonisierung der Voraussetzungen für die Durchführung der Aufsicht“ und verpflichtet die ESA zur Erstellung verschiedener RTS (siehe Abbildung 4). 

Artikel 37 „Folgemaßnahmen zuständiger Behörden“ stellt die „nationale Gegenstelle“ zu den Artikeln 30 bis 36 dar und reiht sich im Zeitstrahl nach der Prüfung und den Empfehlungen der federführenden Aufsichtsinstanz ein. Absatz 1 fordert von IKT-Drittanbietern das Bekenntnis den Empfehlungen der federführenden Aufsichtsinstant aus Artikel 31 Abs. 1 zu folgen oder eine begründete Erklärung für die Nichtbefolgung der Empfehlungen abzugeben. Der in der Version 2022 neue Absatz 1a) regelt die Bekanntgabe des IKT-Drittanbieters bei Nichtbefolgung von Absatz 1. Die zuständige Behörde informiert aus Absatz 2 heraus die relevanten Finanzunternehmen über
die sich aus den Empfehlungen an die IKT-Drittanbieter ergebenden Risiken. Version 2022 wurde um die Absätze 2a) und 2b) ergänzt: Absatz 2a) regelt einen Mechanismus von in Absatz 3 beschriebenen Maßnahmen bis zum vollständigen Aussetzen der Inanspruchnahme der Dienstleistung des IKT-Drittanbieters im Falle der Nicht-Berücksichtigung der Risiken durch das Finanzunternehmen. Absatz 2b) ermöglicht der zuständigen Behörde (BaFin) auf freiwilliger Basis die Konsultation
mit der für KRTIS zuständigen Behörde (BSI) vor einer Entscheidung gemäß Absatz 2a). Zu guter Letzt informiert Artikel 38 die IKT-Drittanbieter über die „Überwachungsgebühren“, die diese für die Aufsicht durch ESA und die zuständigen Behörden zu entrichten haben.

Handlungsempfehlungen für Finanzunternehmen und Aufsichten

Finanzunternehmen, IKT-Drittanbieter und  Aufsichten sollten nicht auf das Inkrafttreten der DORA warten. Auch wenn sich die final verabschiedete Fassung der DORA vom vorliegenden Entwurf unterscheiden wird, gehen die Autoren davon aus, dass sich wesentliche Inhalte nicht substanziell in Quantität oder Qualität ändern werden. Daher sollten beide Adressatengruppen mit der Vorbereitung auf die DORA beginnen, auch wenn diese aller Voraussicht nach erst 2 Jahren angewendet wird,  i. Eine Situation wie mit der DSGVO, die seit der Verabschiedung im Mai 2016 zwei Jahre später im Mai 2018 in Kraft und viele Marktteilnehmer „überrascht“ hat, sollte vermieden wer-den. Für ein Zuwarten stellt die DORA zu hohe Anforderungen an die technisch-organisatorische Ausstattung, an die Reife der Organisation im Risikomanagement und in der Informationssicherheit und an die Fähigkeiten der Verantwortlichen aller Beteiligten. 

Zudem muss wohl unterschieden werden zwischen Finanzunternehmen, die solche Anforderungen wie aus der DORA bereits aus anderen Regulierungen wie zum Beispiel XAIT kennen und Finanzunternehmen, für dieDORA der erste Anforderungskatalog zur Informationssicherheit ist. Zur ersten Gruppe gehören bspw. alle Banken, Versicherungsunternehmen und Zahlungsdienstleister, weil sie Anforderungswerke wie BAIT, VAIT und ZAIT erfüllen müssen. Zur zweiten Gruppe werden viele der neuen Adressaten der DORA gehören. Als Vorbereitungsschritte sind zu empfehlen: 

1)    Aufbau. Pilotierung und Betrieb eines zertifizierungsfähigen ISMS

Auch wenn die Forderung nach einem ISMS wie beschrieben im aktuellen Entwurf vom 23.06.2022 marginalisiert wurde, verlangt DORA in praxi ein umgesetztes ISMS. Im regulierten Finanzsektor ist ein ISMS bereits Pflicht, jedoch ist die Bandbreite der Qualität der implementierten ISMS groß. Einer der Schwerpunkte des Managements sollte auf die Zertifizierungsfähigkeit der bisher Einsatz findenden ISMS gelenkt werden. Zudem besteht heute für viele der neuen Aufsichtsobjekte der DORA keine Pflicht zum Betrieb eines ISMS, sodass auf diese Finanzunternehmen erhebliche Aufwendungen zukommen. Sollte die Anforderung eines zertifizierten ISMS in der nächsten Regulierungsrunde eingeführt werden, stellt ein zertifizierungsfähiges ISMS die beste Vorbereitung dar.

2)    Fokussierung auf Regelbereiche der DORA, Gap-Analyse und Mitigation von Feststellungen
Alle Finanzunternehmen sollten die Konformität ihrer Aufbau- und Ablauforganisation zu den vier Regelbereichen der DORA prüfen:

1. Anforderungen an IKT-Risikomanagement
2. Meldung von IKT-Vorfällen
3. Prüfung der digitalen Betriebsstabilität
4. Prüfung Risiko durch IKT-Drittanbieter

Mögliche Feststellungen durch Prüfer sollten präventiv beseitigt werden. Ein ISMS aus Schritt 1) stellt dabei eine solide sowie gleichfalls unabdingbare Basis für diesen zweiten Schritt dar. 
 
3)    Vorbereitung hybride IT-Prüfung
Finanzunternehmen und Aufsicht sollten gemeinsam einen Standard für eine hybride IT-Prüfung entwickeln. Die DORA wird weitere Digitalisierungsschritte einer Vielzahl von Prüfungshandlun-gen erzwingen. Ein hybrider Prüfungsansatz bestehend aus automatisch erfassten Größen (Maschinen basiert) und manuell durchgeführten Prüfungshandlungen (Experten basiert) bietet verschiedene Vorteile (siehe Abbildung 6) und reduziert Aufwände für Finanzunternehmen und Aufsicht.

Abbildung 6: Zweifachhybride Perspektive auf Governance und Technologie 

4)    Aufsicht stärken 
Die Aufsicht erfährt durch DORA eine große Erweiterung ihrer Aufgaben in Quantität (An-zahl der Finanzunternehmen) und Qualität (vertiefte Kenntnisse in IKT und Risikomanagement), sodass eine angemessene Reaktion in Form von mehr Personal mit MINT-Kompetenzen not-wendig wird. Die gemeinsame Entwicklung des hybriden IT-Prüfungsstandards mit Finanzunternehmen würde die Aufsicht verstärkt auf wesentliche Prüfungshandlungen und Aufsichtsinhalte fokussieren und ggf. zu einem europäischen Prüfungsrahmen beitragen.

 
Fazit

DORA wird zahlreiche bestehende Anforderungen an den Einsatz von modernen Technologien und dem Management von Risiken erstmals durch eine EU-weite Verordnung harmonisieren. Damit begründet DORA die erstmals EU-weit gültige Anwendung zahlreicher bestehender Anforderungen durch eine EU-Verordnung. Dieser Umstand begründet die Hoffnung auf eine deutliche Reduzierung der Aufsichts- und Prüfungsverwaltung für Finanzunternehmen, auf eine Beschleunigung der Digitalisierung im Finanzsektor und des weiteren Aufbaus an MINT-Kompetenzen, um Leitungs- als auch Aufsichtsgremien mit Know-how zu IKT-Organisation und Risikomanagement auszustatten.
Die Fähigkeit von Finanzunternehmen Cyberangriffen mit angemessenen Maßnahmen und Resilienz zu begegnen, drückt sich in den Themenschwerpunkten und dem Anforderungskatalog der DORA aus. Diese sind digitale Betriebsstabilität, Prüfung und der Einbezug von Risiken durch Outsourcing an IKT-Drittanbieter in das interne Risikoinventar von Finanzunternehmen. Die Aufsichtsobjekte tun gut daran, bereits jetzt die DORA zu antizipieren und ein Programm zur „Fitness DORA“ aufzusetzen – erste Schritte wären 

1. Aufbau und Betrieb eines zertifizierungsfähigen ISMS, 
2. Gap-Analyse der vier Themenschwerpunkte der DORA 
   a.    Anforderungen an IKT-Risikomanagement
   b.    Meldung von IKT-Vorfälle
   c.    Prüfung der digitalen Betriebsstabilität
   d.    Prüfung Risiko durch IKT-Drittanbieter

und 
     3. die Vorbereitung einer hybriden IT-Prüfung. 

Alle Adressaten –zuvordest Finanzunternehmen und die Aufsichtsorgane müssen ihre MINT-Fähigkeiten in Quantität und Qualität stärken.

Die europäische Harmonisierung des Aufsichts-, Prüfungs- und Sanktionswesens schafft eine vergleichbare und damit verlässliche und von allen Stakeholdern anerkannte, da vertrauens-würdige Basis. DORA bietet damit dem europäischen Finanzsektor enorme Chancen die Wettbewerbsfähigkeit zu verbessern und kann weiteren Sektoren als Vorbild im Thema Cyber-Sicherheit und Resilienz dienen.