DORA im Finanzsektor

Resilienz im Finanzsektor

DORA reguliert Cybersecurity mit umfangreichen Pflichten und Aufsicht im EU-Finanzsektor:

• Einrichtungen: DORA reguliert Finanzunternehmen wie Kreditinstitute, Handelsplätze und Versicherungen sowie IKT-Drittdienstleister, in allen EU-Mitgliedsstaaten.
• Resilienz: Finanzunternehmen müssen umfangreiche Cybersecurity-Pflichten wie Risikomanagement, Incident Management, Tests der Resilienz, Informations­austausch, Management von IKT-Drittparteien erfüllen.
• Dienstleister: Haben eigene umfangreiche Pflichten und eigene Aufsicht (EU).
• Kooperation: DORA sieht eine Kooperation zwischen nationalen Behörden und EU-Behörden wie ESA, EZB und ENISA vor, plus Kooperation zwischen DORA- und NIS2-Behörden.
• Sanktionen: Mitgliedsstaaten legen Sanktionen fest, die von Behörden angewendet werden können. Sanktionen können verwaltungsrechtlicher, finanzieller und strafrechlicher Art sein.
• Fristen: DORA gilt als EU-Vorgabe direkt für betroffene Unternehmen und muss ab Januar 2025 angewendet werden. Nationale Gesetze analog EU NIS2 sind nicht notwendig.
• Aufsicht: Finanzunternehmen unterliegen primär der Aufsicht nationaler Behörden, die mit EU-Behörden kooperieren; IKT-Drittdienstleister werden durch EU-Behörden überwacht.

Teilweise gibt es nationale Gesetze, wie das Finanzmarkt­digitalisierungs­gesetz (FinmadiG), die flankierende Durchführungsbestimmungen zu EU-Verordnungen im Finanzwesen treffen.

DORA und NIS2

DORA und NIS2 haben Wechselwirkungen für regulierte Einrichtungen im Finanzsektor und Unternehmen, die Dienstleistungen im Finanzsektor erbringen. Finanzunternehmen sind aus NIS2 größtenteils ausgenommen, IT-Dienstleister sind doppelt reguliert mit eigenen Pflichten.

Einrichtungen

Die von DORA regulierten Finanzunternehmen sind in NIS2 zwar Teil des Sektors Finanz- und Versicherungswesen, von den NIS2-Pflichten aber ausgenommen, wenn sie in DORA reguliert sind (lex specialis). Die in DORA auch regulierten kritischen IKT-Drittdienstleister sind in NIS2 Einrichtungen des Sektors IT und TK und bleiben auch dort mehrfach reguliert.

Pflichten

Die Pflichten in DORA und NIS2 sind ähnlich – beide zielen auf Risikomanagement der IT und erbrachter Dienstleistungen ab. DORA ist in der Breite umfangreicher und in der Tiefe deutlich detaillierter als NIS2 – die Pflichten sind preskriptiver und sehr genau beschrieben.

Von DORA und NIS2 betroffene Unternehmen müssen zwischen den Pflichten übersetzen.

Aufsicht

In DORA unterliegen Finanzunternehmen primär der Aufsicht nationaler Aufsichtsbehörden (in Deutschland BaFin, Bundesbank und auch EZB), die mit EU-Behörden kooperieren; IKT-Drittdienstleister erhalten direkte EU-Aufsicht. In NIS2 werden Einrichtungen vor allem durch nationale Behörden (in Deutschland das BSI, die BNetzA) überwacht.

Einrichtungen

DORA reguliert zwei Arten von Unternehmen in der EU: Finanzunternehmen (financial entities), die direkt betroffen sind, und indirekt IKT-Drittdienstleister (ICT third-party service providers).

Ausschlüsse

Bei den von DORA betroffenen Finanzunternehmen gibt es Ausschlüsse: Art. 2 (3)

• Verwalter alternativer Investmentfonds i.S.v. Art. 3 (2) Richtlinie 2011/61/EU
• Versicherungs- und Rückversicherungsunternehmen i.S.v. Art. 4 Richtlinie 2009/138/EU
• Einrichtungen der betrieblichen Alterversorgung mit weniger als 15 Versorgungsanwärtern
• nach Art. 2, 3 Richtlinie 2014/65/EU ausgenommene natürliche oder juristische Personen
• Versicherungsvermittler, wenn sie Kleinst- oder kleine/mittlere Unternehmen sind
• Postgiroämter i.S.v. Art. 2 (5) 3. Richtlinie 2013/36/EU

Abgrenzung zu NIS2

Sofern Finanzunternehmen durch DORA reguliert werden, sind sie von NIS2 ausgeschlossen. Aufgrund der Ausschlüsse in DORA gibt es aber auch Finanzunternehmen, die nicht unter den Anwendungsbereich von DORA fallen – diese könnten dann von NIS2 betroffen sein.

In DORA regulierte IKT-Drittdienstleister bleiben in NIS2 reguliert, wenn dort betroffen.

Pflichten von Einrichtungen

DORA verfolgt das Ziel, innerhalb der EU ein hohes Niveau an digitaler operationaler Resilienz zu erreichen und legt dazu einheitliche Anforderungen für die Sicherheit von Netzwerk- und Informations­systemen, die die Geschäftsprozesse von Finanzunternehmen unterstützen fest.

Finanzunternehmen, die durch DORA reguliert sind, müssen umfangreiche Resilienz-Pflichten umsetzen und ihren zuständigen Aufsichtsbehörden nachweisen. Je nach Einstufung durch die Aufsicht werden auch kritische IKT-Dienstleister mit separaten DORA-Pflichten reguliert.

Risikomanagement

Governance

Finanzunternehmen müssen für DORA viele Maßnahmen im IKT-Risikomanagement umsetzen. Grundlage für das IKT-Risikomanagement ist ein interner Governance- und Kontrollrahmen für wirksames und umsichtiges Management von IKT-Risiken. Die Definition, Genehmigung, Überwachung und Verantwortung hierfür obliegt der Geschäftsführung. Art. 5

Das IKT-Risikomanagement (ICT risk management framework) muss ins Risiko­management integriert sein und Strategien, Richtlinien, Verfahren sowie IT-Tools umfassen, um Informations-, IT- und physische Assets ordnungsgemäß und angemessen zu schützen. Art. 6

