DORA für den Finanzsektor: Was kommt nach NIS2?

DORA und NIS2: Warum der Finanzsektor eine eigene Verordnung braucht

Wenn du im Finanzsektor arbeitest, hast du in den letzten Jahren zwei große regulatorische Wellen erlebt: NIS2 und DORA. Beide adressieren Cybersicherheit und operationelle Resilienz, aber sie tun es auf unterschiedliche Weise und mit unterschiedlichem Detailgrad.

NIS2 ist eine Richtlinie, die von den Mitgliedstaaten in nationales Recht umgesetzt werden muss. Sie richtet sich branchenübergreifend an Unternehmen in kritischen und wichtigen Sektoren, darunter auch der Finanzsektor. NIS2 definiert Mindestanforderungen an Cybersicherheit, Meldepflichten und Governance.

DORA ist eine Verordnung, die unmittelbar und einheitlich in allen EU-Mitgliedstaaten gilt, ohne nationale Umsetzung. Sie richtet sich ausschließlich an den Finanzsektor und ist deutlich detaillierter als NIS2. DORA definiert nicht nur "Was" umgesetzt werden muss, sondern in vielen Bereichen auch "Wie".

Das Verhältnis zwischen beiden ist klar geregelt: DORA geht als lex specialis (sektorspezifisches Gesetz) vor NIS2 (allgemeines Gesetz). Finanzunternehmen, die DORA vollständig umsetzen, erfüllen damit automatisch die sektorspezifischen Anforderungen, die NIS2 an sie stellen würde. Du musst also nicht beide Regelwerke parallel umsetzen, sondern dich auf DORA konzentrieren.

Warum braucht der Finanzsektor überhaupt eine eigene Verordnung? Weil die Abhängigkeit des Finanzsektors von Informations- und Kommunikationstechnologie (ICT) so groß ist, dass ein Ausfall oder eine Kompromittierung weitreichende Folgen für die Finanzstabilität haben kann. Eine Großbank, deren Core-Banking-System für drei Tage ausfällt, verursacht nicht nur einen wirtschaftlichen Schaden für sich selbst, sondern kann eine Kettenreaktion auslösen, die den gesamten Zahlungsverkehr beeinträchtigt. DORA adressiert dieses systemische Risiko mit einem Detailgrad, den NIS2 als branchenübergreifende Regelung nicht bieten kann.

Wer ist von DORA betroffen?

DORA betrifft praktisch den gesamten Finanzsektor der EU. Artikel 2 der Verordnung listet 21 Kategorien von Finanzunternehmen auf:

• Kreditinstitute (Banken und Sparkassen)
• Zahlungsinstitute und E-Geld-Institute
• Wertpapierfirmen
• Zentralverwahrer
• Zentrale Gegenparteien (CCPs)
• Handelsplätze
• Transaktionsregister
• Verwalter alternativer Investmentfonds und OGAW-Verwaltungsgesellschaften
• Versicherungs- und Rückversicherungsunternehmen
• Versicherungsvermittler
• Einrichtungen der betrieblichen Altersversorgung
• Ratingagenturen
• Crowdfunding-Dienstleister
• Krypto-Dienstleister
• Administratoren kritischer Benchmarks

Zusätzlich betrifft DORA die ICT-Drittdienstleister, die für Finanzunternehmen tätig sind. Wenn dein Unternehmen IT-Dienste für Banken, Versicherungen oder andere Finanzunternehmen erbringt, bist du indirekt von DORA betroffen, weil deine Kunden die DORA-Anforderungen an dich weitergeben müssen.

Eine wichtige Ausnahme: Für kleine und weniger komplexe Finanzunternehmen gelten vereinfachte Anforderungen in bestimmten Bereichen. Die genaue Abgrenzung hängt von der Größe, dem Risikoprofil und der Komplexität des Unternehmens ab.

Die fünf Säulen von DORA

DORA ist in fünf thematische Säulen gegliedert, die zusammen ein umfassendes Framework für die digitale operationelle Resilienz bilden.

Säule 1: ICT-Risikomanagement (Artikel 5 bis 16)

Die erste und umfangreichste Säule definiert die Anforderungen an das Management von ICT-Risiken. Sie verlangt einen umfassenden, dokumentierten und regelmäßig aktualisierten ICT-Risikomanagement-Rahmen.

