DORA vs. NIS2 — Welche EU-Resilienzpflicht trifft Sie wirklich?

DORA und NIS2 im Überblick

Kaum eine Compliance-Frage sorgt im DACH-Markt aktuell für so viel Verwirrung wie „DORA oder NIS2?". Der Grund: Beide Regelwerke sind EU-Vorgaben zur digitalen und operativen Resilienz, beide adressieren ICT-Risikomanagement, und beide gelten seit 2025 scharf — aber sie haben unterschiedliche Geltungsbereiche, unterschiedliche Aufsichtsbehörden und unterschiedliche Rechtsfolgen. Wer das vermischt, riskiert Doppelarbeit oder, schlimmer, eine ungeschützte Lücke.

Erschwerend kommt ein zweites Missverständnis hinzu, das wir in der Beratungspraxis fast wöchentlich sehen: Die Abkürzung „DORA" wird systematisch verwechselt. Im Regulatorik-Kontext steht DORA für den Digital Operational Resilience Act — eine EU-Verordnung für den Finanzsektor, anwendbar seit dem 17. Januar 2025. In DevOps-Kreisen meint „DORA" hingegen die DORA-Metriken (DevOps Research and Assessment): Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service. Zwei vollkommen verschiedene Welten, identische vier Buchstaben.

Dieser Artikel räumt mit beiden Verwechslungen auf. Wir liefern eine saubere Disambiguierung, eine Side-by-Side-Gegenüberstellung von DORA-Verordnung und NIS2, einen Entscheidungsbaum für die Frage „Welche Regel gilt für uns?" und eine klare Antwort auf das Vorrangverhältnis im Finanzsektor (Stichwort lex specialis). Grundlage sind die offiziellen EU-Texte sowie die deutsche NIS2-Umsetzung.

Die DORA-Falle: Verordnung vs. DevOps-Metrik

Bevor wir DORA und NIS2 vergleichen, muss eine Begriffsklärung erfolgen, die in deutschsprachigen Quellen fast immer fehlt. „DORA" bezeichnet im Jahr 2026 zwei grundverschiedene Dinge, und die Suchanfragen vermischen beide ungefiltert.

Erstens: Der Digital Operational Resilience Act ist die Verordnung (EU) 2022/2554. Sie regelt die digitale operative Widerstandsfähigkeit von Finanzunternehmen — Banken, Versicherungen, Zahlungsdienstleister, Krypto-Asset-Dienstleister, Handelsplätze und ihre kritischen IKT-Drittdienstleister. DORA ist seit dem 17. Januar 2025 unmittelbar anwendbar. 2025 galt als Übergangsjahr, 2026 ist das Jahr der aktiven Durchsetzung, unter anderem über das Register of Information (Stichtag 31. Dezember 2025).

Zweitens: Die DORA-Metriken aus dem DevOps-Umfeld stammen aus dem DevOps-Research-and-Assessment-Programm. Sie messen die Software-Delivery-Performance von Engineering-Teams und haben mit EU-Regulatorik nichts zu tun. Wer den Unterschied vertiefen möchte: Unser Leitfaden „DORA Metrics erklärt" behandelt ausschließlich die DevOps-Metriken und ist die richtige Anlaufstelle, wenn es um Deployment Frequency und Lead Time geht — nicht um Finanzaufsicht.

Praktische Konsequenz: Wenn Ihre Compliance-Abteilung „wir müssen DORA umsetzen" sagt, prüfen Sie zuerst, welche DORA gemeint ist. Ein Finanzunternehmen meint fast immer die Verordnung. Ein Engineering-Leiter meint fast immer die Metriken. Diese fünf Sekunden Klärung verhindern wochenlange Fehlplanung.

Was ist die DORA-Verordnung?

Der Digital Operational Resilience Act ist das EU-Regelwerk für die digitale operative Resilienz des Finanzsektors. Ziel ist, dass Finanzunternehmen schwere IKT-Störungen — Cyberangriffe, Ausfälle, Drittdienstleister-Probleme — überstehen, ohne dass die Finanzstabilität oder der Kundenschutz gefährdet werden. DORA ist seit dem 17. Januar 2025 anwendbar und wird durch technische Regulierungsstandards der europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) konkretisiert.

