TL;DR

DORA (Digital Operational Resilience Act) zielt auf die digitale Resilienz des Finanzsektors ab. Wenn Sie eine Bank, ein Versicherer, ein Fintech-Unternehmen oder ein Technologieanbieter sind, der diese bedient, betrifft Sie dies.

Umfasst IKT-Risikomanagement, obligatorische Bedrohungstests (wie TLPT), Überwachung von Drittanbieter-Risiken und stringente Incident-Meldung.

In Kraft seit dem 17. Januar 2025 – mit empfindlichen Strafen für den Fall, dass man unvorbereitet ist.

DORA Scorecard Zusammenfassung:

• Aufwand für Entwickelnde: Mittel bis Hoch (Erfordert die Implementierung sicherer und widerstandsfähiger Codierungspraktiken, die Unterstützung eines robusten IKT-Risikomanagements, die Ermöglichung detaillierter Incident-Protokollierung/-Berichterstattung und die Teilnahme an fortgeschrittenen Resilienztests).
• Tooling-Kosten: Hoch (Erfordert Investitionen in ICT-Risikomanagement-Tools, fortschrittliche Sicherheitstest-Tools (Pentesting, TLPT), robustes Monitoring/SIEM, Drittanbieter-Risikomanagement-Plattformen, Business Continuity-/Disaster Recovery-Lösungen).
• Marktauswirkungen: Kritisch (Obligatorisch für praktisch alle EU-Finanzunternehmen und deren kritische IKT-Anbieter; setzt hohe Maßstäbe für die operative Resilienz).
• Flexibilität: Mäßig (Die Regulierung legt Anforderungen in wichtigen Säulen fest, erlaubt aber Verhältnismäßigkeit basierend auf Größe, Risikoprofil und Art/Komplexität der Dienste).
• Prüfungsintensität: Hoch (Compliance, überwacht von nationalen zuständigen Behörden und Europäischen Aufsichtsbehörden (ESAs); beinhaltet den Nachweis robuster Frameworks, Testergebnisse und Fähigkeiten im Incident Management).

Was ist DORA?

Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554), oder DORA, ist ein zentrales EU-Gesetz, das einheitliche Anforderungen an die Sicherheit von Netz- und Informationssystemen festlegt, die die Geschäftsprozesse von Finanzunternehmen unterstützen. Es schafft einen verbindlichen, umfassenden Rahmen, der speziell darauf ausgelegt ist, die IT-Sicherheit und die operationelle Resilienz des EU-Finanzsektors zu stärken.

Im Gegensatz zu NIS2, das breit gefächert anwendbar ist, konzentriert sich DORA ausschließlich auf Finanzunternehmen (Banken, Versicherer, Investmentfirmen, Zahlungsinstitute, Krypto-Asset-Anbieter usw.) und die kritischen IKT-Drittanbieter (wie Cloud-Plattformen, Softwareanbieter, Datenanalyseanbieter), die diese bedienen.

DORA basiert auf fünf Kernsäulen:

1. IKT-Risikomanagement: Verlangt von Unternehmen ein umfassendes, gut dokumentiertes IKT-Risikomanagement-Framework, einschließlich Strategien, Richtlinien, Verfahren, Protokollen und Tools zur Identifizierung, zum Schutz, zur Erkennung, zur Reaktion auf und zur Wiederherstellung von IKT-Risiken. Die Leitungsorgane tragen die letztendliche Verantwortung.
2. IKT-bezogenes Incident Management & Reporting: Schreibt Prozesse vor, um größere IKT-bezogene Vorfälle zu erkennen, zu verwalten, zu protokollieren, zu klassifizieren und den zuständigen Behörden unter Verwendung standardisierter Vorlagen und Zeitpläne zu melden.
3. Tests zur digitalen operationalen Resilienz: Verpflichtet Unternehmen, ein proportionales und risikobasiertes Testprogramm zur digitalen operationalen Resilienz einzurichten, das Schwachstellenanalysen, Netzwerksicherheitsanalysen, szenariobasierte Tests und für bedeutende Unternehmen fortgeschrittene Bedrohungsgesteuerte Penetrationstests (TLPT) mindestens alle drei Jahre umfasst.
4. IKT-Drittpartei-Risikomanagement: Legt strenge Regeln für das Management von Risiken fest, die mit der Abhängigkeit von IKT-Drittanbietern verbunden sind. Dies umfasst die vorvertragliche Due Diligence, spezifische Vertragsbestimmungen (Zugang, Audit, Sicherheit, Exit-Strategien), die Bewertung des Konzentrationsrisikos und die fortlaufende Überwachung.
5. Informationsaustausch: Fördert den freiwilligen Austausch von Informationen und Erkenntnissen zu Cyberbedrohungen zwischen Finanzinstituten, um die kollektive Sensibilisierung und Resilienz zu verbessern.