Governance. Die Leitungsorgane (Vorstand, Geschäftsführung) tragen die Gesamtverantwortung für das ICT-Risikomanagement. Sie müssen das ICT-Risikomanagement-Framework genehmigen und überwachen, ausreichende Ressourcen bereitstellen, die ICT-Strategie festlegen und regelmäßig über ICT-Risiken informiert werden. Das geht über das hinaus, was NIS2 an Governance-Anforderungen stellt, und macht die Geschäftsleitung in höherem Maße rechenschaftspflichtig.

Identifizierung. Finanzunternehmen müssen alle ICT-gestützten Geschäftsfunktionen, ICT-Assets, Datenbestände und Abhängigkeiten identifizieren, klassifizieren und dokumentieren. Das umfasst ein vollständiges Inventar aller ICT-Assets mit Zuordnung zu Geschäftsfunktionen und Risikobewertung.

Schutzmaßnahmen. DORA verlangt ein umfassendes Set an Schutzmaßnahmen: Zugangskontrolle, Netzwerksicherheit, Kryptografie, Datensicherheit, physische Sicherheit und Sicherheit des Personals. Viele dieser Anforderungen entsprechen ISO 27001 Annex A, aber DORA konkretisiert sie mit branchenspezifischen Erwartungen.

Erkennung. Finanzunternehmen müssen Mechanismen zur Erkennung anomaler Aktivitäten implementieren, einschließlich ICT-bezogener Vorfälle. DORA fordert explizit automatisierte Erkennungsmechanismen und regelmäßige Tests der Erkennungsfähigkeiten.

Reaktion und Wiederherstellung. DORA verlangt Business-Continuity-Pläne für ICT-bezogene Störungen, einschließlich Wiederherstellungsziele (RTO und RPO), regelmäßiger Tests und einer Kommunikationsstrategie für Krisenfälle. Die Anforderungen an Backup und Restore sind deutlich detaillierter als in ISO 27001.

Lernen und Weiterentwicklung. Finanzunternehmen müssen aus ICT-Vorfällen und Tests lernen und ihre Maßnahmen kontinuierlich verbessern. DORA fordert Post-Incident-Reviews und die Einbeziehung der Erkenntnisse in das ICT-Risikomanagement.

Säule 2: ICT-bezogenes Incident Reporting (Artikel 17 bis 23)

DORA definiert einen einheitlichen Meldeprozess für schwerwiegende ICT-bezogene Vorfälle.

Klassifizierung von Vorfällen. Finanzunternehmen müssen ICT-bezogene Vorfälle nach definierten Kriterien klassifizieren: Anzahl der betroffenen Kunden, Dauer des Ausfalls, geografische Ausbreitung, Datenverlust, Auswirkung auf kritische Dienste und wirtschaftlicher Schaden. Vorfälle, die bestimmte Schwellenwerte überschreiten, gelten als "schwerwiegend" und müssen gemeldet werden.

Meldepflichten. Schwerwiegende ICT-bezogene Vorfälle müssen der zuständigen Aufsichtsbehörde gemeldet werden. Der Meldeprozess umfasst drei Stufen: eine Erstmeldung innerhalb von vier Stunden nach Einstufung als schwerwiegend (spätestens 24 Stunden nach Erkennung), eine Zwischenmeldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats.

Die Meldefristen sind straffer als bei NIS2. Insbesondere die Vier-Stunden-Frist nach der Einstufung erfordert, dass der Vorfall-Klassifizierungsprozess schnell und zuverlässig funktioniert. Ein Unternehmen, das einen halben Tag braucht, um zu entscheiden, ob ein Vorfall schwerwiegend ist, verletzt bereits die Meldepflicht.

Freiwillige Meldung von Cyber-Bedrohungen. DORA ermöglicht zusätzlich die freiwillige Meldung signifikanter Cyber-Bedrohungen an die Aufsichtsbehörde, auch wenn noch kein Vorfall eingetreten ist.

Säule 3: Digital Operational Resilience Testing (Artikel 24 bis 27)

DORA verlangt ein umfassendes Testprogramm für die digitale operationelle Resilienz.

Basis-Tests. Alle Finanzunternehmen müssen regelmäßig Basis-Tests durchführen: Schwachstellenscans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Gap-Analysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scanning-Software-Lösungen, Source-Code-Reviews (wo möglich), szenariobasierte Tests, Kompatibilitätstests, Performance-Tests und End-to-End-Tests. Die Frequenz und der Umfang richten sich nach dem Risikoprofil des Unternehmens.

Threat-Led Penetration Testing (TLPT). Für systemrelevante Finanzunternehmen verlangt DORA alle drei Jahre ein Threat-Led Penetration Testing nach dem TIBER-EU-Framework. TLPT unterscheidet sich grundlegend von einem klassischen Penetrationstest: Es simuliert einen realistischen Angriff auf die produktiven Systeme des Unternehmens, basierend auf aktuellen Bedrohungsinformationen (Threat Intelligence) und durchgeführt von spezialisierten Red-Team-Anbietern.

Ein TLPT umfasst drei Phasen: In der Threat-Intelligence-Phase erstellt ein spezialisierter Anbieter ein Bedrohungsprofil, das auf realen Bedrohungsakteuren basiert, die das Unternehmen angreifen könnten. In der Red-Team-Phase versucht ein unabhängiges Red Team, auf Basis dieses Profils die kritischen Funktionen des Unternehmens zu kompromittieren. In der Purple-Team-Phase arbeiten Red Team und das interne Blue Team zusammen, um die Erkenntnisse zu analysieren und Verbesserungen abzuleiten.

TLPT ist kostspielig (typischerweise 200.000 bis 500.000 Euro pro Durchlauf) und organisatorisch aufwändig. Es erfordert die Einbindung der Aufsichtsbehörde, die den gesamten Prozess überwacht.

Säule 4: Management des ICT-Drittparteienrisikos (Artikel 28 bis 44)

Die vierte Säule ist für viele Finanzunternehmen die größte Herausforderung. DORA stellt umfassende Anforderungen an das Management von Risiken, die aus der Nutzung von ICT-Dienstleistern entstehen.

Informationsregister. Finanzunternehmen müssen ein vollständiges Register aller vertraglichen Vereinbarungen mit ICT-Drittdienstleistern führen. Das Register muss den Dienstleister identifizieren, die erbrachten Dienstleistungen beschreiben, die Kritikalität der Dienstleistung bewerten und Sub-Outsourcing-Ketten dokumentieren.

Due Diligence und Risikobewertung. Vor dem Abschluss eines Vertrags mit einem ICT-Drittdienstleister muss das Finanzunternehmen eine Due Diligence durchführen, die Risiken bewerten und sicherstellen, dass der Dienstleister die notwendigen Sicherheitsanforderungen erfüllen kann.

Vertragliche Mindestanforderungen. DORA definiert in Artikel 30 detaillierte Mindestanforderungen an Verträge mit ICT-Drittdienstleistern. Dazu gehören: Service Level Descriptions, Audit- und Zugangsrechte, Kooperationspflichten bei Vorfällen, Datenlokalisierung, Exit-Strategien und Sub-Outsourcing-Regelungen.

Konzentrationsrisiko. Finanzunternehmen müssen Konzentrationsrisiken bewerten: Wie abhängig bin ich von einem einzelnen ICT-Dienstleister? Was passiert, wenn dieser Dienstleister ausfällt? DORA fordert, dass Finanzunternehmen ihre Abhängigkeiten diversifizieren und Exit-Strategien vorhalten.

Aufsichtsrahmen für kritische ICT-Drittdienstleister. Besonders bemerkenswert ist der neue Aufsichtsrahmen für ICT-Drittdienstleister, die als "kritisch" eingestuft werden (typischerweise große Cloud-Provider und IT-Outsourcing-Anbieter, die für viele Finanzunternehmen systemrelevant sind). Diese Dienstleister werden direkt von den europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) überwacht.

Säule 5: Informationsaustausch (Artikel 45)

DORA ermutigt Finanzunternehmen, Informationen über Cyber-Bedrohungen und Schwachstellen untereinander und mit den Aufsichtsbehörden auszutauschen. Dieser Austausch soll auf vertrauenswürdigen Plattformen stattfinden und dient der kollektiven Stärkung der Cyber-Resilienz des Finanzsektors.

DORA umsetzen: Die pragmatische Vorgehensweise

Die Umsetzung von DORA ist für die meisten Finanzunternehmen kein Greenfield-Projekt. Die meisten haben bereits regulatorische Anforderungen an IT-Sicherheit und operationelle Resilienz umgesetzt (BAIT, VAIT, KAIT, MaRisk, ISO 27001). Die Frage ist: Was kommt mit DORA hinzu, und wo muss nachgebessert werden?

Schritt 1: Gap-Analyse durchführen

Vergleiche deine bestehenden Maßnahmen, Prozesse und Dokumentationen mit den DORA-Anforderungen. Identifiziere die Lücken. Typische Bereiche, in denen auch gut aufgestellte Finanzunternehmen Nachholbedarf haben:

• Das vollständige ICT-Drittparteienregister (oft existiert nur eine unvollständige Liste)
• Vertragliche Anforderungen an ICT-Dienstleister (oft fehlen DORA-spezifische Klauseln)
• Incident-Klassifizierung und Meldeprozess nach DORA-Kriterien (oft nur generisch)
• Digital Operational Resilience Testing-Programm (oft nur Schwachstellenscans, kein umfassendes Testprogramm)
• TLPT-Bereitschaft (für systemrelevante Institute)

Schritt 2: Governance anpassen

Stelle sicher, dass die Leitungsorgane ihre DORA-Verantwortung kennen und wahrnehmen. Das umfasst: Genehmigung des ICT-Risikomanagement-Frameworks, Festlegung der ICT-Strategie, regelmäßige Berichterstattung über ICT-Risiken an den Vorstand und Sicherstellung ausreichender Ressourcen und Kompetenzen.

Schritt 3: ICT-Risikomanagement-Framework aktualisieren

Überarbeite dein bestehendes ICT-Risikomanagement, um die DORA-spezifischen Anforderungen abzudecken. Das umfasst die vollständige Identifizierung und Klassifizierung aller ICT-Assets, die Bewertung der Abhängigkeiten zwischen Geschäftsfunktionen und ICT-Systemen und die Definition von Schutzmaßnahmen, Erkennungsmechanismen und Wiederherstellungsprozessen.

Schritt 4: Third Party Risk Management aufbauen

Das vollständige ICT-Drittparteienregister ist oft die aufwändigste Aufgabe. Erfasse alle Vertragsbeziehungen, klassifiziere sie nach Kritikalität, prüfe die vertraglichen Regelungen und ergänze fehlende DORA-Klauseln. Für kritische ICT-Dienstleister entwickle Exit-Strategien und bewerte Konzentrationsrisiken.

Schritt 5: Incident-Reporting-Prozess implementieren

Implementiere den dreistufigen Meldeprozess mit den DORA-spezifischen Fristen und Klassifizierungskriterien. In ISMS Lite lässt sich der Incident-Reporting-Prozess strukturiert abbilden, sodass die Vier-Stunden-Frist nicht an fehlender Dokumentation scheitert. Stelle sicher, dass der Prozess auch außerhalb der Geschäftszeiten funktioniert, denn ICT-Vorfälle halten sich nicht an Bürozeiten.

Schritt 6: Testprogramm aufsetzen

Erstelle ein mehrjähriges Testprogramm, das die verschiedenen Testarten (Basis-Tests, erweiterte Tests, TLPT) in einem sinnvollen Rhythmus abdeckt. Beginne mit einer Bestandsaufnahme der bereits durchgeführten Tests und identifiziere die Lücken.

DORA und ISO 27001: Synergien nutzen

Wenn du bereits ein ISMS nach ISO 27001 betreibst, hast du eine solide Grundlage für die DORA-Umsetzung. Die Überlappung liegt bei geschätzten 60 bis 70 Prozent, je nachdem, wie reif dein ISMS ist.

Was ISO 27001 bereits abdeckt: ICT-Risikomanagement-Grundlagen, Schutzmaßnahmen (Zugangskontrolle, Kryptografie, Netzwerksicherheit), Incident Management, Business Continuity, Lieferantenmanagement und interne Audits.

Was DORA zusätzlich fordert: das detaillierte ICT-Drittparteienregister, die spezifischen Meldepflichten und -fristen, das umfassende Testprogramm inklusive TLPT, die explizite Governance-Verantwortung der Leitungsorgane für ICT-Risiken und die branchenspezifischen Detailanforderungen in vielen Bereichen.

Die pragmatische Strategie: Nutze dein bestehendes ISMS als Fundament und ergänze die DORA-spezifischen Anforderungen. Du musst nicht alles neu aufbauen, sondern gezielt die Lücken schließen.

Sanktionen und Aufsicht