Für das Monitoring von IKT-Drittdienstleistern muss im Senior Management eine dedizierte Rolle besetzt werden. Die Geschäftsleitung (management body) soll ihr Wissen und Fähigkeiten über IKT-Risiken aktuell halten und Trainings absolvieren. Art. 5 (3-4)

Vorgaben

Die Geschäftsführung muss die Implementierung vom IKT-Risikomanagement steuern und verantworten, das folgende strategische Vorgaben und Policies umfassen muss: Art. 5 (2)

• Übergreifende Verantwortung übernehmen und Rollen etablieren (a, c, d)
• Strategien: Digitale operationale Resilienz (s. u.), Risiko-Tolerenz für IKT (d)
• Policies und Vorgaben: Datensicherheit, Business Continuity, Response/Recovery Pläne, (b, d)
• Interne Audits und Pläne (f)
• Budgetierung für Sicherheit und Resilienz (g)
• Security Awareness, Training und Awareness und IKT-Skills (g)
• Review und Zustimmung zu Vereinbarungen mit IKT-Drittdienstleistern
• Meldewege innerhalb des Unternehmens

Strategie

Das IKT-Risikomanagement muss eine Strategie für digitale operationale Resilienz mit Methodiken zur Umsetzung vom Risikomanagement in Maßnahmen umfassen: Art. 6 (8)

• Verankerung IKT-Risikomanagement in Geschäftsstrategie, Festlegung der Risikotoleranz, Definition von Zielen für IT-Sicherheit mit KPIs und Metriken (a, b, c)
• Erklärung der Referenzarchitektur für IKT (d)
• Beschreibung von Detektionsmechanismen für IKT-Vorfälle und Auswertungen von Vorfällen und Präventivmaßnahmen (e, f)
• Umsetzung der Resilienztests in Art. 24-27 (g)
• Kommunikationsstrategie bei Vorfällen nach Art. 14 (h)

Informationen und IT-Assets müssen durch Strategien, Vorgaben, Protokolle und Tools geschützt und IKT-Risiken durch entsprechende Maßnahmen minimiert werden. Art. 6 (2)(3)

Audits und Review

Das IKT-Risikomanagement muss dokumentiert und mindestens jährlich oder auf besondere Veranlassung hin überprüft und regelmäßig verbessert werden. Eine unabhängige Kontroll­funktion soll IKT-Risiken überwachen und steuern, Finanzunternehmen sollen dabei die three lines of defence einhalten. Art. 6 (4)(5)

Interne Revisionen sollen den IKT-Risikomanagementrahmen regelmäßig auditieren, im Rahmen des risikobasierten Auditplans des Finanzunternehmens. Dafür sind notwendige Kompentenzen und Wissen notwendig. Art. 6 (6)(7)

Schutz der IT

Resiliente IT

Zur Bewältigung von IKT-Risiken müssen Finanzunternehmen IKT-Systeme, Protokolle und Tools einsetzen, die angemessen, zuverlässig, ausreichend dimensioniert und technologisch resilient sind. Sie müssen diese stets auf dem neusten Stand halten. Art. 7

Im Rahmen vom IKT-Risikomanagement müssen IKT-Lösungen und Prozesse resilient gestaltet werden, um die Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten zu sichern. Dies umfasst sichere Datenübertragung und -management, Schutz vor unberechtigten Zugriffen und Fehlern. Art. 9 (3)

Identifikation

Im IKT-Risikomanagement müssen alle IKT-gestützten Unternehmensfunktionen, Rollen und Verantwortlichkeiten sowie unterstützende Assets mit Rollen und Abhängigkeiten identifiziert, klassifiziert und dokumentiert werden. Dabei müssen auch Konfigurationen, Verbindungen und Abhängigkeiten von Assets erfasst werden.

Alle Quellen für IKT-Risiken, Cyber-Bedrohungen und Schwachstellen müssen kontinuierlich ermittelt, Changes an Netzwerk, IT-Systemen und Prozessen müssen bewertet werden. IKT-Drittdienstleister müssen ermittelt und bewertet werden. Die erhobenen Informationen müssen in entsprechenden Inventaren dokumentiert werden. Art. 8

Schutzmaßnahmen

Die Sicherheit und Funktionsfähigkeit von IKT-Systemen müssen kontinuierlich überwacht und die Auswirkungen von Risiken minimiert werden. Die Resilienz, Kontinuität und Verfügbarkeit der IKT-Systeme müssen sichergestellt werden, um hohe Standards der Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten aufrechtzuerhalten. Art. 9

Im Rahmen des IKT-Risikomanagements müssen Vorgaben in IKT umgesetzt werden: Art. 9 (4)

• Informationssicherheitsleitlinie (Policy) für Daten, Informationen und IKT-Assets (a)
• Risiko-basierter Ansatz für Netzwerk- und Infrastruktur-Management und automatisierte Mechanismen für Isolation (Segmentierung, Zonierung) von Angriffen (b)
• Zugangs- und Zugriffskontrolle durch Policies, Prozeduren und Mechanismen für IAM (c)
• Vorgaben für Strong Authentication, Kryptographie und Verschlüsselung (d)
• Change Management mit Policies, Prozeduren und Mechanismen für Software, Hardware, Firmware (!), Systeme und Sicherheit (e)
• Patch-Management Policies und Vorgaben

Detektion und Reaktion

Erkennung

Anormale Aktivitäten wie IKT-Sicherheitsvorfälle und Leistungsprobleme in Netzwerken müssen umgehend erkannt und potenzielle einzelne wesentliche Schwachstellen ermittelt werden.

Die Erkennung muss mehrere Kontrollebenen ermöglichen und Alarmkriterien beinhalten, damit im Incident Management Reaktionsprozesse und automatisierte Warnmechanismen ausgelöst werden. Monitoring und Alarmierung müssen mit ausreichend Ressourcen für die Überwachung von Aktivitäten, Anomalien und Vorfällen ausgestattet sein. Art. 10

Kommunikation