DORA zielt darauf ab, sicherzustellen, dass das Finanzsystem auch bei schwerwiegenden operativen Störungen, die aus IKT-Problemen oder Cyberangriffen resultieren, resilient bleiben kann. Es trat im Januar 2023 in Kraft, und Finanzunternehmen müssen bis zum 17. Januar 2025 konform sein.

Warum ist es wichtig?

DORA ist von entscheidender Bedeutung für den EU-Finanzsektor und sein Ökosystem:

• Harmonisierung: Schafft einen einzigen, konsistenten Regelsatz für die digitale operationale Resilienz in allen EU-Mitgliedstaaten und ersetzt fragmentierte nationale Ansätze.
• Finanzielle Stabilität: Zielt darauf ab, IKT-Vorfälle zu verhindern, die einzelne Finanzunternehmen oder das gesamte Finanzsystem destabilisieren könnten.
• Adressiert systemische Risiken: Erkennt die zunehmende Abhängigkeit von IKT und die potenziellen systemischen Risiken, die durch Ausfälle entstehen, insbesondere in Bezug auf kritische Drittanbieter.
• Direkte Aufsicht über kritische Anbieter: Gewährt europäischen Aufsichtsbehörden (ESAs wie EBA, ESMA, EIOPA) einzigartige direkte Aufsichtsbefugnisse über benannte kritische IKT-Drittanbieter (CTPPs).
• Obligatorische Compliance: Im Gegensatz zu einigen Frameworks ist DORA eine Verordnung, die direkt anwendbar und für alle betroffenen Unternehmen rechtsverbindlich ist.
• Erhöhte Resilienzanforderungen: Geht über die grundlegende Cybersicherheit hinaus und erfordert robuste Tests (einschließlich TLPT), detailliertes Incident Management und ein strenges Drittanbieter-Risikomanagement.
• Verantwortlichkeit des Managements: Ähnlich wie bei NIS2 wird dem Managementgremium eine klare Verantwortung für die Überwachung von IKT-Risiken zugewiesen.

Für Finanzunternehmen und ihre wichtigsten Technologiezulieferer ist die DORA Compliance unerlässlich für die behördliche Genehmigung, den Marktzugang und die Aufrechterhaltung der operativen Stabilität in der EU.

Was und wie implementieren (Technisch & Policy)

Die Implementierung von DORA erfordert erhebliche Anstrengungen in allen fünf Säulen und umfasst technische und politische Maßnahmen:

1. IKT-Risikomanagement-Framework (Art. 5-16):
   
   • Richtlinie/Strategie: Entwickeln und pflegen Sie ein solides, umfassendes ICT-Risikomanagement-Framework, das vom Management genehmigt wurde.
   • Technische Kontrollen: Implementieren Sie Sicherheitsmaßnahmen basierend auf der Risikobewertung – Identifikation, Schutz (sichere Konfigurationen, Patching, Netzwerksicherheit, physische Sicherheit), Erkennung (Überwachungssysteme, Anomalieerkennung), Reaktion und Wiederherstellung (Backups, Disaster-Recovery-Pläne). Dies umfasst Tools wie Firewalls, SIEM, EDR, Schwachstellenmanagement, IAM.
   • Dokumentation: Pflegen Sie eine umfassende Dokumentation des Frameworks, der Risikobewertungen, der Kontrollimplementierungen und der Wirksamkeitstests.
2. Incident Management & Berichterstattung (Art. 17-23):
   
   • Prozesse: Prozesse für die Überwachung, Erkennung, Klassifizierung (basierend auf Kriterien, die in den Regulatory Technical Standards – RTS definiert sind), Verwaltung, Protokollierung und Meldung schwerwiegender IKT-Vorfälle etablieren.
   • Technischer Support: Implementieren Sie Logging- und Monitoring-Tools (SIEM), die in der Lage sind, Vorfälle zu erkennen und die notwendigen Daten für die Berichterstattung zu sammeln. Entwickeln Sie Reporting-Workflows.