DORA ruht auf fünf Säulen: erstens IKT-Risikomanagement mit einem dokumentierten Rahmen unter Verantwortung des Leitungsorgans; zweitens Behandlung, Klassifizierung und Meldung IKT-bezogener Vorfälle an die zuständige Aufsicht; drittens Testen der digitalen operativen Resilienz, einschließlich bedrohungsgeleiteter Penetrationstests (TLPT) für bedeutende Institute; viertens Management des IKT-Drittparteienrisikos inklusive verpflichtender Vertragsklauseln und des Register of Information; fünftens Informationsaustausch über Cyberbedrohungen.

Adressaten sind rund zwanzig Kategorien von Finanzunternehmen — von Kreditinstituten und Wertpapierfirmen über Zahlungs- und E-Geld-Institute, Versicherungen und Rückversicherer bis zu Krypto-Asset-Dienstleistern und Handelsplätzen. Zusätzlich erfasst DORA als Aufsichtsregime kritische IKT-Drittdienstleister (etwa große Cloud-Anbieter), die direkt von den europäischen Aufsichtsbehörden überwacht werden können.

Was ist NIS2?

NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Netz- und Informationssicherheit. Sie ist der breite Querschnittsrahmen für Cybersicherheit über praktisch alle gesellschaftlich und wirtschaftlich kritischen Sektoren hinweg — Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung, Post, Abfall, Chemie, Lebensmittel, Fertigung und digitale Anbieter. Anders als eine Verordnung muss eine Richtlinie in nationales Recht umgesetzt werden.

In Deutschland erfolgt die Umsetzung durch das NIS2-Umsetzungsgesetz (NIS2UmsuCG). Dieses verschärft die Pflichten gegenüber dem bisherigen IT-Sicherheitsrecht erheblich: ein verpflichtendes Risikomanagement mit zehn Mindestmaßnahmen-Bereichen, ein gestuftes Meldewesen für erhebliche Sicherheitsvorfälle (Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats), Lieferketten-Sicherheit sowie eine nicht delegierbare Verantwortung der Geschäftsleitung mit persönlicher Haftung. Eine vertiefte Darstellung der zehn Maßnahmen-Bereiche und Fristen finden Sie in unserem Beitrag zum NIS2-Umsetzungsgesetz.

NIS2 unterscheidet zwischen „wesentlichen" und „wichtigen" Einrichtungen, wobei sich die Einstufung primär nach Sektor und Unternehmensgröße richtet (Schwellen typischerweise ab 50 Beschäftigten oder 10 Mio. Euro Umsatz, mit sektoralen Sonderfällen). Der Kreis der betroffenen Unternehmen ist mit einer mittleren fünfstelligen Zahl deutlich größer als unter der Vorgängerregelung.

DORA vs. NIS2: Die große Gegenüberstellung

Der fundamentale Unterschied lässt sich in einem Satz fassen: DORA ist ein sektorspezifisches, unmittelbar anwendbares Resilienz-Regelwerk ausschließlich für den Finanzsektor; NIS2 ist ein sektorübergreifender Cybersicherheits-Mindeststandard, der über nationale Umsetzungsgesetze gilt. Beide überschneiden sich im IKT-Risikomanagement, divergieren aber bei Geltungsbereich, Aufsicht, Meldewegen und Rechtsnatur.

Die folgende Tabelle stellt die entscheidungsrelevanten Kriterien systematisch gegenüber. Sie ersetzt keine Rechtsberatung, liefert aber die Struktur, mit der IT- und Compliance-Verantwortliche die Zuordnung für ihr Unternehmen vornehmen können.

Wichtig: Der Vergleich ist keine Wertung. Beide Regelwerke sind in ihrem jeweiligen Anwendungsbereich verpflichtend. Die relevante Frage ist nicht „welches ist besser", sondern „welches gilt für uns — und in welcher Reihenfolge".

Vorrang von DORA im Finanzsektor (lex specialis)

Die für viele Häuser entscheidende Frage lautet: „Wir sind eine Bank/Versicherung — gilt für uns DORA, NIS2 oder beides?". Die Antwort ergibt sich aus dem Verhältnis lex specialis derogat legi generali — die speziellere Regelung verdrängt die allgemeinere.

DORA ist die sektorspezifische Spezialregelung für den Finanzsektor und nimmt für die von ihr erfassten Finanzunternehmen ausdrücklich Vorrang gegenüber den IKT-Risikomanagement- und Meldepflichten von NIS2. Konkret: Erfüllt ein Finanzunternehmen die DORA-Anforderungen zu IKT-Risikomanagement, Vorfallmeldung, Resilienz-Tests und Drittparteienrisiko, wird es insoweit nicht zusätzlich nach den entsprechenden NIS2-Pflichten in Anspruch genommen. DORA wirkt hier als lex specialis, NIS2 als lex generalis.

