NIS2 und DORA Vergleich für deutsche Finanzunternehmen — Lex Specialis Prinzip

NIS2 und DORA für Finanzunternehmen: Überschneidungen nutzen, Doppelarbeit vermeiden

Deutsche Finanzunternehmen stehen seit 2025 vor einer ungewöhnlichen regulatorischen Lage: Zwei bedeutende EU-Regelwerke für Cybersicherheit gelten gleichzeitig. DORA (Regulation (EU) 2022/2554) ist seit dem 17. Januar 2025 direkt anwendbar. Das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) trat am 6. Dezember 2025 in Kraft. Viele Compliance-Teams stellen sich seitdem dieselbe Frage: Müssen wir beide Regelwerke vollständig einhalten — oder ersetzt DORA die NIS2-Richtlinie?

Die Antwort kennt eine wichtige Nuance. Das Lex-Specialis-Prinzip gibt DORA Vorrang — aber nur in drei klar definierten Bereichen. Für alle anderen Anforderungen gilt NIS2 ergänzend weiter. Wer das nicht weiß, riskiert entweder Doppelarbeit oder — schlimmer — unbeabsichtigte Compliance-Lücken.

Dieser Leitfaden erklärt die rechtliche Beziehung zwischen DORA und NIS2, zeigt welche Anforderungen sich überschneiden und was zusätzlich erforderlich ist — und gibt deutschen Finanzunternehmen eine praktische Strategie, um beide Regelwerke effizient zu erfüllen.

Dieser Artikel enthält allgemeine Informationen und stellt keine Rechts- oder Compliance-Beratung dar. NIS2-Anforderungen variieren je nach Mitgliedstaat, Sektor und Unternehmensgröße — konsultieren Sie für Ihre spezifische Situation einen qualifizierten Rechtsanwalt oder Compliance-Spezialisten.

Auf einen Blick: NIS2 und DORA im direkten Vergleich

Bevor wir das Verhältnis beider Regelwerke klären, hier die wichtigsten Unterschiede im Überblick:

Merkmal NIS2 DORA
Rechtsform EU-Richtlinie (nationale Umsetzung erforderlich) EU-Verordnung (unmittelbar anwendbar)
Gilt in Deutschland seit 6. Dezember 2025 (NIS2UmsuCG) 17. Januar 2025
Anwendungsbereich 18 kritische Sektoren, ~30.000 Unternehmen in Deutschland Ausschließlich Finanzsektor (Banken, Zahlungsinstitute, Versicherungen, Investmentfirmen u.a.)
Zuständige Behörde (DE) BSI (Bundesamt für Sicherheit in der Informationstechnik) BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht)
Maximale Sanktionen Bis zu €10 Mio. oder 2% des weltweiten Jahresumsatzes (wesentliche Einrichtungen) National geregelt; kritische IKT-Drittanbieter: bis zu 1% täglicher Umsatz
Schwerpunkt Allgemeine Cybersicherheitsresilienz, sektorübergreifend Digitale operationelle Resilienz, IKT-Risiken im Finanzsektor

Der entscheidende strukturelle Unterschied: NIS2 ist eine Richtlinie, die nationaler Umsetzung bedurfte. DORA ist eine Verordnung und galt in Deutschland ohne zusätzliche Gesetzgebung — zwei Jahre früher als das NIS2-Umsetzungsgesetz. Für Finanzunternehmen bedeutete das, ab Januar 2025 bereits DORA-konform sein zu müssen, während NIS2 erst Ende 2025 verbindlich wurde.

Das Lex-Specialis-Prinzip: Warum DORA in drei Bereichen vorgeht

Die rechtliche Grundlage des Vorrangverhältnisses findet sich in zwei EU-Normen, die zusammengelesen werden müssen.

Artikel 1(2) DORA bestimmt, dass DORA für die in Artikel 2 genannten Finanzunternehmen als sektorspezifischer Rechtsakt der Union im Sinne von Artikel 4(1) der NIS2-Richtlinie gilt. DORA erklärt sich damit ausdrücklich zum Lex-Specialis.

Artikel 4(1) NIS2 legt fest: Wo sektorspezifische Rechtsakte der Union Cybersicherheitsanforderungen vorschreiben, die in ihrer Wirkung mindestens den NIS2-Verpflichtungen entsprechen, gelten die einschlägigen NIS2-Bestimmungen für diese Unternehmen nicht.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bestätigt in seiner offiziellen Leitlinie zu DORA und NIS-2: Die DORA-Regelungen gehen den Bestimmungen des NIS2UmsuCG in den betroffenen Bereichen vor, sofern sie mindestens gleichwertig sind.