Finanzunternehmen müssen über Kommunikationspläne verfügen, die eine angemessene Offenlegung zumindest von schwerwiegenden IKT-Vorfällen oder Schwachstellen gegenüber Kunden und anderen Finanzunternehmen sowie der Öffentlichkeit ermöglichen.

Für die interne Kommunikation bei Sicherheitsvorfällen müssen Kommunikations­strategien vorhanden sein. Mit der Umsetzung der Kommunikationsstrategie muss eine Rolle definiert werden, die Aufgaben gegenüber der Öffentlichkeit und den Medien wahrnimmt. Art. 14

Lernprozess

Es müssen ausreichende Kapazitäten für die Untersuchung von Schwachstellen, Bedrohungen, Vorfällen und deren Auswirkungen auf die digitale operationale Resilienz vorhanden sein. Schulungen für IT-Sicherheit und digitale operationale Resilienz müssen entwickelt und für alle Beschäftigten und die Geschäftsleitung verpflichtend sein. Art. 13

Nach Störungen durch IKT-Vorfälle muss die Ursache untersucht und Verbesserungen ermittelt werden (Lessons Learned). Ergebnisse müssen ins Risikomanagement einbezogen Änderungen nach einem IKT-Vorfall Behörden auf Anfrage mitgeteilt werden.

Business Continuity Management

Geschäftsfortführung

Es muss eine Leitlinie zur Geschäftsfortführung festgelegt und durch Regelungen, Pläne und Mechanismen implementiert werden. Damit muss die Kontinuität kritischer oder wichtiger Unternehmensfunktionen gewährleistet und Schäden durch IKT-Vorfälle mittels einer schnellen, angemessenen und wirksamen Reaktion begrenzt werden. Art. 11

Eine Business Impact Analyse (BIA) muss durchgeführt werden.

Reaktions- und Wiederherstellungspläne müssen im IKT-Risikomanagement implementiert werden und der internen Revision unterliegen. Die Pläne müssen regelmäßig, mindestens jährlich, getestet werden, inklusive Auslagerungen und Drittdienstleistern.

Maßnahmen zur Kommunikation und zum Krisenmanagement müssen festgelegt werden.

Verlustmeldungen

Finanzunternehmen müssen zuständigen Behörden auf Anfrage die geschätzten aggregierten jährlichen Kosten und Verluste ... [melden], die durch schwerwiegende IKT-bezogene Vorfälle verursacht wurden. Art. 11 (10)

Wiederherstellung

IKT-Systeme und Daten müssen mit minimaler Ausfallzeit und Verlusten wiederhergestellt werden. Die Wiederherstellung von Daten darf deren Verfügbarkeit, Integrität oder Vertraulichkeit nicht gefährden. Die Datensicherungssysteme sind regelmäßig zu testen.

Dazu müssen Richtlinien und Verfahren für die Datensicherung festgelegt werden, basierend auf der Kritikalität und Vertraulichkeit der Daten. Datensicherungssysteme müssen physisch und logisch vom Quellsystem getrennt sein.

Es müssen Redundanzen in Ressourcen, Fähigkeiten und Funktionen für die Deckung des Geschäftsbedarfs vorgehalten werden. Art. 12

Test der Resilienz

Finanzunternehmen müssen ihre digitale operationale Resilienz als Teil des IKT-Risiko­management­rahmens testen und dafür ein Testprogramm für Resilienz definieren. Die Tests müssen risikobasiert von unabhängigen internen oder externen Prüfern durchgeführt werden. Probleme müssen wirksam behoben werden. Art. 24

IT und TK

Die angemessenen Tests der digitalen operationalen Resilienz müssen mindestens jährlich erfolgen und alle IT-Systeme und Applikationen umfassen, die beim Finanzunternehmen kritische und wichtige Funktionen unterstützen. Art. 24 (6)

Das Testprogramm muss unter anderem folgende Themen umfassen: Schwachstellen­scans, Open-Source Analysen, Netzwerksicherheit, Überprüfungen der physischen Sicherheit, Scans von Software, Quellcode-Tests, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests. Art. 25

Penetration Testing (TLPT)

Bestimmte Finanzunternehmen, wie bedeutend eingestufte Kreditinstitute, müssen mindestens alle drei Jahre erweiterte Threat Led Penetration Tests (TLPT) durchführen. Diese Pentests müssen kritische und wichtige Funktionen umfassen und an Live-Produktionssystemen durchgeführt werden. Art. 26

IKT-Drittdienstleister im Geltungsbereich des TLPT müssen in die Tests eingebunden werden. Tests müssen Kontrollen umsetzen, um das Risiko von Auswirkungen der Tests auf Daten, Vermögenswerte und kritische und wichtige Funktionen zu mindern. Art. 26 (2-5)

Nach Abschluss der Tests müssen Berichte und Pläne mit Abhilfemaßnahmen ausgearbeitet und der zuständigen Aufsichtsbehörde eine Zusammenfassung der Ergebnisse vorgelegt werden. Die Behörde attestiert danach die Durchführung der Tests. Art. 26 (6-7)

Prüfer

Finanzunternehmen unterliegen Vorgaben, welche Tester sie beauftragen sollen oder dürfen. Bei bedeutenden Finanzunternehmen müssen die Tests immer extern erfolgen, bei anderen in jedem dritten Zyklus. Art. 26 (8)

Prüfer, die TLPTs durchführen, unterliegen besonderen Anforderungen wie fachlicher Eignung, technischen und organisatorischen Fähigkeiten, Fachwissen, Zertifizierungen, Einhaltung formaler Verhaltenskodexe und Absicherung durch Versicherungen. Art. 27

Management von IKT-Drittparteien

Finanzunternehmen müssen im Risikomanagement Risiken der Nutzung von IKT-Drittparteien (Dienstleistern) managen. Die Verantwortung für die Compliance mit DORA-Vorgaben verbleibt beim Finanzunternehmen, auch wenn sie im Rahmen ihrer Geschäftstätigkeit IKT-Dienstleister nutzen und entsprechende Vereinbarungen geschlossen haben. Art. 28 (1)

Strategie

Die Strategie für IKT-Drittparteienrisiko muss eine Leitlinie zur Unterstützung kritischer und wichtiger Funktionen durch IKT-Drittdienstleister umfassen. Die Geschäftsleitung muss regelmäßig alle Risiken überprüfen, die durch die IKT-Dienstleistungen zur Unterstützung kritischer und wichtiger Funktionen entstehen. Art. 28 (2)

Dienstleister-Audits

Finanzunternehmen müssen ihre Dienstleister regelmäßig auditieren. Sie legen dafür die Häufigkeit von Audits und Inspektionen sowie die zu prüfenden Bereiche und die Ausübung von Zugangs-, Inspektions- und Auditrechte[n] beim IKT-Drittdienstleister fest.

Finanzunternehmen müssen sicherstellen, dass interne und externe Auditoren Fähigkeiten haben, um die vertraglichen Dienstleistungen angemessen auditieren und bewerten zu können, insbesondere wenn die Dienstleistungen eine hohe technische Komplexität haben. Art. 28 (6)

Konzentrationsrisiko

Wenn Finanzunternehmen bei der Planung des Vertragsabschlusses für IKT-Dienstleistungen die entstehenden Risiken ermitteln, müssen sie insbesondere berücksichtigen: Art. 29 (1)

• ob Verträge mit einem Dienstleister entstehen, der nur schwer ersetzbar wäre
• ob mehrere Verträge mit demselben oder eng verbundenen IKT-Drittdienstleistern zur Unterstützung kritischer oder wichtiger Funktionen entstehen.

Finanzunternehmen müssen Nutzen und Kosten alternativer Lösungen abwägen, z. B. die Nutzung verschiedener Dienstleister, und berücksichtigen, ob und wie die geplanten Lösungen den Geschäftserfordernissen und -zielen aus der Strategie für digitale Resilienz entsprechen.

Dienstleister-Register

Finanzunternehmen müssen ein Register über vertragliche Vereinbarungen mit IKT-Drittdienst­leistern führen, aus dem hervorgeht, ob Dienstleistungen kritische oder wichtige Funktionen unterstützen. Mindestens jährlich müssen an die zuständige Behörde berichtet werden: neue Vereinbarungen, Dienstleister-Kategorie, bereitgestellte Dienstleistungen.

Auf Anfrage muss der zuständigen Behörde das vollständige Register übermittelt werden. Wenn Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen geplant werden, muss die zuständige Behörde unterrichtet werden. Art. 28 (3)

Subunternehmer

Finanzunternehmen müssen die Risiken von Unterauftrags­vergaben in Verträgen mit IKT-Drittdienstleistern abwägen. Wenn Unteraufträge die Unterstützung kritische oder wichtige Funktionen betreffen, müssen Finanzunternehmen folgendes berücksichtigen: Art. 29 (2)

• Bestimmungen des Insolvenzrechts für den Fall der Insolvenz des IKT-Drittdienstleisters
• Einschränkungen, die sich für die dringende Wiederherstellung von Daten ergeben
• Einhaltung und wirksame Durchsetzung der EU-Datenschutzvorschriften bei IKT-Drittdienstleistern mit Sitz in einem Drittland
• Auswirkungen von komplexe[n] Ketten der Unterauftragsvergabe auf ihre Fähigkeit [...] die vertraglich vereinbarten Funktionen vollständig zu überwachen

Pflichten in Verträgen

Bewertung vor Vertragsschluss

Finanzunternehmen müssen vor Abschluss von Verträgen mit IKT-Dienstleistern: Art. 28 (4)

• Prüfen, ob durch die Dienstleistung kritische oder wichtige Funktionen unterstützt werden
• Aufsichtsrechtlichen Bedingungen für die Auftragsvergabe bewerten und erfüllen
• Risiken der Dienstleisterbeziehung bewerten, auch mögliche IKT-Konzentrationsrisiken
• Sorgfaltspflicht zur Eignung der Dienstleister kontinuierlich im Vergabeprozess sicherstellen
• Interessenskonflikte aufgrund der vertraglichen Vereinbarung bewerten

Vertragliche Vereinbarungen mit IKT-Drittdienstleistern dürfen nur geschlossen werden, wenn diese angemessene Standards für Informationssicherheit einhalten. Werden kritische oder wichtige Funktionen unterstützt, müssen Unternehmen sicherstellen, dass die Dienstleister die aktuellsten und höchten Qualitätsstandards für Informationssicherheit anwenden. Art. 28 (5)

Kündigung

Finanzunternehmen müssen Dienstleistungsverträge bei Anlass kündigen können: Art. 28 (7)

• Erheblicher Verstoß des Dienstleisters gegen geltende Gesetze, Vorschriften oder Verträge
• Nachweisliche Schwächen des Dienstleisters im IKT-Risikomanagement
• Vertrag steht der wirksamen Aufsicht des Finanzunternehmens durch Behörden entgegen

Ausstiegsstrategien

Finanzunternehmen müssen für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, Ausstiegsstrategien haben, ohne dass die Geschäftstätigkeit unterbrochen, die Einhaltung regulatorischer Anforderungen eingeschränkt oder die Kontinuität und Qualität der für Kunden erbrachten Dienstleistungen beeinträchtigt wird (Exit-Strategien).

Ausstiegsstrategien müssen konkrete Ausstiegspläne, alternative Lösungen und Übergänge beinhalten, sowie angemessene Notfallmaßnahmen zur Fortführung der Geschäftstätigkeit, falls es im Zuge eines Ausstiegs doch zu Einschränkungen kommt. Art. 28 (8)

Bestimmungen

Verträge mit IKT-Drittdienstleistern müssen die Rechte und Pflichten des Finanzunternehmens und des Dienstleisters eindeutig zuweisen und schriftlich dokumentieren. Art. 30 DORA schreibt konkrete Aspekte für Dienstleisterverträge vor, mindestens u.a.:

• Klare und vollständige Beschreibung der bereitgestellten Funktionen und Dienstleistungen
• Standorte der Dienstleistung/Bereitstellung
• Bestimmungen über Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit
• Vereinbarte Dienstleistungsgüte
• Verpflichtung zur Unterstützung des Finanzunternehmens bei IKT-Vorfallsbewältigung
• Kündigungsrechte und damit zusammenhängende Mindestkündigungsfristen
• Schulung und Sensibilisierung des IKT-Drittdienstleisters zu digitaler operationalen Resilienz