Das bedeutet jedoch nicht, dass NIS2 für Finanzunternehmen vollständig irrelevant ist. Die Spezialitätswirkung betrifft die deckungsgleichen IKT-Bereiche. Aspekte, die DORA nicht oder anders adressiert, oder Konzerneinheiten außerhalb des DORA-Anwendungsbereichs (etwa nicht-finanzielle Tochtergesellschaften), können weiterhin unter NIS2 fallen. Die belastbare Zuordnung erfordert daher eine entitäts- und tätigkeitsgenaue Analyse — nicht eine pauschale Konzernaussage.

Überschneidungen im ICT-Risikomanagement

Trotz unterschiedlicher Reichweite teilen DORA und NIS2 einen gemeinsamen konzeptionellen Kern: ein dokumentiertes, vom Leitungsorgan verantwortetes IKT-/Cyber-Risikomanagement, ein strukturiertes Vorfall-Handling mit Meldepflichten, Anforderungen an Lieferketten- und Drittparteiensicherheit sowie Business Continuity und Wiederanlauf. Wer eines der beiden Regelwerke sauber implementiert, hat einen erheblichen Teil der Substanz des anderen bereits abgedeckt.

Diese Überschneidung ist die strategische Chance: Ein gemeinsames Control-Set, abgebildet auf einen anerkannten Sicherheitsrahmen, lässt sich zugleich gegen DORA- und NIS2-Anforderungen mappen. In der Praxis nutzen wir hierfür den NIST Cybersecurity Framework 2.0 als integrierende Klammer; die Detaildarstellung dazu liefert unser NIST-CSF-2.0-Assessment-Leitfaden. Das vermeidet zwei getrennte Programme mit redundanter Evidenz.

Die Unterschiede dürfen dabei nicht eingeebnet werden. DORA verlangt deutlich granularere Drittparteien-Governance (Register of Information, Pflichtklauseln, TLPT für bedeutende Institute), während NIS2 mit dem gestuften 24/72/Monats-Meldeschema und der nicht delegierbaren Geschäftsleitungshaftung eigene, schärfere Akzente setzt. Ein integriertes Zielbild muss daher beide Maxima abdecken, nicht den kleinsten gemeinsamen Nenner.

Entscheidungsbaum: Welche Regel gilt für Sie?

Die folgende Schrittfolge führt von der Unternehmensrealität zur korrekten regulatorischen Zuordnung. Sie ist als Erstindikation gedacht und ersetzt keine rechtliche Einzelfallprüfung — liefert aber die belastbare Struktur, um das Compliance-Programm richtig aufzusetzen.

1. 1Ist Ihre Einheit ein Finanzunternehmen im Sinne von DORA (Bank, Versicherer, Zahlungs-/E-Geld-Institut, Wertpapierfirma, Krypto-Asset-Dienstleister, Handelsplatz)? Wenn ja: DORA ist anwendbar und für die IKT-Pflichten vorrangig — weiter mit Schritt 2. Wenn nein: weiter mit Schritt 4.
2. 2Erfüllen Sie die fünf DORA-Säulen vollständig (IKT-Risikomanagement, Vorfallmeldung, Resilienz-Tests, Drittparteienrisiko inkl. Register of Information, Informationsaustausch)? Wenn nein: DORA-Programm priorisieren, da 2026 das aktive Durchsetzungsjahr ist.
3. 3Gibt es im selben Konzern Einheiten oder Tätigkeiten außerhalb des DORA-Scopes (z. B. nicht-finanzielle Tochtergesellschaften, IT-Dienstleister-Gesellschaften)? Wenn ja: für diese Einheiten separat NIS2-Betroffenheit prüfen — weiter mit Schritt 4. Wenn nein: Zuordnung abgeschlossen, DORA ist maßgeblich.
4. 4Fällt die Einheit unter einen NIS2-Sektor (Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung u. a.) und überschreitet sie die Größenschwellen (typischerweise ab 50 Beschäftigten oder 10 Mio. Euro Umsatz, mit sektoralen Sonderfällen)? Wenn ja: Einstufung als wesentliche oder wichtige Einrichtung vornehmen — weiter mit Schritt 5. Wenn nein: keine unmittelbare DORA-/NIS2-Pflicht, dennoch vertragliche Lieferkettenanforderungen Dritter prüfen.
5. 5Setzen Sie die NIS2-Pflichten um: zehn Mindestmaßnahmen-Bereiche, gestuftes Meldewesen (24 h / 72 h / 1 Monat), Lieferkettensicherheit und nicht delegierbare Geschäftsleitungsverantwortung — und mappen Sie das Control-Set auf einen anerkannten Sicherheitsrahmen, um Doppelarbeit mit etwaigen DORA-Anforderungen zu vermeiden.

