DORA und NIS2 sind fast zeitgleich entstanden, adressieren dieselbe Sorge – die Abhängigkeit ganzer Wirtschaftszweige von funktionierender IT – und verwenden über weite Strecken dieselben Bausteine: Risikomanagement, Vorfallmeldung, Steuerung von Drittparteien, Verantwortung der Leitung. Für Compliance-Verantwortliche stellt sich deshalb zuerst eine Zuordnungsfrage und erst danach eine inhaltliche.
Die Zuordnungsfrage ist meist schneller beantwortet, als sie wirkt. DORA gilt für Finanzunternehmen und für kritische IKT-Drittdienstleister. NIS2 gilt, in Deutschland über das BSI-Gesetz, für Einrichtungen in einer Reihe kritischer Sektoren, bestimmt nach Sektor und Unternehmensgröße. Wer weder dem Finanzsektor angehört noch als IKT-Dienstleister für ihn arbeitet, muss sich mit DORA nicht befassen.
Schwieriger sind die Grenzfälle, und sie sind häufiger als erwartet. Ein Finanzunternehmen kann sektoral auch in den Blick von NIS2 geraten; hier greift der Vorrang des sektorspezifischen Rechts. Ein IT-Dienstleister kann unter das BSIG fallen und zugleich über die Verträge seiner Kunden DORA-Anforderungen ausgesetzt sein, ohne selbst Adressat der Verordnung zu sein. Und in Konzernen mit Finanz- und Nicht-Finanzgesellschaften gelten beide Regime nebeneinander, nur für unterschiedliche Einheiten.
Im Direktvergleich
| Kriterium | DORA | NIS2 |
|---|---|---|
| Rechtsform | Verordnung (EU) 2022/2554. Als Verordnung gilt sie unmittelbar in allen Mitgliedstaaten und im gleichen Wortlaut; ein nationales Umsetzungsgesetz ist dafür nicht erforderlich. | Richtlinie (EU) 2022/2555. Als Richtlinie richtet sie sich an die Mitgliedstaaten und wirkt erst über nationales Recht, in Deutschland über das NIS-2-Umsetzungsgesetz, das die Vorgaben im BSI-Gesetz verankert. |
| Geltung in Deutschland | Seit Januar 2025 anwendbar. Konkretisiert wird die Verordnung durch technische Regulierungs- und Durchführungsstandards der europäischen Aufsichtsbehörden. | Das NIS-2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft. Maßgeblicher Text ist damit das BSIG, das in Einzelheiten von anderen nationalen Umsetzungen abweichen kann. |
| Anwendungsbereich | Finanzunternehmen im weiten Sinn, unter anderem Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherungs- und Rückversicherungsunternehmen, Kapitalverwaltungsgesellschaften und Anbieter von Kryptowerte-Dienstleistungen. Zusätzlich erfasst sind kritische IKT-Drittdienstleister. | Einrichtungen in Sektoren hoher Kritikalität und in sonstigen kritischen Sektoren, unter anderem Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, Abfall, Chemie, Lebensmittel und verarbeitendes Gewerbe. Maßgeblich sind Sektor und Unternehmensgröße nach § 28 BSIG. Die öffentliche Verwaltung steht nicht in den Anlagen des BSIG: Einrichtungen der Bundesverwaltung regelt § 29 BSIG, für die Landesverwaltungen gilt Landesrecht. |
| Wer geht vor | Sektorspezifisches Recht für den Finanzsektor. Für die Bereiche, die DORA regelt, geht die Verordnung den entsprechenden Anforderungen aus NIS2 vor. | Allgemeiner Rahmen. Die Richtlinie lässt gleichwertige sektorspezifische Anforderungen ausdrücklich vorgehen; für Finanzunternehmen ist das DORA. |
| Regelungstiefe | Hoch. Die Verordnung ist bereits im Text detailliert und wird durch verbindliche technische Standards weiter konkretisiert. Der Auslegungsspielraum ist entsprechend gering. | Mindestharmonisierung. Die Richtlinie nennt Mindestinhalte, die Mitgliedstaaten dürfen strenger sein. Die Konkretisierung erfolgt national über das BSIG und die Praxis des BSI. |
| IKT-Risikomanagement | Kapitel II (Art. 5 bis 16) verlangt einen dokumentierten IKT-Risikomanagementrahmen mit Strategien, Leitlinien, Verfahren und Werkzeugen: von Schutz und Erkennung über Reaktion und Wiederherstellung bis zu Lernen und Kommunikation. Für kleine Unternehmen ist ein vereinfachter Rahmen vorgesehen. | § 30 BSIG verlangt geeignete, verhältnismäßige technische und organisatorische Maßnahmen auf Grundlage eines Ansatzes, der alle Gefahren berücksichtigt. Die Maßnahmenbereiche sind aufgezählt, die Methodik bleibt offen. |
| Meldepflichten | Kapitel III (Art. 17 bis 23). Schwerwiegende IKT-bezogene Vorfälle sind zu klassifizieren und gestuft an die zuständige Aufsichtsbehörde zu melden: Erstmeldung, Zwischenbericht, Abschlussbericht. Für erhebliche Cyberbedrohungen ist eine freiwillige Meldung vorgesehen. | § 32 BSIG. Erhebliche Sicherheitsvorfälle sind gestuft an die von BSI und BBK eingerichtete gemeinsame Meldestelle zu melden: frühe Erstmeldung, ausführlichere Meldung, Abschlussmeldung. Kriterien und Fristen ergeben sich aus dem Gesetz. |
| Testen der Resilienz | Kapitel IV (Art. 24 bis 27) verlangt ein Programm zum Testen der digitalen operationalen Resilienz. Für bestimmte Unternehmen kommen bedrohungsorientierte Penetrationstests hinzu. | Konzepte zur Bewertung der Wirksamkeit der Maßnahmen, dazu grundlegende Schulungen und Sensibilisierungsmaßnahmen. Ein eigenständiges, formalisiertes Testprogramm in vergleichbarer Tiefe schreibt das Gesetz nicht vor. |
| Drittparteien und Lieferkette | Kapitel V Abschnitt I (Art. 28 bis 30) regelt Vertragsinhalte, Ausstiegsstrategien, Konzentrationsrisiko und ein Informationsregister über alle vertraglichen Vereinbarungen zur IKT-Nutzung. | Lieferkettensicherheit und die Beziehungen zu unmittelbaren Anbietern und Dienstleistern gehören zu den geforderten Maßnahmenbereichen. Ein Informationsregister kennt das BSIG nicht. |
| Aufsicht über Dienstleister | Kapitel V Abschnitt II (Art. 31 bis 44) begründet einen europäischen Überwachungsrahmen für kritische IKT-Drittdienstleister. Die europäischen Aufsichtsbehörden haben im November 2025 eine erste Liste solcher Anbieter veröffentlicht. | Kein eigenes Aufsichtsregime. Ein Anbieter wird nur erfasst, wenn er selbst als Einrichtung in den Anwendungsbereich fällt. |
| Verantwortung der Leitung | Das Leitungsorgan trägt die Letztverantwortung für das IKT-Risikomanagement, legt Zuständigkeiten fest, genehmigt die Strategie und muss sein Wissen zu IKT-Risiken laufend aktuell halten. | § 38 BSIG verpflichtet die Geschäftsleitung, die Risikomanagementmaßnahmen umzusetzen und ihre Umsetzung zu überwachen, knüpft daran eine gesellschaftsrechtliche Haftung und sieht eine Schulungspflicht vor. |
| Zuständige Aufsicht | Die Finanzaufsicht; in Deutschland die BaFin. Für kritische IKT-Drittdienstleister tritt der europäische Überwachungsrahmen der europäischen Aufsichtsbehörden hinzu. | Das BSI mit Auskunfts-, Prüf- und Anordnungsbefugnissen. Die Prüfintensität richtet sich nach der Einrichtungskategorie. |
Unser Fazit
Die erste Antwort ist eine Zuordnung, keine Abwägung. Sie können sich zwischen DORA und NIS2 nicht entscheiden; der Anwendungsbereich entscheidet über Sie.
Finanzunternehmen richten sich nach DORA. Wo die Verordnung IKT-Risikomanagement, Vorfallmeldung, Resilienztests und Drittparteienrisiko regelt, geht sie den entsprechenden Anforderungen aus NIS2 vor. Das entlastet: Ein zweites, paralleles Regime für dieselben Sachverhalte entsteht nicht. Es entlastet allerdings nur dort, wo DORA tatsächlich regelt. Andere Pflichten aus dem nationalen Recht bleiben davon unberührt, und die Abgrenzung im Einzelfall gehört in eine rechtliche Prüfung.
Unternehmen außerhalb des Finanzsektors richten sich nach dem BSIG, sofern sie nach Sektor und Größe erfasst sind. DORA ist für sie nur mittelbar relevant, nämlich dann, wenn sie IKT-Leistungen für Finanzunternehmen erbringen. Dann kommen die DORA-Vorgaben über Vertragsklauseln, Auskunfts- und Prüfrechte sowie Ausstiegsregelungen bei ihnen an, ohne dass sie selbst Adressat der Verordnung wären. Diese vertragliche Durchreichung ist der Weg, auf dem DORA die meisten Nicht-Finanzunternehmen tatsächlich erreicht. In Konzernen mit gemischtem Portfolio ist deshalb je Gesellschaft einzuordnen; eine konzernweite Pauschalantwort führt regelmäßig in die Irre, weil Anwendungsbereich und Aufsicht an die einzelne Einheit anknüpfen.
Inhaltlich lohnt der Blick auf die Überschneidung. IKT-Risikomanagement, Vorfallerkennung und -behandlung, Business Continuity, Zugriffskontrolle und die Steuerung von Dienstleistern sind in beiden Regimen gefordert. Wer dafür eine gemeinsame Grundlage betreibt, ein Managementsystem für Informationssicherheit mit sauberem Asset- und Risikobezug, kann dieselben Maßnahmen und Nachweise mehrfach verwenden und muss nur die regimespezifischen Aufsätze trennen.
Die Unterschiede, die sich nicht zusammenführen lassen, sind die formalen: unterschiedliche Meldewege an unterschiedliche Behörden, unterschiedliche Schwellen und Klassifizierungen und, im Fall von DORA, das Informationsregister sowie das Testprogramm, für die es unter NIS2 keine Entsprechung in vergleichbarer Tiefe gibt. Planen Sie diese Teile getrennt, statt sie in ein gemeinsames Raster zu zwingen.