DORA und NIS2 gleichzeitig: Wie Finanzdienstleister den Compliance-Doppeldruck managen

⏱ 14 Min. Lesezeit

DORA ist seit Januar 2025 anwendbar, NIS2 seit Dezember 2025 in deutsches Recht überführt. Für Finanzdienstleister bedeutet das: zwei Regulierungen mit unterschiedlichen Fristen, Definitionen und Meldesystemen – aber massiven inhaltlichen Überschneidungen. Wer beide Regelwerke isoliert bearbeitet, verdoppelt den Aufwand ohne Mehrwert. Wer die Synergien versteht, spart Millionen und baut ein integriertes Compliance-System, das tatsächlich Sicherheit schafft. Dieser Artikel zeigt, wo sich DORA und NIS2 überschneiden, wo sie sich unterscheiden und was Finanzunternehmen einmal statt zweimal machen können.

Das Wichtigste in Kürze

• DORA (Digital Operational Resilience Act) gilt seit 17. Januar 2025, NIS2 seit Dezember 2025 in deutschem Recht – Finanzdienstleister müssen beide gleichzeitig erfüllen
• DORA ist lex specialis für den Finanzsektor und hat bei Überschneidungen Vorrang, aber NIS2 greift zusätzlich, wenn DORA einen Bereich nicht abdeckt
• Die größte Effizienz liegt in einem integrierten ICT-Risikomanagement, das beide Frameworks bedient – statt zwei paralleler Compliance-Projekte
• IT-Drittparteien-Risikomanagement (TPRM) ist die gemeinsame Schwachstelle: DORA fordert ein Register of Information, NIS2 verlangt Supply-Chain-Sicherheit – beides lässt sich zusammenführen
• Meldepflichten unterscheiden sich erheblich: DORA verlangt 24-Stunden-Erstmeldung an die BaFin, NIS2 fordert „unverzügliche“ Meldung an das BSI – zwei unterschiedliche Systeme, die parallel bedient werden müssen

Zwei Regulierungen, ein Ziel – aber unterschiedliche Wege

Sowohl DORA als auch NIS2 verfolgen dasselbe übergeordnete Ziel: die Cyber-Resilienz in Europa zu stärken. Beide fordern Risikomanagement, Incident Reporting, Penetration Testing und die Absicherung von Lieferketten. Der fundamentale Unterschied liegt im Scope und in der Spezifität.

DORA ist eine EU-Verordnung, die direkt gilt – ohne nationale Umsetzung. Sie richtet sich ausschließlich an den Finanzsektor: Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister, Kryptowerte-Dienstleister und deren kritische IKT-Drittdienstleister. DORA definiert granulare Anforderungen an die digitale operationale Resilienz, vom ICT-Risikomanagement über das Incident Reporting bis zum Threat-Led Penetration Testing (TLPT).

NIS2 ist eine EU-Richtlinie, die in nationales Recht umgesetzt werden musste. In Deutschland geschah das durch das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, das im Dezember 2025 in Kraft trat. NIS2 gilt sektorübergreifend für „wesentliche“ und „wichtige“ Einrichtungen in 18 Sektoren – darunter auch der Finanzsektor. Die Anforderungen sind weniger granular als DORA, decken dafür aber ein breiteres Spektrum ab.

Lex specialis: Was bedeutet der Vorrang von DORA?

DORA gilt als lex specialis gegenüber NIS2 im Finanzsektor. Das bedeutet: Wo DORA spezifische Anforderungen definiert, haben diese Vorrang vor den allgemeineren NIS2-Vorgaben. Die NIS2-Richtlinie selbst bestätigt das in Artikel 4 Absatz 2 und verweist explizit auf DORA als sektorspezifische Regelung.

In der Praxis ist das aber komplizierter, als es klingt. Das lex-specialis-Prinzip bedeutet nicht, dass NIS2 für Finanzunternehmen irrelevant ist. Es bedeutet nur, dass DORA dort Vorrang hat, wo es die gleichen Themen detaillierter regelt. In Bereichen, die DORA nicht abdeckt – etwa Lieferkettensicherheit jenseits von IKT-Dienstleistern oder die Sicherheit von OT-Systemen – greift NIS2 weiterhin.

Einen detaillierten Blick darauf, wie die BaFin die DORA-Umsetzung prüft, bietet unser Artikel auf MyBusinessFuture: DORA: BaFin prüft Finanzinstitute.

Überschneidungen: Was einmal reicht

Die gute Nachricht: Etwa 60-70 Prozent der Anforderungen von DORA und NIS2 überschneiden sich inhaltlich. Wer diese Synergien nutzt, vermeidet massive Doppelarbeit. Hier die wichtigsten Bereiche, in denen eine einzige Implementierung beide Frameworks bedient:

ICT-Risikomanagement

DORA (Kapitel II, Artikel 5-16) fordert ein umfassendes ICT-Risikomanagement-Framework. NIS2 verlangt in Artikel 21 „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“ zum Risikomanagement. In der Praxis: Ein nach DORA aufgebautes ICT-Risk-Framework erfüllt automatisch die NIS2-Anforderungen an das Risikomanagement – DORA ist hier detaillierter und strenger.

● Einmal implementieren: ICT-Risikomanagement-Framework nach DORA-Standard. Dieses Framework deckt alle NIS2-relevanten Risikomanagement-Anforderungen ab.

● Dokumentation anpassen: Die DORA-Dokumentation mit NIS2-spezifischen Referenzen ergänzen, damit bei Prüfungen beider Regulierungen die Nachweisführung steht.

Incident Response und Management

Beide Regelwerke fordern strukturiertes Incident Management. DORA definiert in Kapitel III (Artikel 17-23) detaillierte Anforderungen an Klassifizierung, Meldung und Nachbereitung von IKT-Vorfällen. NIS2 fordert in Artikel 23 ein „Frühwarnsystem“ und strukturierte Meldungen.

Der Incident-Management-Prozess kann einheitlich aufgebaut werden. Die kritische Differenz liegt in den Meldewegen und -fristen – dazu mehr im Abschnitt zu den Meldepflichten.

Penetration Testing und Schwachstellenmanagement

DORA fordert in Artikel 26-27 regelmäßige Penetrationstests und für systemrelevante Institute Threat-Led Penetration Testing (TLPT) nach dem TIBER-EU-Framework. NIS2 verlangt allgemein „Richtlinien und Verfahren zur Bewertung der Wirksamkeit“ der Sicherheitsmaßnahmen.

Ein DORA-konformes Testing-Programm mit TLPT übertrifft die NIS2-Anforderungen deutlich. Hier reicht also die DORA-Implementierung vollständig aus.

Business Continuity Management

DORA verlangt umfassende IKT-Business-Continuity-Pläne (Artikel 11). NIS2 fordert „Aufrechterhaltung des Betriebs“ und Krisenmanagement (Artikel 21 Absatz 2c). Auch hier: Ein DORA-konformes BCM-Programm deckt die NIS2-Anforderungen ab – DORA ist spezifischer und strenger.

Die kritischen Unterschiede: Was zweimal gemacht werden muss

Trotz der Synergien gibt es Bereiche, in denen DORA und NIS2 substantiell voneinander abweichen und separate Maßnahmen erfordern:

Meldepflichten: Zwei Systeme, zwei Behörden, unterschiedliche Fristen

Hier liegt der größte operative Mehraufwand für Finanzdienstleister. DORA und NIS2 verlangen Incident Reporting – aber an unterschiedliche Behörden mit unterschiedlichen Fristen und Formaten:

● DORA: Meldung an die zuständige Finanzaufsichtsbehörde (in Deutschland: BaFin). Erstmeldung innerhalb von 24 Stunden nach Klassifizierung als „schwerwiegender IKT-bezogener Vorfall“. Zwischenbericht innerhalb von 72 Stunden. Abschlussbericht innerhalb eines Monats. Format: EBA/ESMA-Meldeformulare.

● NIS2: Meldung an die zuständige nationale Behörde (in Deutschland: BSI). „Unverzügliche“ Frühwarnung innerhalb von 24 Stunden. Detaillierte Meldung innerhalb von 72 Stunden. Abschlussbericht innerhalb eines Monats. Format: BSI-Meldeportal.

Obwohl die Fristen ähnlich klingen, sind die Meldesysteme, Formulare und Ansprechpartner unterschiedlich. Finanzunternehmen müssen beide Meldewege operativ beherrschen. Der Praxis-Tipp: Einen einheitlichen internen Incident-Report erstellen und diesen dann an die jeweiligen Formular-Anforderungen von BaFin und BSI anpassen – statt zwei komplett separate Prozesse aufzubauen.

IT-Drittparteien-Risikomanagement: DORA geht deutlich weiter