Wann welche Regel — und wann beide

Wann DORA: Sie sind ein reguliertes Finanzunternehmen oder ein kritischer IKT-Drittdienstleister für solche. Dann ist DORA nicht optional, sondern unmittelbar anwendbares Recht — mit Vorrang vor den deckungsgleichen NIS2-IKT-Pflichten. Priorität hat hier 2026 der Nachweis: Register of Information, vertragliche IKT-Drittparteienklauseln und ein prüffähiger IKT-Risikorahmen.

Wann NIS2: Sie betreiben kritische Infrastruktur oder wesentliche Dienste außerhalb des Finanzsektors und überschreiten die Größenschwellen. Dann gilt das nationale NIS2-Umsetzungsgesetz mit den zehn Maßnahmen-Bereichen, dem 24/72/Monats-Meldeschema und der persönlichen Geschäftsleitungshaftung. Hier ist der Zeitdruck im DACH-Markt besonders hoch, weil keine lange Übergangsfrist vorgesehen ist.

Wann beide: Bei Mischkonzernen mit Finanz- und Nicht-Finanz-Einheiten oder bei Finanzunternehmen, deren Konzern auch NIS2-relevante Dienste betreibt. Hier empfehlen wir kein zweigleisiges Doppelprogramm, sondern ein integriertes Resilienz-Zielbild: ein gemeinsames, auf NIST CSF 2.0 gemapptes Control-Set, das die jeweils strengere Anforderung pro Domäne als Zielwert nimmt und entitätsspezifische Nachweise (DORA-Register vs. NIS2-Meldekette) als Ableitungen führt. Den methodischen Überbau dazu liefert unser IT-Governance-Assessment-Leitfaden.

Fazit

Die Frage „DORA oder NIS2?" hat zwei Antworten — eine begriffliche und eine regulatorische. Begrifflich gilt: DORA-Verordnung und DORA-Metrik sind nicht dasselbe; klären Sie das, bevor ein Programm startet. Regulatorisch gilt: DORA ist die sektorspezifische Spezialregelung für den Finanzsektor und verdrängt dort die deckungsgleichen NIS2-IKT-Pflichten, während NIS2 der breite, sektorübergreifende Mindeststandard für kritische Einrichtungen ist.

Für reine Finanzunternehmen ist DORA der maßgebliche Rahmen, und 2026 verschiebt sich der Fokus von der Konzeption zum prüffähigen Nachweis. Für kritische Einrichtungen außerhalb des Finanzsektors ist NIS2 die unausweichliche Pflicht mit hohem Zeitdruck. Mischkonzerne brauchen ein integriertes Zielbild statt zweier paralleler Programme.

Unsere Empfehlung an CIOs und Compliance-Verantwortliche: Klären Sie zuerst die Entität-zu-Regel-Zuordnung sauber (Entscheidungsbaum oben), bauen Sie dann ein gemeinsames, auf einen anerkannten Sicherheitsrahmen gemapptes Control-Set und führen Sie die regelspezifischen Nachweise als Ableitungen daraus. So vermeiden Sie sowohl die teure Doppelarbeit als auch die gefährliche Lücke.

Als Berater für IT-Governance und Resilienz begleiten wir Organisationen von der regulatorischen Zuordnung über die Control-Mappings bis zum prüffähigen Nachweis. Nutzen Sie unsere Assessment-Werkzeuge, um Ihren aktuellen Resilienz-Reifegrad zu bestimmen und eine belastbare Roadmap abzuleiten.

Quellen & Referenzen

Die in diesem Artikel referenzierten Rechtsakte und Standards basieren auf den folgenden offiziellen Quellen:

• DORA — Verordnung (EU) 2022/2554 (EUR-Lex): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022R2554
• NIS2 — Richtlinie (EU) 2022/2555 (EUR-Lex): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022L2555
• BSI — NIS-2-regulierte Unternehmen: https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html
• ISACA — Resilience and Security in Critical Sectors: Navigating NIS2 and DORA: https://www.isaca.org/resources/white-papers/2025/resilience-and-security-in-critical-sectors-navigating-nis2-and-dora-requirements
• NIST Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework