Einführungspreis endet in
--T--Std--Minoder erste 20 Plätze
Jetzt sichern →
← Zur Wissens-Übersicht
NIS2 vs DORANIS2 DORA VergleichDORA NIS2 FinanzsektorNIS2 DORA lex specialis

NIS2 vs. DORA — Welche Regulierung gilt für Ihr Unternehmen?

DORA geht als lex specialis im Finanzsektor vor NIS2. Unsere Vergleichstabelle zeigt, welche Regulierung wann gilt und wo beide greifen.

Veröffentlicht: 21. März 2026Letzte Aktualisierung: 21. März 202611 Min. Lesezeit

NIS2 vs. DORA — Welche Regulierung gilt für Ihr Unternehmen?

Letzte Aktualisierung: 21. März 2026

NIS2 und DORA regulieren beide Cybersicherheit, doch bei NIS2 vs DORA gilt für Finanzunternehmen grundsätzlich DORA als lex specialis: DORA ist seit dem 17. Januar 2025 unmittelbar anwendbar, NIS2 adressiert 18 Sektoren horizontal, und NIS2 greift im Finanzsektor nur dort eigenständig, wo DORA denselben Sachverhalt nicht bereits spezieller regelt oder wo Unternehmen außerhalb des DORA-Scope liegen.

Die praktische Frage lautet deshalb nicht nur „Was ist strenger?“, sondern zuerst „Welche Rolle hat Ihr Unternehmen?“. Banken, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen, E-Geld-Institute und weitere Finanzunternehmen müssen primär DORA lesen. Betreiber aus Energie, Gesundheit, Verkehr, digitale Infrastruktur oder Industrie prüfen dagegen zuerst NIS2. Mischkonstellationen entstehen vor allem bei Finanzgruppen, IT-Dienstleistern für den Finanzsektor und Unternehmen, die sowohl in regulierten Sektoren tätig sind als auch kritische digitale Dienstleistungen bereitstellen.

Wenn Sie die NIS2-Pflichten zunächst auf Organisationsebene einordnen möchten, lesen Sie ergänzend unsere NIS2-Checkliste, den Beitrag zur NIS2-Meldepflicht binnen 24 Stunden und den Vergleich NIS2 vs. ISO 27001. Für die Verantwortlichkeit der Leitungsebene ist außerdem der Leitfaden zur Haftung des Geschäftsführers unter NIS2 relevant.

NIS2 vs. DORA — welche Regulierung hat Vorrang?

Die kurze juristische Antwort lautet: DORA hat Vorrang, wenn ein Finanzunternehmen in einem Bereich betroffen ist, den DORA bereits als sektorspezifischer Rechtsakt regelt. Genau dieses Verhältnis beschreibt das Lex-specialis-Prinzip. NIS2 ist der allgemeinere europäische Cybersicherheitsrahmen für wesentliche und wichtige Einrichtungen in 18 Sektoren. DORA ist dagegen eine unmittelbar geltende Verordnung nur für den Finanzsektor und geht dort tiefer in die operative Resilienz hinein.

Das ist keine bloße Theorie, sondern eine konkrete Prioritätenregel für Compliance-Programme. Wenn ein Kreditinstitut seine Incident-Prozesse, sein ICT-Risikomanagement, die Steuerung ausgelagerter IT-Dienstleistungen oder Resilienztests aufsetzt, ist DORA der führende Maßstab. NIS2 bleibt als Hintergrundrahmen relevant, aber nicht als primäre Detailnorm für dieselben Themenfelder.

Für die Praxis ist dabei wichtig, zwischen drei Ebenen zu unterscheiden:

  1. DORA verdrängt NIS2 nicht pauschal in jedem denkbaren Punkt, sondern dort, wo DORA denselben Gegenstand spezieller regelt.
  2. NIS2 bleibt für Unternehmen außerhalb des Finanzsektors der maßgebliche Ausgangspunkt.
  3. Konzernstrukturen, ausgelagerte IT-Modelle und Mischgruppen können dazu führen, dass unterschiedliche Gesellschaften innerhalb derselben Unternehmensgruppe verschiedenen Primärregimen unterliegen.

Wer also nur fragt „Gilt DORA oder NIS2?“, stellt die Frage zu grob. Richtig ist: Für welches Unternehmen, für welche Funktion, für welchen Vorfall und für welchen Drittanbieter gilt welcher Standard als führend?

Vergleichstabelle NIS2 und DORA: Der direkte NIS2-DORA-Vergleich

Die folgende Tabelle verdichtet die Unterschiede zwischen horizontaler NIS2-Regulierung und sektorspezifischer DORA-Regulierung. Sie ist die schnellste Entscheidungshilfe für Management, Compliance und Informationssicherheit.

DimensionNIS2DORA
RechtsformRichtlinie, also nationale Umsetzung erforderlichVerordnung, also unmittelbar in allen Mitgliedstaaten geltend
Zielgruppe18 Sektoren, insbesondere wesentliche und wichtige EinrichtungenFinanzsektor, etwa Banken, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen und weitere Finanzunternehmen
Inkrafttreten / AnwendungUmsetzungsfrist bis 17. Oktober 2024; praktische Wirkung hängt national von der Umsetzung abSeit 17. Januar 2025 anwendbar
KernfokusAllgemeine Cybersicherheit und Resilienz von EinrichtungenDigitale operationale Resilienz des Finanzsektors
MeldepflichtenFrühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 1 Monat an zuständige Behörde oder CSIRT; in Deutschland perspektivisch über BSI-StrukturenDORA-spezifische Stufenmeldungen bei schwerwiegenden IKT-Vorfällen an die zuständige Finanzaufsicht; in Deutschland zentral über BaFin
IKT-DrittanbieterLieferketten- und Abhängigkeitsmanagement als Teil des CyberrisikomanagementsAusdifferenziertes Drittparteiregime mit Vertragsvorgaben, Informationsregister und Aufsicht über kritische IKT-Drittdienstleister
Lex specialisAllgemeiner RahmenGeht im Finanzsektor als speziellere Regel vor
AufsichtNationale Behörden und CSIRTsNationale Finanzaufsicht und europäische Aufsichtsarchitektur
ResilienztestsAllgemeine Erwartung an angemessene Sicherheitsmaßnahmen und KrisenfestigkeitKonkreter geregelte Tests digitaler operationaler Resilienz
Drittstaaten- und KonzernwirkungRelevant über Betreiberstatus und LieferketteStark relevant über Auslagerung, ICT-Dienstleister und gruppenweite Register

Der wichtigste Punkt der Tabelle ist nicht nur „Verordnung versus Richtlinie“. Entscheidend ist, dass DORA dieselben Themenfelder im Finanzsektor wesentlich detaillierter operationalisiert. Das betrifft insbesondere Governance, Meldeprozesse, Registerpflichten, Tests und die Steuerung externer ICT-Leistungen.

Wann gilt NIS2, wann DORA — und wann beides im Finanzsektor?

NIS2 gilt immer dann, wenn Ihr Unternehmen als wesentliche oder wichtige Einrichtung in den horizontalen Geltungsbereich fällt und kein speziellerer Unionsrechtsakt denselben Bereich ersetzt. DORA gilt dagegen nur für Finanzunternehmen und bestimmte im Finanzaufsichtsrahmen definierte Kategorien, dafür aber unmittelbar und verbindlich seit dem 17. Januar 2025.

Ein typischer Dreiklang für die Einordnung sieht so aus:

  1. Ein Energieversorger, Krankenhaus oder Betreiber digitaler Infrastruktur prüft zuerst NIS2.
  2. Eine Bank, Versicherung oder Wertpapierfirma prüft zuerst DORA.
  3. Ein IT-Dienstleister oder Konzern mit mehreren regulierten Gesellschaften kann mit beiden Regimen in Berührung kommen, allerdings nicht immer auf dieselbe Weise.

Besonders missverständlich ist der Fall der Finanzunternehmen. Viele Häuser fallen schon wegen „Banking“ oder „Financial Market Infrastructures“ in den NIS2-Kontext. Das bedeutet aber nicht, dass NIS2 für alle Kernpflichten gleichrangig neben DORA steht. Vielmehr ist DORA gerade geschaffen worden, um die digitale operationale Resilienz des Finanzsektors sektorspezifisch und einheitlich zu regeln. In den Bereichen, die DORA explizit abdeckt, ist DORA daher der vorrangige Steuerungsmaßstab.

Gleichzeitig gibt es Konstellationen, in denen „beides“ die richtige Antwort ist. Das betrifft vor allem Unternehmensgruppen, in denen eine Finanzgesellschaft DORA-pflichtig ist, während eine Schwester- oder Tochtergesellschaft als Managed Service Provider, Rechenzentrumsbetreiber, Plattformbetreiber oder Lieferant in einem anderen regulatorischen Raster hängt. Es betrifft auch Outsourcing-Strukturen, in denen der Finanzkunde DORA erfüllen muss, während der Dienstleister zusätzlich aus seiner eigenen regulatorischen Stellung heraus NIS2-relevant sein kann.

Für die interne Governance ist deshalb eine Matrix sinnvoll:

UnternehmensrollePrimär zu prüfenTypische Zusatzfrage
Bank oder ZahlungsdienstleisterDORAWelche NIS2-Themen bleiben außerhalb des DORA-Kerns zusätzlich relevant?
Versicherung oder WertpapierfirmaDORAWie sind ICT-Drittdienstleister und Gruppenbezüge dokumentiert?
Rechenzentrum oder MSP außerhalb des FinanzsektorsNIS2Welche Kundenanforderungen aus DORA schlagen vertraglich durch?
IT-Dienstleister für BankenEigenstatus prüfen, oft NIS2 plus DORA-vertragliche AnforderungenWelche DORA-Klauseln verlangen Kunden zusätzlich?
Mischkonzern mit Finanz- und NichtfinanzgesellschaftenGesellschaftsbezogene TrennungWelche Controls sind zentral, welche sektorspezifisch?

Genau an dieser Stelle scheitern viele Programme: Sie bauen entweder alles als DORA-Projekt oder alles als NIS2-Projekt auf. Beides ist zu grob. Tragfähig ist nur ein Modell, das Rechtsregime, Gesellschaft, Funktion und Drittparteikette sauber auseinanderhält.

Lex-specialis-Prinzip: DORA verdrängt NIS2 im Finanzsektor

Das Lex-specialis-Prinzip bedeutet, dass eine speziellere Norm eine allgemeinere Norm verdrängt, soweit beide denselben Regelungsgegenstand erfassen. Auf das Verhältnis von NIS2 und DORA angewendet heißt das: Für Finanzunternehmen ersetzt DORA die NIS2-Anforderungen dort, wo DORA denselben Sachverhalt spezifisch regelt, insbesondere beim ICT-Risikomanagement und bei der Meldung schwerwiegender IKT-bezogener Vorfälle.

Warum ist das so wichtig? Weil es den Unterschied zwischen Doppelarbeit und belastbarer Compliance ausmacht. Ohne saubere Lex-specialis-Logik würde ein Finanzunternehmen zwei parallele Melde- und Risikosteuerungssysteme aufbauen, obwohl der europäische Gesetzgeber gerade eine sektorale Spezialregel schaffen wollte. Die Konsequenz lautet daher nicht „DORA plus identische NIS2-Dopplung“, sondern „DORA als Führungsrahmen mit gezielter Prüfung verbleibender NIS2-Schnittstellen“.

Praktisch ist das vor allem in vier Bereichen relevant:

  1. ICT-Risikomanagement: DORA geht tiefer in Governance, Schutz, Erkennung, Reaktion und Wiederherstellung.
  2. Vorfallmeldung: DORA regelt schwerwiegende IKT-bezogene Vorfälle sektorspezifisch über Aufsichtskanäle des Finanzsektors.
  3. Resilienztests: DORA konkretisiert Test- und Überprüfungspflichten deutlich stärker als NIS2.
  4. Drittparteisteuerung: DORA schafft ein eigenes, detailliertes Regime für ICT-Drittdienstleister.

Das bedeutet aber nicht, dass Finanzunternehmen NIS2 ignorieren dürfen. NIS2 bleibt als Referenzrahmen für den unionsweiten Grundansatz zur Cybersicherheit relevant und kann für Randbereiche, für Konzernabgrenzungen oder für nicht vollständig deckungsgleiche Sachverhalte Bedeutung behalten. Die Leitfrage lautet immer: Regelt DORA diesen konkreten Punkt schon speziell genug? Wenn ja, geht DORA vor.

Für die Umsetzung im Unternehmen ist das Lex-specialis-Prinzip auch kommunikativ wichtig. Compliance, Informationssicherheit, Einkauf und Management sollten nicht mit zwei konkurrierenden Programmen arbeiten, sondern mit einer zentralen Kontrollbibliothek, die bei jedem Control dokumentiert, ob der führende Anker NIS2 oder DORA ist.

IKT-Drittanbieter-Aufsicht — DORA strenger als NIS2

Im Verhältnis NIS2 DORA Unterschied ist kaum ein Bereich so deutlich wie die Behandlung von Drittparteien. NIS2 verlangt, dass Einrichtungen Lieferketten, Abhängigkeiten und Sicherheitsrisiken aus der Zusammenarbeit mit Dienstleistern angemessen in ihr Cyberrisikomanagement einbeziehen. Das ist wichtig, bleibt aber bewusst prinzipienbasiert.

DORA geht hier wesentlich weiter. Finanzunternehmen müssen nicht nur Risiken externer ICT-Dienstleistungen bewerten, sondern Verträge strukturiert ausgestalten, Informationsregister führen, kritische oder wichtige Funktionen identifizieren, Exit-Strategien mitdenken und sich auf ein formales Aufsichtsregime für kritische ICT-Drittdienstleister einstellen. Genau deshalb ist die Aussage „DORA ist im Drittparteibereich strenger als NIS2“ nicht bloß journalistische Zuspitzung, sondern regulatorisch zutreffend.

Die Unterschiede zeigen sich in der Praxis an fünf Stellen:

  1. Vor Vertragsschluss: DORA verlangt eine deutlich systematischere Due Diligence als NIS2 typischerweise vorgibt.
  2. Vertragsinhalt: DORA arbeitet mit konkreten Mindestklauseln, etwa zu Zugriff, Prüfungsrechten, Meldungen, Subunternehmern und Exit.
  3. Laufendes Monitoring: DORA erwartet eine engere fortlaufende Steuerung kritischer ICT-Abhängigkeiten.
  4. Informationsregister: Finanzunternehmen müssen die relevanten Auslagerungs- und ICT-Beziehungen strukturierter dokumentieren.
  5. Aufsicht über kritische Drittdienstleister: DORA schafft erstmals einen übergeordneten Aufsichtsmechanismus speziell für kritische ICT-Anbieter des Finanzsektors.

Für IT-Dienstleister ist das ein entscheidender Punkt. Auch wenn sie selbst nicht unmittelbar DORA-pflichtiges Finanzunternehmen sind, spüren sie DORA vertraglich sehr direkt. Banken und Versicherer werden tiefere Sicherheitsnachweise, klarere Subunternehmertransparenz, definierte Meldewege und belastbare Exit-Szenarien einfordern. Wer heute Dienstleistungen für Finanzkunden anbietet, sollte deshalb DORA nicht als fremdes Aufsichtsrecht betrachten, sondern als Marktstandard, der Beschaffung und Vertragsverhandlungen bereits prägt.

Meldepflichten im Vergleich: Der NIS2-DORA-Unterschied in der Praxis

Bei den Meldepflichten wird der Unterschied zwischen NIS2 und DORA operativ am sichtbarsten. NIS2 arbeitet mit einer unionsweit vorgegebenen Sequenz aus Frühwarnung binnen 24 Stunden, Folgemeldung binnen 72 Stunden und Abschlussbericht innerhalb eines Monats. Die Meldung geht an die zuständige Behörde oder das zuständige CSIRT. Für Deutschland ist die Perspektive dabei eng mit den künftigen BSI-Strukturen der nationalen NIS2-Umsetzung verbunden.

DORA arbeitet anders. Für Finanzunternehmen gibt es einen sektorspezifischen Meldeweg für schwerwiegende IKT-bezogene Vorfälle. In Deutschland fungiert die BaFin als zentraler Melde-Hub für DORA-Vorfallmeldungen und leitet Meldungen an weitere zuständige Stellen weiter. Das ist ein wesentlicher Grund, warum Finanzunternehmen ihre NIS2- und DORA-Meldeprozesse nicht einfach additiv nebeneinanderstellen sollten. Der primäre behördliche Ansprechpartner im DORA-Kontext ist eben nicht das allgemeine NIS2-Schema, sondern die Finanzaufsicht.

Für die Praxis sollten Sie Meldepflichten entlang der folgenden Fragen strukturieren:

  1. Handelt es sich um ein Finanzunternehmen im DORA-Scope?
  2. Ist der Vorfall ein schwerwiegender IKT-bezogener Vorfall im Sinne von DORA?
  3. Läuft die Erstkommunikation daher über die BaFin beziehungsweise den DORA-Meldeweg?
  4. Gibt es daneben zusätzliche nationale oder vertragliche Benachrichtigungspflichten?
  5. Sind parallel datenschutzrechtliche oder kundenbezogene Informationspflichten zu prüfen?

Gerade hier entstehen vermeidbare Fehler. Manche Häuser übernehmen die bekannte NIS2-24h-72h-1-Monats-Logik pauschal auch für DORA. Andere betrachten DORA nur als BaFin-Thema und verlieren aus dem Blick, dass Incident Classification, Eskalation, Wiederherstellung und Dokumentation im DORA-Modell deutlich präziser vorbereitet sein müssen. Tragfähig ist nur ein gemeinsamer Intake-Prozess mit regulatorischer Weiche: NIS2-Logik für horizontale Betreiberfälle, DORA-Logik für schwerwiegende IKT-Vorfälle im Finanzsektor.

Wenn Sie die NIS2-Seite dieses Themas vertiefen möchten, ist unser Beitrag zur NIS2-Meldepflicht binnen 24 Stunden der naheliegende nächste Schritt. Er zeigt, wie die Fristlogik organisatorisch in Incident Response und Management-Eskalation übersetzt werden sollte.

IT-Dienstleister zwischen NIS2 und DORA

IT-Dienstleister sitzen häufig genau an der Grenze zwischen beiden Regimen. Eigene regulatorische Pflichten ergeben sich für sie oft aus NIS2, wenn sie selbst als relevanter digitaler Dienst, Managed Service Provider oder sonstige wichtige Einrichtung qualifizieren. Gleichzeitig werden sie von DORA mittelbar erfasst, sobald Finanzkunden DORA-konforme Verträge, Sicherheitsnachweise, Registerdaten und Vorfallmeldelogiken verlangen.

Für Dienstleister lautet die praktische Kurzformel daher: eigene NIS2-Prüfung plus DORA-Fähigkeit im Kundenverhältnis. Wer nur den eigenen Rechtsstatus betrachtet, unterschätzt die Beschaffungsrealität im Finanzsektor. Banken und Versicherer werden ihre Lieferanten entlang von DORA auswählen, überprüfen und vertraglich steuern. Das betrifft insbesondere:

  1. Nachweise zum Sicherheitsniveau und zum Risiko-Management.
  2. Transparenz über Subunternehmer und Leistungsketten.
  3. Definierte Incident- und Eskalationswege.
  4. Auditierbare Dokumentation und Auskunftsfähigkeit.
  5. Exit- und Migrationsszenarien bei kritischen Leistungen.

Für viele IT-Dienstleister ist DORA deshalb ein kommerzieller Faktor, selbst wenn sie keine adressierte Finanzentität sind. Wer DORA-Kunden bedient, braucht meist DORA-kompatible Vertrags- und Betriebsprozesse. Gleichzeitig bleibt NIS2 für den eigenen Organisationsrahmen relevant. Genau diese Doppelperspektive sollten Dienstleister im Vertrieb, in der Vertragsgestaltung und in der Security-Governance aktiv einplanen.

Ein sinnvoller Startpunkt ist häufig nicht das Schreiben neuer Policies, sondern die Bestandsaufnahme: Welche Kunden sind Finanzunternehmen? Welche Leistungen stützen kritische oder wichtige Funktionen? Welche Nachweise können Sie heute schon liefern? Wo fehlen vertragliche Eskalationen, Audit-Klauseln oder Subunternehmertransparenz? Wer diese Fragen sauber beantwortet, bewegt sich weg von abstrakter Regulierungsdebatte hin zu konkreter Lieferfähigkeit.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen NIS2 und DORA?

NIS2 ist der allgemeine europäische Cybersicherheitsrahmen für wesentliche und wichtige Einrichtungen in 18 Sektoren. DORA ist die sektorspezifische Verordnung für den Finanzsektor. Der Unterschied liegt daher nicht nur im Adressatenkreis, sondern in der Regelungstiefe: DORA ist bei ICT-Risikomanagement, Vorfallmeldung, Tests und Drittparteisteuerung deutlich spezieller.

Brauche ich NIS2 und DORA?

Das kann vorkommen, aber nicht im Sinn einer vollständigen doppelten Umsetzung derselben Controls. Ein Finanzunternehmen prüft primär DORA und nur ergänzend, welche NIS2-Aspekte daneben eigenständig relevant bleiben. Ein IT-Dienstleister kann selbst NIS2-pflichtig sein und zugleich DORA-Anforderungen seiner Finanzkunden vertraglich erfüllen müssen.

Gilt DORA oder NIS2 für Banken?

Für Banken gilt primär DORA. DORA ist für den Finanzsektor der speziellere Rechtsrahmen und verdrängt NIS2 dort, wo beide denselben Sachverhalt regeln. NIS2 verschwindet damit nicht vollständig aus dem Bild, ist aber für Banken nicht der führende Spezialstandard in den Kernbereichen digitaler operationaler Resilienz.

Was bedeutet lex specialis bei NIS2 und DORA?

Lex specialis bedeutet Vorrang des spezielleren Rechts. Im Verhältnis zwischen NIS2 und DORA heißt das, dass DORA für Finanzunternehmen den allgemeineren NIS2-Rahmen in den speziell geregelten Themenfeldern ersetzt. Genau deshalb müssen Finanzunternehmen keine parallelen, widersprüchlichen Standards für dieselbe Pflichtmaterie aufbauen.

Welche Pflichten hat DORA, die NIS2 nicht hat?

DORA geht bei IKT-Drittanbietern, Resilienztests, Informationsregistern und dem aufsichtsrechtlichen Zugriff auf kritische ICT-Drittdienstleister weiter als NIS2. NIS2 verlangt ebenfalls wirksame Cybersicherheitsmaßnahmen, bleibt aber stärker prinzipienbasiert und sektorübergreifend. Für Finanzunternehmen ist DORA deshalb der granularere operative Maßstab.

Fazit: Für Finanzunternehmen ist DORA der Führungsrahmen, NIS2 bleibt der Hintergrundrahmen

Die belastbare Antwort auf NIS2 vs DORA lautet: DORA geht im Finanzsektor vor, weil DORA als lex specialis den spezielleren Rechtsrahmen für digitale operationale Resilienz bildet. NIS2 bleibt für alle anderen regulierten Sektoren zentral und kann auch im Umfeld von Finanzgruppen, Dienstleistern und nicht deckungsgleichen Themen weiter relevant sein. Wer Compliance sauber steuern will, sollte daher nicht in Entweder-oder-Kategorien denken, sondern pro Gesellschaft, Funktion und Drittparteikette den führenden Rechtsanker festlegen.

Wenn Sie Ihr Management, Ihre IT und Ihre Compliance-Funktion auf NIS2-Pflichten praxisnah ausrichten wollen, ist unsere NIS2-Schulung der naheliegende nächste Schritt. Ergänzend helfen die NIS2-Checkliste, die Anleitung zur NIS2-Meldepflicht binnen 24 Stunden und der Vergleich NIS2 vs. ISO 27001 dabei, Anforderungen in konkrete Maßnahmen, Verantwortlichkeiten und Nachweise zu übersetzen.

Ihr KI-Nachweis in 90 Minuten

Seit Februar 2025 gilt der EU AI Act. Jedes Unternehmen in der EU muss nachweisen, dass seine Mitarbeiter im Umgang mit KI geschult sind. Per Gesetz und ohne Ausnahme. Ohne Nachweis drohen Bußgelder bis 35 Mio. EUR oder 7% des Jahresumsatzes.