3. Digital Operational Resilience Testing (Art. 24-27):
   
   • Testprogramm: Etablieren Sie ein risikobasiertes Programm, das Schwachstellenbewertungen, Open-Source-Analysen, Netzwerksicherheitsbewertungen, physische Sicherheitsüberprüfungen, szenariobasierte Tests und Kompatibilitätstests umfasst.
   • Tools: Nutzen Sie Schwachstellenscanner, Konfigurationsscanner, DAST-, SAST-, SCA-Tools.
   • Bedrohungsbasiertes Penetration Testing (TLPT): Für bedeutende Unternehmen führen Sie fortgeschrittenes TLPT (wie TIBER-EU) basierend auf spezifischen RTS durch, unter Einbeziehung externer, zertifizierter Tester, die reale Angreifer simulieren. Erfordert ausgereifte Erkennungs- und Reaktionsfähigkeiten, um effektiv zu sein.
4. ICT-Drittrisikomanagement (Art. 28-44):
   
   • Strategie & Richtlinie: Entwickeln Sie eine Strategie und Richtlinie für das Management von Risiken im Zusammenhang mit IKT-Drittanbietern.
   • Informationsregister: Führen Sie ein detailliertes Register aller ICT-Drittanbieter-Dienstleistungsverträge.
   • Due Diligence: Führen Sie strenge Sicherheits- und Resilienzbewertungen durch, bevor Sie Verträge mit IKT-Anbietern abschließen.
   • Vertragliche Anforderungen (Art. 30): Stellen Sie sicher, dass Verträge obligatorische Klauseln zu Sicherheitsstandards, Auditrechten, Zusammenarbeit bei der Meldung von Vorfällen, klaren Leistungsbeschreibungen, Standorten der Datenverarbeitung und Exit-Strategien enthalten.
   • Aufsicht über kritische Drittanbieter (CTPPs): Kooperieren Sie mit ESAs bei direkten Aufsichtsaktivitäten von benannten CTPPs.
   • Konzentrationsrisiko: Risiken bewerten und managen, die mit einer starken Abhängigkeit von einzelnen oder wenigen Anbietern verbunden sind.
5. Informationsaustausch (Art. 45):
   
   • Beteiligen Sie sich (freiwillig) an Vereinbarungen zum Austausch von Cyber-Bedrohungsaufklärung und -informationen, um die GDPR-Compliance sicherzustellen.

Die Implementierung erfordert eine starke Governance, dedizierte Ressourcen, abteilungsübergreifende Zusammenarbeit (IT, Security, Risiko, Recht, Beschaffung) und oft erhebliche Investitionen in Technologie und Fachwissen.

Häufige Fehler, die es zu vermeiden gilt

Einrichtungen, die DORA implementieren, sollten diese häufigen Fehler vermeiden:

1. Implementierung verzögern: Zu langes Warten mit dem Beginn der umfangreichen Arbeiten, die für Gap-Analyse, Framework-Entwicklung, Testimplementierung und die Behebung von Drittanbieterverträgen vor der Frist im Januar 2025 erforderlich sind.
2. Umfang/Aufwand unterschätzen: Die Breite der DORA-Anforderungen über alle fünf Säulen hinweg nicht zu erfassen und die Compliance-Bemühungen unzureichend zu finanzieren.
3. Es nur als IT/Sicherheit behandeln: Risiko-, Rechts-, Beschaffungs- und das obere Management nicht ausreichend einbeziehen, insbesondere im Hinblick auf das IKT-Risikorahmenwerk und das Management von Drittanbieterrisiken.
4. Unzureichendes Drittanbieter-Risikomanagement: Versäumnis, eine angemessene Due Diligence durchzuführen, Verträge mit obligatorischen Klauseln zu aktualisieren oder das Konzentrationsrisiko im Zusammenhang mit IKT-Anbietern zu managen.
5. Unzureichende Resilienztests: Durchführung nur grundlegender Schwachstellen-Scans anstelle der umfassenden, risikobasierten Tests (einschließlich TLPT, wo erforderlich), die von DORA vorgeschrieben sind.
6. Mangelnde Bereitschaft zur Vorfallmeldung: Fehlen der technischen Überwachung oder interner Prozesse, um schwerwiegende Vorfälle genau und innerhalb der erforderlichen Fristen zu klassifizieren und zu melden.
7. Annahme, dass andere Frameworks ausreichen: Sich ausschließlich auf bestehende ISO 27001 oder andere Compliance zu verlassen, ohne eine spezifische Gap-Analyse gegen die detaillierten Anforderungen von DORA durchzuführen, insbesondere in Bezug auf Drittanbieter-Risiken und Resilienztests.

Was Auditoren/Regulierungsbehörden fragen könnten (Fokus Entwickelnde)

Aufsichtsbehörden, die die DORA-Compliance prüfen, werden weitreichende Befugnisse haben. Fragen, die Entwicklungsteams betreffen, könnten sich auf Resilienz, Security by Design, Tests und Incident Support konzentrieren:

• (IKT-Risikomanagement) „Wie werden Sicherheits- und Resilienzanforderungen in den Softwareentwicklungslebenszyklus integriert?“
• (IKT-Risikomanagement) „Zeigen Sie Nachweise für sichere Codierungspraktiken und Schwachstellenmanagement innerhalb der Entwicklung.“
• (Incident-Management) „Wie erleichtert die Protokollierung der Anwendung die Erkennung, Analyse und Meldung von IKT-bezogenen Vorfällen?“
• (Resilienz-Tests) „Welche Sicherheitstests (statisch, dynamisch, Komponenten) werden an der Anwendung durchgeführt? Legen Sie aktuelle Ergebnisse vor.“
• (Resilienz-Tests) „Wie ist die Anwendung konzipiert, um Ausfällen oder hoher Last standzuhalten (z. B. Redundanz, Skalierbarkeit, Failover-Mechanismen)?“
• (Resilienz-Tests) „Können Sie den Prozess zur Wiederherstellung der Anwendung und ihrer Daten aus Backups demonstrieren?“
• (Drittanbieter-Risiko) „Wie verwalten Sie Sicherheitsrisiken im Zusammenhang mit Drittanbieter-Softwarekomponenten oder APIs, die in die Anwendung integriert sind?“

Regulierungsbehörden werden dokumentierte Frameworks, Richtlinien, Verfahren, Testergebnisse, Incident-Protokolle und Nachweise erwarten, dass Resilienz in Systeme und Prozesse integriert ist.

Quick Wins für Entwicklungsteams

Obwohl die vollständige DORA Compliance komplex ist, können Dev-Teams durch grundlegende Praktiken dazu beitragen:

1. Anwendungs-Protokollierung verbessern: Erweitern Sie Anwendungs-Logs, um sicherheitsrelevante Ereignisse und Fehler für die Incident-Analyse zu erfassen. Stellen Sie sicher, dass die Logs zentralisiert sind.
2. SAST/SCA integrieren: Integrieren Sie automatisierte Sicherheitsscans für Code und Abhängigkeiten frühzeitig in die CI/CD-Pipeline.
3. Fokus auf Resilienz-Muster: Betonung von Codierungspraktiken, die die Resilienz verbessern (z. B. korrekte Fehlerbehandlung, Timeouts, Wiederholungsversuche, Zustandslosigkeit wo möglich).
4. Abhängigkeiten dokumentieren: Pflegen Sie eine genaue Software-Stückliste (SBOM) für Anwendungen.
5. Fehlerszenarien testen: Fügen Sie Tests hinzu, wie sich die Anwendung unter Fehlerbedingungen verhält (z.B. Abhängigkeit nicht verfügbar, hohe Last).
6. Sichere Konfiguration: Sicherstellen, dass Anwendungen sichere Standardkonfigurationen haben und Konfigurationseinstellungen angemessen externalisieren.

Ignorieren Sie dies und... (Konsequenzen der Nichteinhaltung)

DORA gewährt den zuständigen Behörden erhebliche Aufsichts- und Durchsetzungsbefugnisse. Nichteinhaltung kann zu Folgendem führen:

• Administrative Strafen/Bußgelder: Während DORA selbst keine pauschalen spezifischen Bußgeldbeträge festlegt (einige Umsetzungen den Mitgliedstaaten überlässt), kann die Nichteinhaltung zugrunde liegender Richtlinien/Verordnungen, die es verstärkt, oder die Nichtbefolgung von Anordnungen zuständiger Behörden zu erheblichen Bußgeldern führen (potenziell bis zu 1-2 % des weltweiten Umsatzes oder spezifische Beträge wie 10 Mio. €, abhängig von der nationalen Umsetzung und spezifischen Verstößen). Korrektur: Einige Quellen erwähnen periodische Zwangsgelder von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes für kritische Drittanbieter, die direkt von den ESAs beaufsichtigt werden. Nationale Strafen für Finanzunternehmen selbst variieren, werden aber voraussichtlich erheblich sein.
• Korrekturmaßnahmen: Behörden können Unternehmen anweisen, ein Verhalten einzustellen, spezifische Abhilfemaßnahmen zu implementieren oder spezifische Informationen bereitzustellen.
• Öffentliche Bekanntmachungen: Behörden können öffentliche Bekanntmachungen herausgeben, die die nicht-konforme Entität und die Art des Verstoßes identifizieren.
• Entzug der Genehmigung: In schwerwiegenden Fällen könnte die Genehmigung des Finanzinstituts entzogen werden.
• Sanktionen für das Management: Potenzielle administrative Strafen oder temporäre Verbote für Mitglieder des Managementgremiums, die für Verstöße verantwortlich sind.
• Reputationsschaden: Die öffentliche Offenlegung von Nichteinhaltung der Compliance oder daraus resultierenden Vorfällen schädigt das Vertrauen im Finanzsektor erheblich.
• Betriebliche Einschränkungen: Behörden können betriebliche Einschränkungen auferlegen, bis die Compliance wiederhergestellt ist.

FAQ

Wer muss DORA einhalten?

DORA gilt für eine Vielzahl von EU-Finanzunternehmen, darunter Banken, Kreditinstitute, Zahlungsinstitute, Wertpapierfirmen, Versicherungs-/Rückversicherungsunternehmen, Krypto-Asset-Dienstleister, Crowdfunding-Plattformen, zentrale Gegenparteien (CCPs), Transaktionsregister, Verwalter alternativer Investmentfonds (AIFMs), OGAW-Verwaltungsgesellschaften sowie kritische IKT-Drittdienstleister, die von den europäischen Aufsichtsbehörden benannt wurden.

Was ist die Frist für die DORA-Compliance?

Finanzinstitute müssen bis zum 17. Januar 2025 vollständig mit DORA konform sein.

Wie verhält sich DORA zu NIS2?

DORA stellt eine lex specialis für den Finanzsektor dar. Dies bedeutet, dass Finanzunternehmen, die sowohl unter DORA als auch unter NIS2 fallen, primär die spezifischeren Anforderungen von DORA in Bezug auf IKT-Risikomanagement, Meldung von Vorfällen, Resilienztests und Drittanbieterrisiken befolgen. NIS2 gilt weiterhin für Aspekte, die nicht von DORA abgedeckt sind.

Was ist Threat-Led Penetration Testing (TLPT) unter DORA?

TLPT ist eine fortgeschrittene Form des Resilienz-Testings, die für bedeutende Finanzunternehmen unter DORA (Artikel 26) vorgeschrieben ist. Dabei werden die Taktiken, Techniken und Verfahren (TTPs) realer Bedrohungsakteure simuliert, die auf die kritischen Funktionen und zugrunde liegenden Systeme des Unternehmens abzielen. Es basiert auf Frameworks wie TIBER-EU und erfordert zertifizierte externe Tester.

Gilt DORA für Cloud-Anbieter?

Ja, erheblich. Cloud-Dienstleister gelten unter DORA als IKT-Drittanbieter. Finanzunternehmen, die Cloud-Dienste nutzen, müssen strenge Anforderungen an das Drittparteien-Risikomanagement anwenden (Art. 28-30). Darüber hinaus unterliegen Cloud-Anbieter, die von den Europäischen Aufsichtsbehörden als „kritisch“ eingestuft werden, einer direkten Aufsicht und potenziellen Sanktionen (Art. 31-44).

Was sind die Hauptsäulen von DORA?

Die fünf Kernpfeiler sind:

1. IKT-Risikomanagement
2. Management und Meldung von ICT-Vorfällen
3. Digital Operational Resilience Testing
4. IKT-Drittanbieter-Risikomanagement
5. Vereinbarungen zum Informationsaustausch

Gibt es eine Zertifizierung für DORA?

Nein, DORA selbst etabliert kein Zertifizierungsschema. Die Compliance wird von nationalen zuständigen Behörden und den Europäischen Aufsichtsbehörden (für kritische IKT-Drittanbieter) überwacht und durchgesetzt. Unternehmen weisen die Compliance durch ihre implementierten Frameworks, Richtlinien, Testergebnisse, Incident Reports und die Zusammenarbeit mit Aufsichtsbehörden nach.