Das Lex-Specialis-Vorrecht gilt jedoch nur für genau drei IKT-Bereiche:

  1. IKT-Risikomanagement (Artikel 5–15 DORA): Governance, Risikotoleranz, Schutzmaßnahmen, Erkennung, Reaktion und Wiederherstellung
  2. IKT-Vorfallmeldung (Artikel 17–23 DORA): Klassifizierung schwerwiegender IKT-Vorfälle und Meldung an die zuständige Behörde
  3. IKT-Drittanbietersteuerung (Artikel 28–44 DORA): Vertragsanforderungen, Register of Information, Aufsicht über kritische IKT-Drittanbieter durch die europäischen Aufsichtsbehörden (ESA)

In diesen drei Bereichen müssen DORA-pflichtige Finanzunternehmen nicht parallel NIS2 einhalten. DORA setzt den Standard — und dieser ist durchgehend strenger und detaillierter als NIS2.

Außerhalb dieser drei Bereiche gilt: DORA schützt nicht. NIS2 bleibt vollständig wirksam.

Für eine Einführung in die Grundlagen der NIS2-Richtlinie lesen Sie unseren Artikel: Was ist die NIS2-Richtlinie?

Was von NIS2 trotz DORA-Compliance weiterhin gilt

Das ist der Bereich, der in der Praxis am häufigsten übersehen wird: Selbst ein vollständig DORA-konformes Finanzunternehmen hat konkrete Verpflichtungen aus dem NIS2UmsuCG. Verstöße dagegen sind eigenständige Compliance-Fehler mit eigenständigen Sanktionsrisiken.

Registrierungspflicht beim BSI

§33 NIS2UmsuCG verlangt, dass wesentliche und wichtige Einrichtungen sich beim BSI registrieren. Die Frist für bestehende Einrichtungen endete am 6. März 2026. DORA enthält kein Äquivalent zu dieser Registrierungspflicht — die BaFin-Aufsicht unter DORA ersetzt die BSI-Registrierung nicht.

Einstufung als „Wichtige Einrichtung” und ihre Folgen

Finanzunternehmen werden als wichtige Einrichtung nach NIS2UmsuCG eingestuft, wenn sie alle drei Schwellenwerte gleichzeitig erfüllen:

  • Mindestens 50 Beschäftigte
  • Jahresumsatz und Bilanzsumme jeweils über 10 Millionen Euro
  • Tätigkeit in einem der in Anlage 1–2 NIS2UmsuCG genannten Sektoren (der Finanzsektor ist dort explizit aufgeführt)

Als wichtige Einrichtung gelten erweiterte Pflichten: regelmäßige Sicherheitsaudits, verschärfte Nachweispflichten gegenüber dem BSI und — besonders relevant — die persönliche Managementhaftung nach §38 NIS2UmsuCG. Geschäftsführer und Vorstandsmitglieder können persönlich für Verstöße gegen die Risikomanagementpflichten haftbar gemacht werden, wenn sie die vorgeschriebenen Maßnahmen nicht billigen oder kontinuierlich überwachen.

Bereiche außerhalb des IKT-Anwendungsbereichs von DORA

DORA beschränkt sich auf IKT-Risiken im engeren Sinne. Folgende Bereiche bleiben vollständig unter NIS2-Aufsicht:

NIS2-Bereich Gilt trotz DORA? Warum
BSI-Registrierung (§33 NIS2UmsuCG) Ja Kein DORA-Äquivalent vorhanden
BSI-Kooperation und Auskunftspflichten Ja Kein DORA-Äquivalent für BSI-Zusammenarbeit
Physische Sicherheit (Rechenzentren, Zutritt) Ja DORA regelt ausschließlich IKT, nicht physische Infrastruktur
OT-Systeme und Gebäudeautomation Ja OT fällt nicht unter DORAsche IKT-Definition
Nicht-IKT-Lieferkette (physische Lieferanten) Ja DORA: nur IKT-Drittanbieter; NIS2: gesamte Lieferkette
Managementhaftung (§38 NIS2UmsuCG) Ja, ergänzend DORA-Governance und NIS2-Haftung sind parallel anwendbar
IKT-Risikomanagement (Art. 5–15 DORA) Nein DORA ersetzt NIS2 (Lex Specialis)
IKT-Vorfallmeldung (Art. 17–23 DORA) Nein DORA ersetzt NIS2 (Lex Specialis)
IKT-Drittanbietersteuerung (Art. 28 DORA) Nein DORA ersetzt NIS2 (Lex Specialis)