Das Management von IKT-Drittdienstleistern ist der Bereich, in dem DORA die striktesten und detailliertesten Anforderungen aller europäischen Regulierungen stellt. DORA fordert:

● Register of Information (RoI): Eine vollständige Dokumentation aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern. Dieses Register muss granulare Details enthalten: Vertragsgegenstand, Datenstandorte, Subunternehmer, Exit-Strategien und Abhängigkeitsanalysen. Die Deadline für das erste vollständige RoI war Q1 2026.

● Kritikalitätsbewertung: Jeder IKT-Dienstleister muss nach seiner Kritikalität für die Geschäftsfunktionen bewertet werden. Für „kritische“ Dienstleister gelten verschärfte Anforderungen an Vertragsgestaltung, Auditrechte und Exit-Szenarien.

● Konzentrationsrisiko-Analyse: Finanzunternehmen müssen analysieren, ob sie bei bestimmten IKT-Diensten zu stark von einzelnen Anbietern abhängig sind – ein Thema, das besonders bei den Hyperscalern (AWS, Azure, GCP) relevant ist.

NIS2 fordert ebenfalls „Sicherheit der Lieferkette“ (Artikel 21 Absatz 2d), aber in deutlich weniger Detailtiefe. Für Finanzunternehmen gilt: Das DORA-TPRM-Framework ist der Standard, der implementiert werden muss. Die NIS2-Anforderungen sind darin enthalten.

Aufsichtsrahmen für kritische IKT-Drittdienstleister

DORA führt in Kapitel V einen völlig neuen Aufsichtsrahmen ein: Kritische IKT-Drittdienstleister (wie große Cloud-Provider) werden künftig direkt durch eine „Lead Supervisory Authority“ der ESAs (EBA, ESMA, EIOPA) beaufsichtigt. Dieses Element hat kein Pendant in NIS2 und betrifft Finanzunternehmen indirekt – sie müssen sicherstellen, dass ihre kritischen IKT-Dienstleister den neuen Aufsichtsanforderungen genügen.

Der integrierte Compliance-Ansatz: Ein Framework für beides

Statt DORA und NIS2 als zwei separate Compliance-Projekte zu behandeln, sollten Finanzunternehmen einen integrierten Ansatz verfolgen. Die Grundidee: Ein einziges Governance-Framework aufbauen, das beide Regulierungen bedient und dabei die DORA-Anforderungen als Basis nimmt (da diese detaillierter sind).

So sieht ein integrierter Ansatz in der Praxis aus:

● Schritt 1 – Mapping: Erstellen Sie eine Kreuzreferenz-Matrix, die jede DORA-Anforderung der entsprechenden NIS2-Anforderung zuordnet. Die ESAs und das BSI bieten Mapping-Dokumente als Ausgangspunkt. Identifizieren Sie die drei Kategorien: „DORA deckt ab“, „NIS2 deckt ab“, „beide erfordern separate Maßnahmen“.

● Schritt 2 – Einheitliches Risikomanagement: Implementieren Sie ein ICT-Risikomanagement-Framework nach DORA-Standard (Artikel 5-16). Ergänzen Sie es um NIS2-spezifische Elemente wie OT-Sicherheit und nicht-IKT-bezogene Lieferkettensicherheit.

● Schritt 3 – Parallele Meldewege: Bauen Sie einen einheitlichen internen Incident-Management-Prozess auf. Implementieren Sie am Ende der Meldekette zwei parallele Ausgänge: einen zum BaFin-Meldesystem (DORA) und einen zum BSI-Meldeportal (NIS2). Der interne Prozess ist identisch, nur die letzten Meter unterscheiden sich.

● Schritt 4 – Integriertes TPRM: Nutzen Sie das DORA Register of Information als zentrale Datenbasis für das gesamte Drittparteien-Risikomanagement. Erweitern Sie es um nicht-IKT-Lieferanten, die unter NIS2 relevant sind.

● Schritt 5 – Governance: Etablieren Sie eine einzige Governance-Struktur (z.B. ein „Digital Resilience Committee“), das sowohl DORA- als auch NIS2-Compliance verantwortet. Keine parallelen Compliance-Teams für unterschiedliche Regulierungen.

Register of Information: Die praktische Herausforderung

Das DORA Register of Information (RoI) verdient besondere Aufmerksamkeit, weil es für viele Institute die aufwändigste Einzelanforderung ist. Das RoI muss alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern dokumentieren – einschließlich Details, die in vielen Unternehmen bisher nirgends zentral erfasst wurden:

● Vertragsdetails: Gegenstand, Laufzeit, Kündigungsfristen, SLAs, Haftungsregelungen

● Datenstandorte: Wo werden Daten verarbeitet und gespeichert? Welche Jurisdiktionen sind betroffen?

● Subunternehmer-Ketten: Welche Sub-Dienstleister setzt der IKT-Anbieter ein? Wo sitzen diese?

● Abhängigkeitsanalyse: Welche Geschäftsfunktionen hängen von diesem Dienstleister ab? Was passiert bei Ausfall?

● Exit-Strategie: Wie kann der Dienstleister gewechselt werden? Welche Daten müssen migriert werden?

Institute, die das RoI noch nicht fertiggestellt haben, sollten pragmatisch priorisieren: Mit den kritischsten Dienstleistern (Cloud-Provider, Kernbanksysteme, Payment-Infrastruktur) beginnen und dann schrittweise erweitern. Die BaFin hat signalisiert, dass sie bei der Erstprüfung den Fortschritt und die Methodik bewerten wird – nicht nur das Ergebnis.

Geschäftsleitung in der Pflicht: Haftung unter DORA und NIS2

Sowohl DORA als auch NIS2 betonen die Verantwortung der Geschäftsleitung für Cybersicherheit. DORA macht das Leitungsorgan explizit verantwortlich für die Genehmigung und Überwachung des ICT-Risikomanagement-Frameworks (Artikel 5 Absatz 2). NIS2 sieht vor, dass Leitungsorgane die Risikomanagement-Maßnahmen billigen, deren Umsetzung überwachen und an Cybersicherheitsschulungen teilnehmen müssen (Artikel 20).

In der deutschen Umsetzung können Geschäftsführer und Vorstände persönlich haftbar gemacht werden, wenn sie ihren Überwachungspflichten nicht nachkommen. Die Bußgelder sind erheblich: bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes nach NIS2, vergleichbare Größenordnungen unter DORA.

Die praktische Konsequenz: Cybersicherheit ist kein IT-Thema mehr, das an den CISO delegiert werden kann. Vorstände und Geschäftsführer müssen nachweisbar involviert sein – in Entscheidungen, Freigaben und regelmäßigen Reviews.

„GAP-Assessment gegen beide Frameworks: Nicht DORA und NIS2 einzeln prüfen, sondern eine integrierte GAP-Analyse durchführen.“

Praxis-Checkliste: DORA + NIS2 Doppeldruck managen

Für Finanzunternehmen, die den Compliance-Doppeldruck effizient bewältigen wollen, hier die konkreten nächsten Schritte:

● GAP-Assessment gegen beide Frameworks: Nicht DORA und NIS2 einzeln prüfen, sondern eine integrierte GAP-Analyse durchführen. Ergebnis: Ein konsolidierter Maßnahmenplan statt zwei.

● Register of Information fertigstellen: Wenn noch nicht geschehen, jetzt mit den Top-20-IKT-Dienstleistern starten. Nicht auf Perfektion warten – ein 80%-RoI, das existiert, ist besser als ein 100%-RoI, das in sechs Monaten fertig wird.

● Meldeprozesse doppelt aufsetzen: Einen einheitlichen internen Incident-Prozess mit zwei Ausgängen (BaFin + BSI) implementieren. Testmeldungen durchführen, bevor der Ernstfall eintritt.

● TLPT-Programm planen: Für systemrelevante Institute ist Threat-Led Penetration Testing unter DORA Pflicht. Der Aufwand ist erheblich (6-12 Monate pro TLPT-Zyklus) – frühzeitig mit einem qualifizierten TLPT-Provider starten.

● Schulung der Geschäftsleitung: Vorstand und Geschäftsführung müssen unter beiden Frameworks nachweisbar geschult sein. Ein gemeinsames Schulungsprogramm aufsetzen, das DORA und NIS2 integriert behandelt.

● Konzentrationsrisiko bewerten: Analyse der Abhängigkeit von einzelnen Cloud-Providern und IKT-Dienstleistern durchführen. Multi-Cloud- und Exit-Strategien dokumentieren.

● Verträge überarbeiten: Alle IKT-Verträge gegen die DORA-Anforderungen prüfen (Auditrechte, Subunternehmer-Klauseln, Exit-Regelungen). Nachverhandlungen frühzeitig initiieren.

Ausblick: Die Regulierungsdichte nimmt weiter zu