DORA überträgt die Aufsicht über die Einhaltung den nationalen Finanzaufsichtsbehörden (in Deutschland primär BaFin und Bundesbank). Die Sanktionsmöglichkeiten umfassen Verwaltungsmaßnahmen und Bußgelder, deren genaue Höhe von den Mitgliedstaaten im Rahmen ihrer nationalen Gesetzgebung festgelegt wird.

Was schwerer wiegt als Bußgelder: Die Aufsichtsbehörde kann operative Beschränkungen verhängen, etwa das Verbot bestimmter Geschäftsaktivitäten oder die Anordnung, Verträge mit ICT-Drittdienstleistern zu beenden, die als Risiko eingestuft werden. Für ein Finanzunternehmen kann eine solche Anordnung existenzbedrohend sein.

Der Aufsichtsrahmen für kritische ICT-Drittdienstleister ist besonders bemerkenswert: Die europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) haben die Befugnis, direkte Prüfungen bei kritischen ICT-Drittdienstleistern durchzuführen, Empfehlungen auszusprechen und bei Nichteinhaltung Sanktionen zu verhängen. Das betrifft vor allem die großen Cloud-Provider (AWS, Azure, Google Cloud), die für viele Finanzunternehmen systemrelevante Infrastruktur bereitstellen.

Typische Herausforderungen bei der DORA-Umsetzung

Das Drittparteienregister

Für viele Finanzunternehmen ist das vollständige ICT-Drittparteienregister die größte operative Herausforderung. Die Anforderung klingt simpel: Erfasse alle Vertragsbeziehungen mit ICT-Dienstleistern. In der Praxis bedeutet das, jeden Vertrag zu identifizieren, der einen ICT-Bezug hat, die Kritikalität zu bewerten, Sub-Outsourcing-Ketten zu dokumentieren und Konzentrationsrisiken zu analysieren.

Ein mittelständisches Finanzunternehmen hat typischerweise 50 bis 200 ICT-Dienstleisterbeziehungen. Viele davon sind dem zentralen Einkauf oder der IT-Abteilung bekannt, aber Schatten-IT (Cloud-Dienste, die Fachabteilungen eigenständig beschafft haben) und indirekte Abhängigkeiten (Sub-Auftragnehmer deiner Dienstleister) werden oft übersehen. Die vollständige Erfassung erfordert eine systematische Inventur, die alle Abteilungen einbezieht. Nicht selten deckt man dabei auch Shadow IT auf, die bisher unter dem Radar der zentralen IT lief.

Exit-Strategien für kritische Dienstleister

DORA verlangt, dass Finanzunternehmen Exit-Strategien für kritische ICT-Dienstleister vorhalten. Das bedeutet: Du musst einen dokumentierten Plan haben, wie du den Dienstleister wechseln kannst, ohne deine Geschäftsprozesse wesentlich zu beeinträchtigen. Für Cloud-Migrationen kann das bedeuten, dass du Multi-Cloud-Fähigkeit sicherstellen, Datenportabilität vertraglich vereinbaren und regelmäßig die Machbarkeit der Exit-Strategie testen musst.

In der Praxis ist das für viele Finanzunternehmen eine enorme Herausforderung, besonders wenn sie tief in das Ökosystem eines einzelnen Cloud-Providers integriert sind. Die Exit-Strategie muss realistisch und getestet sein, ein Papierdokument, das einen theoretischen Migrationspfad beschreibt, reicht nicht aus.

Meldeprozesse rund um die Uhr

Die Vier-Stunden-Frist für die Erstmeldung nach der Einstufung eines Vorfalls als schwerwiegend erfordert, dass der Incident-Response-Prozess auch außerhalb der Geschäftszeiten funktioniert. Für mittelständische Finanzunternehmen ohne 24/7-Security-Operations-Center bedeutet das: Rufbereitschaft, klare Eskalationswege und vorbereitete Meldeformulare, die im Ernstfall schnell ausgefüllt und abgesetzt werden können.

Weiterführende Artikel

• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• NIS2 vs. ISO 27001: Gemeinsamkeiten, Unterschiede und Synergien
• Cyber Resilience Act: Neue Pflichten für Hersteller von Produkten mit digitalen Elementen
• Risikobewertung im ISMS: Methodik, Vorgehensweise und Praxistipps
• Lieferantenbewertung und Sicherheitsfragebögen: So prüfst du deine Dienstleister