Für einen vollständigen Überblick der NIS2-Anforderungen und ihrer technischen Umsetzung empfehlen wir unseren Leitfaden: NIS2-Anforderungen für Unternehmen.

Die Gemeinsamkeiten: Was beide Regelwerke gemeinsam verlangen

In der Praxis überlappen sich rund 60–70 Prozent der operativen Anforderungen beider Regelwerke. Das ist ein erhebliches Effizienzpotenzial — vorausgesetzt, Finanzunternehmen bauen von Anfang an ein konsolidiertes Compliance-Programm statt zwei parallele Projekte.

Anforderungsbereich NIS2 DORA Synergiegrad
IKT-Risikomanagement Risikobasierter Ansatz (§30 NIS2UmsuCG) Umfassendes Framework (Art. 5–15) Hoch — DORA erfüllt NIS2 automatisch
Management-Verantwortung Billigung und Überwachung durch Leitung (§38) Leitungsorganverantwortung (Art. 5 DORA) Hoch — eine Governance-Struktur reicht
Vorfallmanagement intern Interne Prozesse und BSI-Meldung Interne Klassifizierung und BaFin-Meldung Mittel — Prozesse konsolidierbar, Kanäle separat
Business Continuity BCPs, regelmäßige Tests (§30 Nr. 7) Dokumentierte BCPs mit RTO/RPO-Zielen (Art. 11–12) Hoch — ein BCP-Programm erfüllt beide
Drittanbieter-Risiko Lieferkettensicherheit (§30 Nr. 5) Register of Information, Vertragsanforderungen (Art. 28) Mittel — DORA deutlich umfangreicher
Schulungen und Awareness Managementschulung verpflichtend (§38) Mitarbeiter-Schulungsprogramme (Art. 13) Hoch — ein konsolidiertes Schulungsprogramm

Die wichtigste Erkenntnis: Wer DORA vollständig erfüllt, hat die IKT-bezogenen NIS2-Anforderungen automatisch miterfüllt — da DORA strenger ist. Das Compliance-Risiko liegt nicht im IKT-Bereich, sondern in den NIS2-Anforderungen außerhalb von DORA: Registrierung, physische Sicherheit, OT und Lieferkette.

Die Unterschiede im Detail: Wo parallele Compliance unausweichlich ist

Trotz erheblicher inhaltlicher Überlappung gibt es Bereiche, in denen DORA und NIS2 substantiell divergieren und keine Konsolidierung möglich ist.

Meldepflichten: Vier Stunden gegen vierundzwanzig Stunden

Dies ist der operativ anspruchsvollste Unterschied. Bei einem schwerwiegenden Sicherheitsvorfall müssen deutsche Finanzunternehmen zwei separate Meldungen einreichen — an zwei verschiedene Behörden, mit unterschiedlichen Fristen und unterschiedlichen Formularen:

Meldephase DORA → BaFin NIS2 → BSI
Erstmeldung Innerhalb 4 Stunden nach Klassifizierung als schwerwiegend (nach Art. 18-Kriterien) Innerhalb 24 Stunden (Frühwarnung)
Zwischenmeldung Innerhalb 72 Stunden Innerhalb 72 Stunden
Abschlussbericht Innerhalb 1 Monat nach Vorfallende Innerhalb 1 Monat nach Vorfallende
Formular und Kanal EBA/ESMA-Standardformulare, BaFin-Portal BSI-Meldeplattform, eigenes Format

Eine einzige Meldung kann beide Pflichten nicht erfüllen. Die Kanäle, Formulare und Klassifizierungsrahmen sind different. Ein Incident-Management-Prozess muss von Beginn an so konstruiert sein, dass er beide Ausgabekanäle parallel bedient — mit klaren Verantwortlichkeiten für beide Fristen.

DORA-spezifisch: Das Register of Information

Artikel 28 DORA verlangt ein vollständiges Vertragsregister aller IKT-Drittanbieter. Für jeden Vertrag sind granulare Informationen erforderlich: Datenverarbeitungsstandorte und Rechenzentrumsadressen, vollständige Subunternehmerketten, Exit-Strategien mit Übergangsfristen, Business-Continuity-Vorkehrungen und Abhängigkeitsanalysen. Die erste vollständige Übermittlung dieses Registers an die Aufsichtsbehörden war im ersten Quartal 2026 fällig. NIS2 enthält keine vergleichbar granulare Dokumentationsanforderung — das Register ist ein reiner DORA-Zusatzaufwand.

DORA-spezifisch: Threat-Led Penetration Testing