Verträge für Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, müssen höhere Anforderungen erfüllen und weitere Inhalte umfassen, insbesondere Überwachungs- und Auditrechte seitens der Finanzunternehmen sowie Exit-Strategien, die Finanzunternehmen einen Dienstleisterwechsel oder die Umstellung auf eine interne Lösung ermöglichen.

Die ESA erarbeiten dazu technische Standards (RTS), um die Aspekte zu präzisieren, die ein Finanzunternehmen bei der Untervergabe von IKT- Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen bestimmen und bewerten muss.

Registrierung

DORA macht keine eigenen Vorgaben zur Registrierung von betroffenen Finanzunternehmen bei zuständigen Behörden. Finanzunternehmen registrieren sich im Rahmen der nationalen Markteintrittsverfahren bei zuständigen Aufsichtsbehörden.

Die Behörden und Mechanismen zur Registrierung sind gesetzlich definiert, etwa im KWG. In Deutschland benötigen Unternehmen, die bestimmte Dienstleistungen des Bank- und Finanzwesens ... erbringen, ... eine Erlaubnis der Finanzaufsicht; z. B. für Bankgeschäfte oder Finanzdienst­leistungen eine schriftliche Erlaubnis der BaFin, teilweise auch der EZB.

Sicherheitsvorfälle

Finanzunternehmen müssen IKT-Vorfälle an relevante Aufsichtsbehörden und Stellen melden und dafür umfangreiche interne und externe Prozesse implementieren: Für die Erkennung, Behandlung und Meldung von Vorfällen. Dabei müssen alle IKT-bezogenen Vorfälle und erheblichen Cyberbedrohungen erfasst werden.

Behandlung und Bewertung

Der Incident Management Prozess muss u.a. die Verwendung von Indikatoren, Verfahren zur Erkennung, Nachverfolgung, Protokollierung, Kategorisierung und Klassifizierung sowie Kommunikationspläne (Mitarbeiter, Interessensgruppen, Medien und Kunden) umfassen. Schwerwiegende Vorfälle müssen der Geschäftsleitung gemeldet werden. Art. 17

IKT-Vorfälle müssen klassifiziert und die Auswirkungen bewertet werden. Kriterien sind u. a. Anzahl betroffener Kunden, Dauer und geografische Ausbreitung des Vorfalls, Verlust der Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen.

Cyberbedrohungen müssen ebenso mit analogen Kriterien bewertet werden. Art. 18

Meldeprozess

Finanzunternehmen müssen schwerwiegende IKT-Vorfälle der zuständigen Behörde melden. Bei bedeutend eingestuften Kreditinstituten wird diese Meldung von der Behörde an die EZB weitergeleitet.

Hat ein schwerwiegender IKT-Vorfall Auswirkungen auf die finanziellen Interessen der Kunden, müssen Finanzunternehmen die Kunden über den Vorfall informieren. Cyber­bedrohungen können gemeldet werden, wenn die Bedrohung für das Finanzsystem, Nutzer der Dienstleistung oder Kunden relevant ist. Art. 19

Für den Inhalt von Meldungen über schwerwiegende IKT-Vorfälle und Cyberbedrohungen und Meldefristen entwickeln die ESA mit ENISA und EZB technische Standards (RTS) und prüfen die Einrichtung einer einheitlichen EU-Plattform für die Meldung schwerwiegender IKT-Vorfälle. Art. 20 Art. 21

Rückmeldung

Aufsichtsbehörden bestätigen den Eingang von Meldungen über schwerwiegende IKT-Vorfälle und liefern ggf. Rückmeldungen oder Orientierungshilfen. Dies kann auch die Bereitstellung relevanter anonymisierter Informationen und Erkenntnisse über ähnliche Bedrohungen und Abhilfemaßnahmen umfassen. Art. 22

Die Vorgaben gelten auch für zahlungsbezogene Betriebs- oder Sicherheitsvorfälle, auch schwerwiegender Art, wenn sie Kreditinstitute, Zahlungsinstitute, Kontoinformationsdienstleister und E-Geld-Institute betreffen. Art. 23

Informationsaustausch

Finanzunternehmen können Informationen und Erkenntnisse über Bedrohungen untereinander austauschen, z. B. Indikatoren, Taktiken, Techniken und Verfahren, Warnungen und Tools. Die Teilnahme an einem solchen Informationsaustausch ist freiwillig. Erwägungsgrund 34

Der Austausch von Informationen und Erkenntnissen soll die digitale operationale Resilienz von Finanzunternehmen stärken, mit Vereinbarungen zum Schutz sensibler Informationen. Art. 45

Sofern Finanzunternehmen in einen entsprechenden Austausch eintreten oder ihn beenden, müssen sie dies der zuständigen Aufsichtsbehörde mitteilen.

Nationale Aufsicht

Finanzunternehmen werden unter DORA national durch zuständige Behörden überwacht. Diese zuständigen Behörden sind in diversen anderen EU-Vorgaben festgelegt, auf welche DORA referenziert, aber keine eigenen Zuständigkeiten definiert. Art. 46

Die nationalen Aufsichtsbehörden für Finanzunternehmen in Deutschland sind primär die BaFin, die Deutsche Bundesbank und die EZB.

Davon unabhängig werden kritische IKT-Drittdienstleister durch die EU separat überwacht.

EU und europäische Aufsicht

Neben der nationalen Aufsicht über Finanzunternehmen gibt es verschiedene Kooperations­ebenen von EU-Aufsichtsbehörden und Mechanismen: ESA (EU-Aufsicht), JON (EU-Netzwerk), Kooperation mit nationalen und NIS2-Behörden und übergreifende Übungen.

European Supervisory Authorities (ESA)

ESA sind die drei Europäischen Aufsichtsbehörden, die zusammen mit dem Europäischen Ausschuss für Systemrisiken (European Systemic Risk Board, ESRB) Teil des Europäischen Systems der Finanzaufsicht (ESFS) sind. Zu den ESA gehören:

• Europäische Bankenaufsichtsbehörde (European Banking Authority - EBA): Die EBA entwickelt europäische Aufsichtsstandards für die Finanzmarktaufsicht, welche den Rahmen für die primär zuständigen nationalen Aufsichtsbehörden bilden.
• Europäische Aufsichtsbehörde für Versicherungswesen und betriebliche Altersvorsorge (European Insurance and Occupational Pensions Authority - EIOPA): Die EIOPA ist zuständig für die einheitliche Beaufsichtigung des Versicherungswesens und der betrieblichen Altersversorgung sowie der Aufrechterhaltung der Finanzmarktstabilität in den Bereichen.
• Europäische Wertpapier- und Marktaufsichtsbehörde (European Security and Markets Authority - ESMA): Die ESMA kontrolliert die Einhaltung gesetzlicher Regelungen im Finanz­sektor mit Fokus auf Ratingagenturen, Transaktionsregister und zentrale Gegenparteien. Die ESMA koordiniert außerdem Tätigkeiten der Wertpapieraufsichtsbehörden.

Joint Oversight Network (JON)

Die Überwachungsbehörden EIOPA, ESMA und EBA richten ein Joint Oversight Network (JON) zur Abstimmung von Überwachungstätigkeiten von IKT-Drittdienstleistern ein. EZB und ENISA können ad-hoc um fachliche Beratung oder Teilnahme an Sitzungen gebeten werden. Art. 34

Kooperation mit NIS2-Behörden

Die ESA und zuständige Behörden können im Rahmen ihrer Aufsichts von Finanzunternehmen an der NIS2-Kooperationsgruppe (Cooperation Group) teilnehmen. Sie können eine Partizipation an Themen verlangen, die IKT-Dienstleister betreffen, die NIS2-Einrichtung und kritische IKT-Dienstleister nach DORA sind. Die Behörden für DORA und NIS2 sollen sich abstimmen. Art. 47

Auch im Meldewesen ist eine Zusammenarbeit geplant, damit Finanzaufsichtsbehörden Details über schwerwiegende IKT-Vorfälle auch an Nicht-Finanzbehörden, z. B. zuständige Behörden nach NIS2, weiterleiten. Erwägungsgrund 52

Sektorübergreifende Übungen

Die im Rahmen von DORA zuständigen Behörden (ESA, ENISA, nationale Behörden usw.) sollen Informationsaustausch in Finanzsektoren einrichten. Sie sollen Krisen- und Notfallübungen für Cyberangriffe konzipieren, um Abhängigkeiten des Finanzsektors von anderen Sektoren zu untersuchenund eine koordinierte Reaktion auf EU-Ebene zu entwickeln. Art. 49

Harmonisierung

Die vorgenannten Themen und verpflichtenden Maßnahmen können weiterentwickelt und konkretisiert werden. Hierzu entwickeln die ESA gemeinsam mit ENISA und EZB technische Standards (RTS). Art. 15

Prüfungen

Der IKT-Risikomanagementrahmen von Finanzunternehmen muss regelmäßig geprüft werden:

• Mindestens jährlich
• Nach IKT-Vorfällen
• Nach aufsichtsrechtlicher Anweisungen
• Bei Feststellungen aus Tests oder Auditverfahren

Auf Anfrage der zuständigen Aufsichtsbehörde müssen Berichte vorgelegt werden. Art. 6 (5) Die nationalen Aufsichtsbehörden überprüfen mit diesen Berichten die Kohärenz des IKT-Risikomanagementrahmens. Art. 4 (3)

Sofern ein vereinfachter IKT-Risikomanagementrahmen angewendet wird, muss dieser regelmäßig und bei Auftreten schwerwiegender IKT-bezogener Vorfälle entsprechend den aufsichtsrechtlichen Anweisungen dokumentiert und überprüft werden. Art. 16 (2)

Kritische IKT-Drittdienstleister

Bestimmte IT-Provider, die Finanzkunden in der EU bedienen, werden durch die europäische Aufsicht als kritisch eingestuft und von einer EU-Behörde (Lead Overseer) überwacht. Diese kritischen IKT-Drittdienstleister erbringen für Finanzunternehmen Dienstleistungen mit hohen Risiken und müssen viele eigene Pflichten umsetzen.

Wie wird man kritisch?

Die ESA (European Supervisory Authorities) stufen kritische IKT-Drittdienstleister anhand einer entsprechenden Bewertung und festgelegten Kriterien ein. Art. 31

Die Einstufung als kritischer IKT-Drittdienstleister basiert auf verschiedenen Kriterien:

• Systemische Auswirkungen: Wenn Betriebsstörungen beim IKT-Dienstleister Auswirkungen auf die Stabilität, Kontinuität oder Qualität von Finanzdienstleistungen haben.
• Systemischer Charakter: Bedeutung der IKT-Dienstleister oder der der Finanzunternehmen, die auf die Dienstleistungen zugreifen. Wichtig: Anzahl global systemrelevanter Institute oder anderer systemrelevanter Institute, die auf den IKT-Dienstleister zurückgreifen, oder Interdependenzen zwischen den genannten Instituten
• Abhängigkeit von Finanzunternehmen von den Dienstleistungen: Kritische oder wichtige Funktionen, in die derselbe IKT-Dienstleister involviert ist (direkt oder indirekt)
• Grad der Substituierbarkeit des IKT-Dienstleisters: Potenzieller Mangel an Alternativen aufgrund der begrenzten Zahl von IKT-Drittdienstleistern, oder Schwierigkeiten bei der Migration von einem zum anderen Dienstleister

Wenn ein IKT-Drittdienstleister zu einer größeren Gruppe gehört, dann sind die genannten Kriterien unabhängig von der Unternehmensstruktur auf die in der gesamter Gruppenstruktur bereitgestellten IKT-Dienstleistungen anzuwenden. Dadurch soll eine akkurate Bewertung von Dienstleistern gewährleistet werden. Erwägungsgrund 77

Die ESA veröffentlichen jährlich eine Liste der als kritisch eingestuften Dienstleister.

Ausnahmen

Folgende Unternehmen können nicht als kritisch eingestuft werden: Art. 31 (8)