DORA und NIS2 sind nicht die letzten Regulierungen, die Finanzunternehmen in der Cybersicherheit treffen. Mit dem EU AI Act, dem Cyber Resilience Act und dem Data Act kommen weitere Regelwerke hinzu, die Überschneidungen aufweisen und integriert betrachtet werden müssen.

Finanzinstitute, die jetzt ein flexibles, integriertes Compliance-Framework aufbauen, werden diese zusätzlichen Regulierungen leichter absorbieren als Unternehmen, die jedes neue Gesetz als isoliertes Projekt behandeln. Der integrierte Ansatz zahlt sich nicht nur kurzfristig aus – er ist die einzige skalierbare Strategie für die steigende Regulierungsdichte in Europa.

Die Aufsichtsbehörden – BaFin und BSI – sind sich der Doppelbelastung bewusst und arbeiten an koordinierten Prüfungsansätzen. Trotzdem liegt die Verantwortung für die effiziente Umsetzung bei den Unternehmen selbst. Wer jetzt die Synergien hebt, spart nicht nur Compliance-Kosten, sondern baut eine digitale Resilienz auf, die wirklich schützt. Einen Überblick über die NIS2-Anforderungen im Detail finden Sie in unserem Artikel NIS2 in Deutschland: Was Unternehmen jetzt wissen und umsetzen müssen.

Häufige Fragen

Müssen Finanzunternehmen sowohl DORA als auch NIS2 erfüllen?

Ja. DORA gilt als lex specialis und hat bei Überschneidungen Vorrang, aber NIS2 greift zusätzlich in Bereichen, die DORA nicht abdeckt. Finanzunternehmen müssen beide Regelwerke kennen und die jeweiligen Anforderungen erfüllen. Ein integrierter Compliance-Ansatz vermeidet dabei Doppelarbeit.

An wen müssen Sicherheitsvorfälle gemeldet werden?

Unter DORA an die zuständige Finanzaufsichtsbehörde (BaFin) innerhalb von 24 Stunden. Unter NIS2 an das BSI, ebenfalls „unverzüglich“ (in der Praxis innerhalb von 24 Stunden). Beide Meldungen müssen parallel erfolgen – es handelt sich um unterschiedliche Meldesysteme und Formulare.

Was ist das Register of Information und bis wann muss es fertig sein?

Das Register of Information ist eine vollständige Dokumentation aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern nach DORA. Es muss Details zu Vertragsgegenstand, Datenstandorten, Subunternehmern, Abhängigkeiten und Exit-Strategien enthalten. Die Deadline für das erste vollständige Register war Q1 2026. Institute, die es noch nicht fertiggestellt haben, sollten sofort mit den kritischsten Dienstleistern beginnen.

Haftet die Geschäftsleitung persönlich?

Ja, unter beiden Regelwerken. DORA macht das Leitungsorgan verantwortlich für die Genehmigung und Überwachung des ICT-Risikomanagement-Frameworks. NIS2 sieht persönliche Haftung vor, wenn Leitungsorgane ihren Überwachungspflichten nicht nachkommen. Geschäftsführer und Vorstände müssen nachweisbar in Cybersicherheitsentscheidungen involviert sein.

Wie lassen sich die Compliance-Kosten für DORA und NIS2 reduzieren?

Durch einen integrierten Compliance-Ansatz: Ein einziges Governance-Framework aufbauen, das beide Regulierungen bedient. DORA-Anforderungen als Basis nehmen (da detaillierter), NIS2-Lücken gezielt ergänzen. Eine einheitliche GAP-Analyse statt zwei separate durchführen. Synergien im Risikomanagement, BCM und Testing konsequent nutzen. Parallele Compliance-Teams vermeiden.

Weiterführende Lektüre

• NIS2 in Deutschland: Was Unternehmen jetzt wissen und umsetzen müssen
• DORA: BaFin prüft Finanzinstitute – MyBusinessFuture
• Cyber-Versicherung 2026: Was Unternehmen wissen müssen

Mehr aus dem MBF Media Netzwerk

• FinOps: Wie Unternehmen Cloud-Kosten in den Griff bekommen – cloudmagazin
• Cybersecurity-Trends 2026: Sieben Entwicklungen – SecurityToday
• Supply Chain Security 2026 – SecurityToday

Quelle Titelbild: Pexels / Sora Shimazaki

Hier schreibt Tobias Massow für Sie

Mehr Artikel vom Autor Tobias Massow