Erweiterte DORA-Entitäten — in der Regel systemrelevante Finanzinstitute — müssen regelmäßig Threat-Led Penetration Tests (TLPT) nach dem standardisierten TIBER-EU-Framework oder einem als äquivalent anerkannten Rahmen durchführen. Diese Form des risikobasierten Adversarial-Testings hat kein direktes Pendant in der NIS2-Richtlinie. Für betroffene Institute bedeutet das einen zusätzlichen, eigenständigen Testaufwand.

DORA-spezifisch: EU-Direktaufsicht über kritische IKT-Drittanbieter

Unter DORA können EBA, ESMA und EIOPA kritische IKT-Drittanbieter — etwa große Cloud-Anbieter oder zentrale Softwareplattformen — direkt beaufsichtigen, unabhängig von ihrem Mitgliedstaat. Diese Form der paneuropäischen Direktaufsicht durch den Lead Overseer existiert unter NIS2 nicht. Finanzunternehmen müssen bei Vertragsgestaltungen mit potenziell kritischen Drittanbietern diese Aufsichtsmöglichkeit vertraglich absichern (Zugangsrechte, Kooperationspflichten).

Sanktionsstruktur: EU-weit einheitlich vs. national geregelt

NIS2 definiert EU-weit einheitliche Maximalstrafen: bis zu 10 Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes für wesentliche Einrichtungen; bis zu sieben Millionen Euro oder 1,4 Prozent für wichtige Einrichtungen. DORA überlässt Sanktionen gegenüber Finanzinstituten den nationalen Behörden ohne EU-weit fixierte Maximalwerte. Lediglich für kritische IKT-Drittanbieter, die der EU-Direktaufsicht unterliegen, sieht DORA Strafen von bis zu einem Prozent des durchschnittlichen täglichen globalen Umsatzes vor.

Meldepflichten in der Praxis: Ein Prozess, zwei Kanäle

Der häufigste operative Fehler: Finanzunternehmen bauen getrennte Incident-Response-Prozesse für DORA und NIS2. Das führt zu Doppelarbeit, erhöhtem Fehlerrisiko und der realen Gefahr, Fristen zu versäumen, weil Zuständigkeiten unklar sind.

Der effizientere Ansatz ist ein einheitlicher interner Incident-Management-Prozess mit zwei definierten Ausgabekanälen. Der Prozess läuft intern identisch ab; erst bei der Ausgabe teilen sich die Wege:

Prozessschritt DORA-Kanal (BaFin) NIS2-Kanal (BSI)
Erkennung und erste Bewertung Einheitlicher interner Prozess (CISO-Team)
Dual-Klassifizierung Prüfung gegen Art. 18-Kriterien DORA (schwerwiegend?) Prüfung gegen NIS2UmsuCG-Kriterien (erheblich?)
Erstmeldung 4-Stunden-Frist → BaFin (EBA-Formular) 24-Stunden-Frist → BSI-Meldeplattform
Eskalation intern CISO + Compliance Officer + Vorstand
Zwischenmeldung 72 Stunden → BaFin 72 Stunden → BSI
Abschlussbericht 1 Monat → BaFin 1 Monat → BSI

Der entscheidende Unterschied zwischen beiden Klassifizierungen liegt in den Auslösekriterien. DORA Artikel 18 definiert „schwerwiegend” anhand von Parametern wie Anzahl betroffener Kunden, betroffenes Transaktionsvolumen und Ausfalldauer kritischer Dienste. Das NIS2UmsuCG nutzt andere Erheblichkeitskriterien. Ein Vorfall kann beide Schwellen gleichzeitig überschreiten — oder nur eine. Das interne Klassifizierungsprotokoll muss beide Rahmen parallel prüfen.

Zur Vorbereitung auf die NIS2-spezifischen Meldepflichten nach NIS2 empfehlen wir unseren detaillierten Leitfaden.

Konsolidierte Compliance-Strategie für Finanzunternehmen

Angesichts einer Überlappungsrate von 60–70 Prozent ist ein integriertes Programm kein Komfortgedanke, sondern die kosteneffizienteste Antwort auf den regulatorischen Doppeldruck. Zwei getrennte Projekte bedeuten doppelte Gap-Analysen, doppelte Audit-Vorbereitungen und doppelte Governance-Strukturen — ohne regulatorischen Mehrwert.

Vier-Schritte-Ansatz

Schritt 1: Integrierte Gap-Analyse
Bewerten Sie Ihren aktuellen Compliance-Stand gleichzeitig gegen beide Regelwerke. DORA-Lücken haben generell Priorität — strengere Anforderungen, kürzere Fristen. Identifizieren Sie explizit die NIS2-Bereiche außerhalb von DORA: BSI-Registrierung, physische Sicherheit, OT-Systeme, Nicht-IKT-Lieferkette. Diese sind die typischen blinden Flecken in DORA-fokussierten Compliance-Programmen.