• Finanzunternehmen, die IKT-Dienstleistungen für andere Finanzunternehmen bereitstellen
• IKT-Drittdienstleister, die anderen Überwachungsrahmen der EU unterliegen
• Gruppeninterne IKT-Dienstleister
• IKT-Drittdienstleister, die ihre Dienstleistungen ausschließlich in einem Mitgliedsstaat für Finanzunternehmen bereitstellen, die nur in diesem Mitgliedsstaat tätig sind

Überschneidung mit NIS2

Für kritische IKT-Dienstleister nach DORA gibt es Überschneidungen und Dopplungen zu NIS2. Unternehmen unterliegen potenziell Mehrfachregulierung mit DORA-Pflichten als kritischer IKT-Dienstleister und NIS2-Pflichten als Einrichtung nach NIS2. DORA nennt Anbieter von Cloud-Computing-Diensten als Infrastruktur, die auch unter NIS2 fällt. Erwägungsgrund 20

Pflichten kritischer Dienstleister

Kritische IKT-Drittdienstleister werden durch eine EU-Behörde überwacht und im IKT-Risiko­management bewertet. Dazu müssen kritische IKT-Dienstleister viele Pflichten erfüllen: Art. 33

Geltungsbereich

IKT-Risikomanagement muss in DORA alle IKT-Dienstleistungen und Prozesse umfassen, die kritische oder wichtige Funktionen von Finanz­unternehmen unterstützen. Dafür müssen Dienstleister bewerten, mit welchen Dienstleistungen sie IKT-Risiken für Finanz­unternehmen darstellen, und in diesem Geltungsbereich DORA-Maßnahmen umsetzen. Art. 33 (2)

Management und Cybersecurity

Governance: Organisationsstrukturen und Governance-Regeln mit klaren Verantwortlichkeiten (responsibility and accountability) für effektives IKT-Risikomanagement. Art. 33 (3) d

Risikomanagement: Prozesse und Policies für IKT-Risikomanagement, Business Continuity (BCM) und IT-Notfallpläne (ICT response and recovery plans). Art. 33 (3) c

Standards: Nutzung relevanter nationaler und internationaler Standards in Dienstleistungen an Finanzunternehmen. Art. 33 (3) i

Interoperabilität: Mechanismen für Portabilität von Daten und Anwendungen sowie Interoperabilität, für effektive Kündigungsrechte der Finanzunternehmen. Art. 33 (3) f

Technische Sicherheit und IT

Schutz der IT: Maßnahmen für IT und TK, um die erbrachten Dienste der IKT-Dienstleister für Finanzunternehmen zu schützen – im Speziellen die Sicherheit, Verfügbarkeit, Kontinuität, Skalierbarkeit und Qualität der Dienste. Dies umfasst auch Datensicherheit. Art. 33 (3) a

Physische Sicherheit: Schutz der Gebäude, Liegenschaften und Rechenzentren, und physische Sicherheit, welche die IT-Sicherheit unterstützt. Art. 33 (3) b

Detektion und Vorfälle: Identifikation, Monitoring und Meldung von IT-Vorfällen an Finanz­unternehmen und Behandlung und Behebung dieser Vorfälle und Cyber-Angriffe. Art. 33 (3) e

Tests und Audits: Tests von Systemen, Infrastruktur und Kontrollen, IT-Audits. Art. 33 (3) g/h

Verträge und Kunden

IKT-Drittdienstleister müssen neben den eigenen DORA-Pflichten noch vertragliche Pflichten ihrer Finanzkunden umsetzen, die sich aus dem DORA-vorgegebenen Provider Management in Verträgen ergeben; bei einigen Pflichten von Finanzunternehmen müssen sie aktiv mitwirken.

• Mögliche Einbindung in das jährliche Testprogramm von IKT-Systemen für kritische und wichtige Funktionen bei Finanzunternehmen Art. 24
• Einbindung in Threat Led Penetration Tests (TLPT) bei Finanzunternehmen Art. 26, 30 (3) d
• Dienstleisteraudits durch die Finanzunternehmen Art. 28 (6)
• Einhaltung angemessener Standards für Informationssicherheit und höchster Standards, wenn wichtige und kritische Funktionen unterstützt werden Art. 28 (5)
• Diverse Informationspflichten und Auskünfte zur Dienstleistung und Infrastruktur Art. 30 (2)
• Unterstützung der Finanzunternehmen bei IKT-Vorfallsbewältigung und Zusammenarbeit, auch mit Behörden Art. 30 (2) f-g
• Teilnahme an Security Awareness Programmen der Finanzunternehmen Art. 30 (3) i
• Meldepflichten für Entwicklungen bei kritischen und wichtigen Funktionen, die Auswirkungen auf Finanzunternehmen (und SLAs) haben Art. 30 (3) b
• Implementierung und Tests von von BCM-Plänen sowie IT-Maßnahmen bei kritischen und wichtigen Funktionen Art. 30 (3) c
• Umfangreiche Auditrechte bei kritischen und wichtigen Funktionen: Zutritt, Inspektionen und Audits durch Finanzunternehmen und Behörden, Zugang zu Dokumenten und Kopien, Kooperationspflichten Art. 30 (3) e

Prüfung

Kritische IKT-Drittdienstleister werden durch ihre zuständige Überwachungsbehörde jährlich auf die Einhaltung der o.g. Pflichten aus Art. 33 (3) überwacht. Die zuständige Behörde führt die Bewertung mit einem klaren, detaillierten Überwachungsplan durch, der jährliche Aufsichts­ziele und -maßnahmen enthält. Art. 33 (4)

Der Überwachungsplan wird den kritischen IKT-Dienstleistern als Entwurf übermittelt, die dann in 15 Tagen Lösungen vorschlagen können, falls die Überwachungstätigkeiten zu Risiken und negativen Auswirkungen für ihre Kunden außerhalb von DORA führen.

Aufsicht von Dienstleistern

Die ESA (European Supervisory Authorities) ernennen für jeden kritischen IKT-Drittdienstleister die EIOPA, ESMA oder EBA als federführende Überwachungsbehörde. Art. 33 (1b) Kritische IKT-Drittdienstleister stehen also unter direkter Aufsicht einer Behörde der EU-Finanzaufsicht.

Dieser EU-Überwachungsrahmen für IKT-Drittdienstleister ist aber eine Lösung nur im Kontext von DORA und soll kein generelles Aufsichtsmodell sein. Erwägungsgrund 76

Überwachungsforum

Ein Überwachungsforum wird die zuständigen EU-Überwachungsbehörden bei Risiken von IKT-Drittparteien unterstützen. Im Forum werden gemeinsame Positionen und Maßnahmen erarbeitet, Risiken und Schwachstellen erörtert und ein Ansatz zur Überwachung gefördert. Das Überwachungsforum legt für kritische IKT-Drittdienstleister Referenzwerte vor. Art. 32

Befugnisse Überwachungsbehörden

Um zu bewerten, ob kritische IKT-Drittdienstleister ihre DORA-Pflichten erfüllen, haben die EU-Überwachungsbehörden weitreichende Befugnisse gegenüber den Dienstleistern, u.a.:

• Auskunftsersuchen: Die Überwachungsbehörde kann verlangen, alle für die Überwachung notwendigen Informationen zur Verfügung zu stellen. Art. 37
• Allgemeine Untersuchungen: Die Überwachungsbehörde darf Untersuchungen beim IKT-Dienstleister durchführen und dazu Aufzeichnungen, Daten und Verfahren prüfen, Vertreter vorladen, die Abgabe von Erklärungen fordern, Personen befragen und Aufzeichnungen von Telefongesprächen und Datenübermittlungen anfordern.
  Sie kann für die Untersuchungen Dritte ermächtigen. Art. 38
• Inspektionen: Die Überwachungsbehörde dürfen in Geschäftsräumen, Grundstücken und Gebäuden des IKT-Drittdienstleisters Inspektionen durchführen. Sie dürfen Räumlichkeiten betreten und versiegeln. Art. 39
• Folgemaßnahmen: Die Überwachungsbehörde kann Informationen über die Umsetzung von Empfehlungen mit der für die Finanzunternehmen zuständigen Behörden teilen. In bestimten Fällen kann auch die Öffentlichkeit informiert werden, mit Nennung des IKT-Dienstleisters und Art der Nichtkonformität. Behörden können von Finanzunternehmen im Zweifel verlangen, die Nutzung des betroffenen IKT-Dienstleisters auszusetzen. Art. 42
• Sanktionierung: Die Überwachungsbehörden können Zwangsgelder verhängen, um kritische IKT-Drittdienstleister zur Einhaltung von Maßnahmen zu zwingen. Art. 35 (6-11)

Die ESA entwickeln technische Standards (RTS), um die Anforderungen an IKT-Drittdienstleister bei Pflichten und Überwachungstätigkeiten zu präzisieren. Art. 41

Berichte

Nach Überwachungstätigkeiten können die Behörden von den Dienstleistern Berichte über Maßnahmen anfordern und Empfehlungen zur Verbesserung aussprechen. Dabei stimmen sich Behörden untereinander ab, auch mit NIS2 Behörden, um eine Überschneidung von technischen und organisatorischen Maßnahmen zu vermeiden. Art. 35 (2)

Audit-Team

Behörden werden bei ihren Tätigkeiten wie den Untersuchungen und Inspektionen von einem Überwachungsteam unterstützt, das für jeden kritischen IKT-Dienstleister eingerichtet wird.

Das Team setzt sich wie folgt zusammen: Art. 40

• Mitarbeiter der ESA (European Supervisory Authorities)
• Mitarbeiter der zuständigen Behörde für Finanzunternehmen, die Dienstleistungen beziehen (in Deutschland primär die BaFin)
• (optional) Mitarbeiter der zuständigen NIS2-Behörde (in Deutschland z. B. das BSI)
• (optional) Mitarbeiter der nationalen Behörde des Mitgliedsstaats, in dem der IKT-Dienstleister seinen Sitz hat

Register kritischer Dienstleister

Die ESA veröffentlichen jährlich eine Liste der als kritisch eingestuften IKT-Dienstleister. Art. 31

Gesetzgebung

Zeitleiste

Das EU-Parlament und der Rat haben die DORA-Verordnung (2022/2554) am 14. Dezember 2022 beschlossen. DORA ist am 17. Januar 2023 in Kraft getreten und wird ab dem 17. Januar 2025 angewendet.

DORA-Framework

Die Europäischen Aufsichtsbehörden EBA, EIPOA und ESMA müssen bis zum 17. Juli 2024 ergänzende technische Regulierungsstandards (RTS) und technische Durchführungsstandards (ITS) zur Konkretisierung einzelner Anforderungen aus DORA veröffentlichen.

Review

DORA soll periodisch von der Kommission nach Konsultation der ESA und des ESRB gereviewed werden, mit dem ersten Report im Januar 2028.

Literatur

1. European System of Financial Supervision, European Central Bank, 2024.
2. ESAs publish first set of rules under DORA for ICT and third-party risk management and incident classification, European Securities and Markets Authority, 17.01.2024.
3. DORA - Digital Operational Resilience Act, Informationsseite der BaFin, Bundesanstalt für Finanzdiensleistungsaufsicht, 18.01.2024.
4. Markteintritt, Bundesanstalt für Finanzdiensleistungsaufsicht, o.D.
5. Übersicht der Merkblätter zu einzelnen Bankgeschäften, Bundesanstalt für Finanzdiensleistungsaufsicht, o.D.
6. Behandlung, Klassifizierung und Berichterstattung IKT-bezogener Vorfälle, Die BaFin informiert über Kapitel III, Artikel 17 bis 23 DORA, Bundesanstalt für Finanzdiensleistungsaufsicht, o.D.

Quellen

1. REGULATION (EU) 2022/2554 (DORA), on digital operational resilience for the financial sector, 14 December 2022
2. Verordnung (EU) 2022/2554 (DORA), über die digitale operationale Resilienz im Finanzsektor, 14. Dezember 2022
3. Verordnung über digitale Betriebsstabilität (DORA) Auf einen Blick, Plenum – November 2022, EPRS.
4. Gesetz über die Digitalisierung des Finanzmarktes (Finanzmarktdigitalisierungsgesetz - FinmadiG), Bundesministerium der Finanzen, 20.12.2023.