Schritt 2: Einheitlicher Incident-Prozess mit doppeltem Ausgang
Bauen Sie einen einzigen internen Incident-Management-Prozess, der am Ende zwei Ausgabekanäle bedient: BaFin (EBA/ESMA-Formular) und BSI (NIS2-Meldeplattform). Beide Fristentrigger — vier Stunden DORA, vierundzwanzig Stunden NIS2 — müssen als automatische Eskalationsschritte im Prozess verankert sein.

Schritt 3: DORA Register als TPRM-Fundament
Das DORA-Vertragsregister nach Artikel 28 ist detaillierter als alle NIS2-Drittanbieteranforderungen. Nutzen Sie es als Grundlage des gesamten Third-Party Risk Managements. Erweitern Sie es um Nicht-IKT-Lieferanten, um die NIS2-Lieferkettenpflichten abzudecken. Ein einziges Register ersetzt zwei separate Dokumentationspflichten.

Schritt 4: Gemeinsames Digital-Resilience-Komitee
Etablieren Sie ein gemeinsames Gremium aus CISO, Compliance Officer, Legal und Vorstandsrepräsentant, das beide Regelwerke gemeinsam überwacht. Getrennte Teams mit getrennten Budgets und getrennten Reporting-Linien verdoppeln Aufwand und Koordinationsrisiko ohne jeden regulatorischen Vorteil.

Rollenverantwortung im Überblick

Funktion Verantwortung DORA Verantwortung NIS2 (verbleibend)
Vorstand / Leitungsorgan Genehmigung IKT-Strategie und Risikotoleranz (Art. 5 DORA) Billigung Risikomanagementmaßnahmen, laufende Überwachung (§38 NIS2UmsuCG)
CISO IKT-Risikomanagement-Framework, TLPT-Programm, Incident-Klassifizierung DORA Technische Sicherheitsmaßnahmen, OT-Sicherheit, Incident-Klassifizierung NIS2
Compliance Officer Register of Information, Drittanbieter-Compliance, BaFin-Meldungen (EBA-Formular) BSI-Registrierung, NIS2-Meldepflichten, Einstufungsprüfung wichtige Einrichtung
Legal Vertragsanforderungen Art. 28 DORA, ESA-Aufsichtskooperation Haftungsfragen §38 NIS2UmsuCG, Prüfung nationale Transpositionsvariationen
IT-Abteilung TLPT-Durchführung, BC/DR-Systeme, RTO/RPO-Definition und -Tests Physische Sicherheitsmaßnahmen, OT-Systeme, BSI-Meldeplattform-Anbindung

Fazit: DORA als Basis — NIS2 schließt die Lücken

Für deutsche Finanzunternehmen lautet die richtige Formel nicht „DORA oder NIS2”, sondern „DORA als strengerer Standard, NIS2 für alles was DORA nicht abdeckt”. Das Lex-Specialis-Prinzip aus Artikel 1(2) DORA in Verbindung mit Artikel 4(1) NIS2 — bestätigt durch die offizielle BSI-Leitlinie — befreit von Doppelpflichten in exakt drei IKT-Bereichen. Registrierung beim BSI, physische Sicherheit, OT-Systeme und die allgemeine Lieferkettensicherheit bleiben unabhängig davon unter NIS2 geregelt.

Der strategisch klügste Ansatz ist ein konsolidiertes Programm: DORA setzt die strengere Baseline für IKT-Risiken; NIS2-spezifische Anforderungen füllen die Lücken. Der unmittelbare Handlungsbedarf für Unternehmen, die die Schwellenwerte einer wichtigen Einrichtung erfüllen und noch nicht beim BSI registriert sind: Die Registrierungsfrist ist abgelaufen — die Nachregistrierung sollte unverzüglich erfolgen.

Dieser Artikel stellt allgemeine Informationen bereit und ersetzt keine individuelle Rechts- oder Compliance-Beratung. Anforderungen können je nach Unternehmenstyp, Sektor und nationalem Recht variieren. Konsultieren Sie einen qualifizierten Rechtsanwalt oder Compliance-Spezialisten für Ihre spezifische Situation.

Quellen

  • Regulation (EU) 2022/2554 — Digital Operational Resilience Act: eur-lex.europa.eu
  • BSI — NIS-2 und DORA: Verhältnis und Anwendungsbereich: bsi.bund.de
  • PayTechLaw — NIS2 meets DORA: Was sich für Finanzinstitute ändert: paytechlaw.com

Ähnliche Beiträge