DORA ist die gezielte EU-Regelung für digitale operative Resilienz im Finanzsektor; NIS2 adressiert dagegen die Cybersicherheit essenzieller und wichtiger Einrichtungen in vielen EU-Sektoren breiter.
Der Unterschied ist für Compliance-, Sicherheits- und Rechtsverantwortliche mehr als eine formale Abgrenzung. In vielen Unternehmen entscheidet er darüber, welche Behörde zuständig ist, welche Meldewege vorbereitet werden müssen, wie Lieferantenverträge aussehen und ob Leitungsorgane ihre Nachweise über Cyberrisiken neu strukturieren müssen.
Beide Regelwerke verfolgen ein ähnliches Ziel: digitale Störungen sollen beherrschbar bleiben, bevor sie kritische Dienste, Finanzmärkte oder Lieferketten gefährden. DORA und NIS2 erreichen dieses Ziel jedoch über unterschiedliche Rechtsinstrumente, unterschiedliche Sektoren und teilweise unterschiedliche Aufsichtslogiken. Diese Unterschiede sollten früh verstanden werden, weil ein Unternehmen durchaus unter beide Regime fallen kann.
Stand: 2026. Dieser Beitrag bietet eine fachliche Einordnung auf Basis der EU-Regelungen, insbesondere der DORA-Verordnung und der NIS2-Richtlinie auf EUR-Lex, ersetzt aber keine Rechtsberatung. Nationale NIS2-Umsetzungsgesetze, Behördenleitfäden und sektorspezifische Aufsichtspraxis können zusätzliche Anforderungen oder Präzisierungen enthalten.
Warum DORA und NIS2 nebeneinander bestehen
DORA und NIS2 entstanden aus derselben Grundbeobachtung: Cybervorfälle sind selten rein interne IT-Ereignisse. Ein Ausfall bei einem Cloud-Anbieter, eine kompromittierte Softwarelieferkette oder ein Ransomware-Angriff auf einen Dienstleister kann mehrere Organisationen gleichzeitig treffen und dadurch gesellschaftliche oder finanzielle Funktionen beeinträchtigen.
NIS2 adressiert dieses Risiko horizontal. Die Richtlinie erweitert den Kreis der regulierten Organisationen gegenüber der früheren NIS-Richtlinie und verpflichtet essenzielle und wichtige Einrichtungen in Sektoren wie Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, öffentliche Verwaltung, bestimmte Fertigungsbereiche und IKT-Dienstleistungen zu Risikomanagement, Vorfallmeldung und Governance.
DORA ist enger, aber tiefer. Die Verordnung richtet sich an Finanzunternehmen und berücksichtigt, dass der Finanzsektor besonders stark von IKT-Dienstleistungen, Datenverfügbarkeit, Zahlungsinfrastrukturen, Handelsplattformen und ausgelagerten Technologieprozessen abhängt. Ein schwerer IKT-Vorfall kann dort nicht nur ein einzelnes Institut treffen, sondern Vertrauen, Marktstabilität und Zahlungsfähigkeit berühren.
Der zeitliche Unterschied wird häufig missverstanden. DORA trat bereits 2023 in Kraft, ist aber seit Januar 2025 anwendbar. NIS2 trat ebenfalls 2023 in Kraft; die Mitgliedstaaten mussten die Richtlinie bis Oktober 2024 in nationales Recht umsetzen. Bei NIS2 kommt es deshalb in der Praxis stärker darauf an, wie das jeweilige Land die Richtlinie ausgestaltet und welche Behörde zuständig ist.
Der Kernunterschied: Verordnung für Finanzresilienz, Richtlinie für sektorübergreifende Cybersicherheit
DORA ist eine EU-Verordnung. Sie gilt unmittelbar in den Mitgliedstaaten und schafft ein einheitliches Regelwerk für das IKT-Risikomanagement im Finanzsektor. Dazu gehören Anforderungen an Governance, Risikomanagement, Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch und das Management von IKT-Drittparteien.
NIS2 ist eine EU-Richtlinie. Sie muss durch nationale Gesetze umgesetzt werden, wodurch Begrifflichkeiten, Zuständigkeiten und Vollzug im Detail variieren können. Der gemeinsame Kern bleibt jedoch: betroffene Einrichtungen müssen technische, operative und organisatorische Maßnahmen zur Risikosteuerung treffen, bedeutende Sicherheitsvorfälle melden und Leitungsorgane stärker in die Verantwortung nehmen.
Aus praktischer Sicht bedeutet das: DORA beantwortet für Finanzunternehmen sehr spezifisch, wie IKT-Risiken in das Risikomanagement, die Aufsicht über Drittanbieter und Resilienztests eingebettet werden sollen. NIS2 fragt breiter, ob eine Organisation in einem kritischen oder wichtigen Sektor tätig ist und angemessene Cybersicherheitsmaßnahmen nachweisen kann.
Vergleich der wichtigsten Unterschiede zwischen DORA und NIS2
| Kriterium |
DORA |
NIS2 |
| Rechtsform |
EU-Verordnung, unmittelbar anwendbar |
EU-Richtlinie, Umsetzung durch nationale Gesetze |
| Schwerpunkt |
Digitale operative Resilienz im Finanzsektor |
Cybersicherheit essenzieller und wichtiger Einrichtungen |
| Typische Adressaten |
Finanzunternehmen wie Banken, Versicherer, Zahlungsdienstleister, Wertpapierfirmen und weitere beaufsichtigte Finanzakteure |
Organisationen in kritischen und wichtigen Sektoren, unter anderem Energie, Gesundheit, Verkehr, digitale Infrastruktur, öffentliche Verwaltung und bestimmte IKT-Dienste |
| Drittparteien |
Sehr konkrete Anforderungen an IKT-Drittparteien, Vertragsrechte, Überwachung, Register und Exit-Planung |
Lieferketten- und Dienstleisterrisiken als Teil des Risikomanagements; direkte Regulierung nur, wenn der Anbieter selbst in den NIS2-Anwendungsbereich fällt |
| Aufsicht |
Finanzaufsicht und europäisch koordinierte Aufsichtsmechanismen, insbesondere für kritische IKT-Drittdienstleister |
Nationale zuständige Behörden und nationale Durchsetzung |
| Zeitliche Einordnung |
In Kraft seit 2023, anwendbar seit Januar 2025 |
In Kraft seit 2023, nationale Umsetzung bis Oktober 2024 vorgesehen |
Gilt DORA, NIS2, beides oder keines?
Die belastbare Einstufung beginnt nicht mit der Frage, welches Regelwerk strenger wirkt, sondern mit Sektor, Rolle und Niederlassungsbezug. Ein beaufsichtigtes Finanzunternehmen in der EU fällt typischerweise in den DORA-Anwendungsbereich. Eine Einrichtung außerhalb des Finanzsektors muss prüfen, ob sie nach nationalem NIS2-Umsetzungsrecht als essenziell oder wichtig gilt. Ein IKT-, Cloud- oder Managed-Service-Provider muss zusätzlich bewerten, ob er selbst unter NIS2 fällt und ob seine Leistungen für Finanzunternehmen DORA-relevant sind.
Ein einfaches Beispiel zeigt die Abgrenzung. Eine Bank muss DORA für ihr IKT-Risikomanagement, ihre Vorfallprozesse, Resilienztests und ihre IKT-Drittparteiensteuerung berücksichtigen. Ein Rechenzentrumsbetreiber kann unter NIS2 fallen, weil digitale Infrastruktur erfasst ist, und zugleich DORA-relevante Vertrags- und Kontrollanforderungen erfüllen müssen, wenn er kritische Services für Finanzunternehmen erbringt. Ein internationaler Softwareanbieter mit EU-Kunden sollte außerdem prüfen, ob EU-Tochtergesellschaften, Niederlassungen oder Dienstleistungsketten zusätzliche Pflichten auslösen.
Die Lex-specialis-Perspektive ist dabei wichtig. Für beaufsichtigte Finanzunternehmen ist DORA in Fragen des IKT-Risikomanagements regelmäßig der speziellere Rahmen. Das bedeutet jedoch nicht, dass NIS2 nie relevant ist. Je nach nationaler Umsetzung und Unternehmensstruktur können horizontale Pflichten, sektorbezogene Meldewege oder Anforderungen an Lieferketten-Sicherheit weiterhin eine Rolle spielen. Doppelmeldungen und Zuständigkeiten sollten deshalb früh mit den einschlägigen Behörden, internen Rechtsfunktionen und Aufsichtsteams abgestimmt werden.
In der Praxis hilft ein vierteiliger Entscheidungsrahmen: Zuerst wird die juristische Einheit betrachtet, nicht nur die Unternehmensgruppe. Danach folgt die Sektorzuordnung nach DORA und nationalem NIS2-Recht. Anschließend wird die Rolle in der Wertschöpfungskette geprüft, insbesondere als Finanzunternehmen, Betreiber kritischer Dienste, digitaler Infrastrukturanbieter oder IKT-Drittanbieter. Zum Schluss werden Meldewege, Vertragsketten und Aufsichtskontakte je Land dokumentiert.
Wo sich die Pflichten überschneiden
Die Überschneidung liegt weniger in identischen Formulierungen als in den operativen Fähigkeiten, die Unternehmen aufbauen müssen. Beide Regelwerke verlangen, dass Cyber- und IKT-Risiken nicht nur technisch behandelt werden. Sie müssen in Governance, Risikomanagement, Lieferantensteuerung, Business Continuity und Incident Response verankert sein.
Besonders deutlich wird das bei Vorfällen. NIS2 verlangt bei erheblichen Vorfällen eine Frühwarnung innerhalb von 24 Stunden, eine ausführlichere Meldung innerhalb von 72 Stunden und in der Regel einen Abschlussbericht innerhalb eines Monats. DORA sieht ebenfalls ein gestuftes Meldewesen für schwerwiegende IKT-bezogene Vorfälle vor; die konkreten Formate und Detailanforderungen werden über technische Regulierungs- und Durchführungsstandards konkretisiert. Daraus folgt ein praktischer Punkt: Wer beide Regime bedienen muss, braucht keinen zweiten Incident-Prozess, sondern einen integrierten Meldeprozess mit klaren Schwellenwerten, Eskalationsmatrizen und behördenspezifischen Vorlagen.
Auch die Governance überschneidet sich. NIS2 betont die Verantwortung der Leitungsorgane und sieht je nach nationaler Umsetzung persönliche Konsequenzen, Aufsichtsmaßnahmen und Sanktionen vor. DORA verlangt im Finanzsektor ebenfalls eine klare Einbindung des Leitungsorgans in IKT-Risiken und digitale operative Resilienz. Schulungsnachweise, Beschlussprotokolle, Risikoappetit, Krisenübungen und regelmäßige Berichte werden dadurch zu wichtigen Belegen, nicht zu administrativen Nebensachen.
Bei Drittparteien ist DORA besonders konkret. Finanzunternehmen müssen ihre IKT-Dienstleister systematisch steuern, Informationen in Registern pflegen und Vertragsrechte zu Zugang, Prüfung, Audit, Unterbeauftragung, Kündigung und Ausstieg angemessen regeln. Viele Organisationen entdecken hier die größte Umsetzungslücke: Standardverträge enthalten oft nicht die nötigen Rechte, Exit-Szenarien wurden selten getestet, und Unterauftragnehmerketten sind nicht vollständig transparent. NIS2 verlangt ebenfalls Lieferketten-Risikomanagement, reguliert aber nicht automatisch jeden Lieferanten direkt.
Wie ein gemeinsames Betriebsmodell aussehen kann
Unternehmen, die DORA und NIS2 parallel berücksichtigen müssen, profitieren von einem Zielbetriebsmodell, das regulatorische Unterschiede sichtbar macht, aber operative Fähigkeiten bündelt. Der Fehler liegt oft darin, zwei Programme nebeneinander aufzubauen: eines für Finanzaufsicht, eines für nationale Cybersicherheitsbehörden. Das erzeugt doppelte Kontrollen, widersprüchliche Klassifizierungen und Unsicherheit im Krisenfall.
Ein tragfähiger Ansatz beginnt mit einer gemeinsamen Kontrollbibliothek. Jede Kontrolle wird den relevanten DORA- und NIS2-Anforderungen zugeordnet, aber nur einmal operativ umgesetzt. Ein Incident-Response-Playbook enthält dann beispielsweise gemeinsame Schritte für Erkennung, Klassifizierung, Krisenstab, Beweissicherung und Kommunikation, ergänzt um Meldefristen und Formatanforderungen je Rechtsgrundlage und Behörde.
Das gleiche Prinzip gilt für Lieferanten. Ein zentraler Prozess für IKT- und Sicherheitsrisiken sollte erfassen, welche Dienstleister kritisch sind, welche Verträge DORA-relevante Rechte enthalten müssen, welche NIS2-Lieferkettenrisiken bestehen und welche Exit- oder Substitutionspläne realistisch getestet werden können. Beschaffung, Recht, Informationssicherheit und Risikomanagement sollten dabei nicht nacheinander arbeiten, sondern dieselben Daten verwenden.
Resilienztests werden ebenfalls wirksamer, wenn sie nicht nur als technische Übung verstanden werden. Ein gutes Szenario prüft gleichzeitig Erkennung, Entscheidungswege, Meldefähigkeit, Kundenkommunikation, Dienstleistersteuerung und Wiederanlauf. Dadurch entstehen Nachweise, die gegenüber internen Gremien und Aufsichtsbehörden belastbarer sind als isolierte technische Testergebnisse.
Welche Fehler Unternehmen häufig vermeiden sollten
Ein verbreiteter Fehler ist die Annahme, dass die Einordnung auf Gruppenebene ausreicht. Regulierung knüpft jedoch häufig an einzelne juristische Einheiten, Tätigkeiten, Niederlassungen, Kundenbeziehungen und nationale Schwellenwerte an. Internationale Gruppen sollten deshalb prüfen, welche EU-Gesellschaft welchen Dienst erbringt, welche Behörde zuständig ist und wie Vorfälle über Ländergrenzen hinweg eskaliert werden.
Ein zweiter Fehler besteht darin, die Meldefristen erst während eines Vorfalls zu klären. Gerade bei NIS2 sind die ersten 24 und 72 Stunden organisatorisch anspruchsvoll, weil technische Fakten, rechtliche Bewertung, Kommunikationsfreigaben und Managemententscheidungen gleichzeitig entstehen müssen. Unter DORA kommen Klassifizierungslogik und aufsichtsbezogene Formate hinzu. Wer die Entscheidungsmatrix erst im Ernstfall baut, verliert wertvolle Zeit.
Ein dritter Fehler liegt in zu engen Projektteams. DORA und NIS2 betreffen Informationssicherheit, aber auch Recht, Compliance, Einkauf, Datenschutz, Business Continuity, Unternehmenskommunikation und Vorstand beziehungsweise Geschäftsführung. Wenn die Umsetzung als rein technische Aufgabe geführt wird, bleiben Vertragsrechte, Leitungsnachweise und behördliche Kommunikationswege häufig lückenhaft.
FAQ zu DORA vs. NIS2
Muss ein Finanzunternehmen zusätzlich zu DORA auch NIS2 beachten?
Das hängt von der konkreten nationalen Umsetzung, der juristischen Einheit und den Tätigkeiten ab. Für IKT-Risikofragen ist DORA bei beaufsichtigten Finanzunternehmen der speziellere Rahmen, doch NIS2 kann je nach Struktur und Mitgliedstaat weitere horizontale Pflichten oder Meldeanforderungen berühren.
Gelten die NIS2-Meldefristen von 24 Stunden und 72 Stunden auch für DORA?
Nein, sie sollten nicht einfach übertragen werden. NIS2 arbeitet mit Frühwarnung, Folgemeldung und Abschlussbericht. DORA sieht ebenfalls ein gestuftes Meldewesen für schwerwiegende IKT-bezogene Vorfälle vor, wird aber über eigene technische Standards und Aufsichtsformate konkretisiert.
Reguliert NIS2 alle Lieferanten eines betroffenen Unternehmens direkt?
Nicht automatisch. NIS2 verlangt, dass betroffene Einrichtungen Lieferketten- und Dienstleisterrisiken steuern. Ein Lieferant fällt aber nur dann direkt unter NIS2, wenn er selbst die einschlägigen Kriterien des nationalen Umsetzungsrechts erfüllt.
Warum sind IKT-Verträge unter DORA so wichtig?
DORA verlangt bei IKT-Drittdienstleistungen deutlich strukturierte Rechte und Pflichten, unter anderem zu Audit, Zugang, Unterbeauftragung, Kündigung und Ausstieg. Für viele Finanzunternehmen bedeutet das, bestehende Vertragsmuster, Dienstleisterregister und Exit-Tests zu überarbeiten.
Was jetzt sinnvoll ist
Der entscheidende Schritt ist eine saubere Anwendungsanalyse, bevor Kontrollkataloge und Projekte gestartet werden. Unternehmen sollten festhalten, welche juristischen Einheiten unter DORA, NIS2, beide Regelwerke oder keines davon fallen, welche Behörden zuständig sind und welche Vorfallkategorien welche Meldewege auslösen. Diese Analyse sollte regelmäßig aktualisiert werden, weil nationale NIS2-Umsetzungen und Behördenleitlinien praktische Details verändern können.
Danach lohnt sich die Bündelung. Ein integriertes Programm für Governance, Incident Reporting, Drittparteienmanagement, Resilienztests und Managementnachweise reduziert Doppelarbeit und schafft klare Verantwortlichkeiten. Readynez kann mit dem DORA Essentials Training dabei helfen, die Struktur und die fünf zentralen Säulen von DORA besser in die eigene Finanz- und IKT-Praxis einzuordnen.
Die wichtigste Schlussfolgerung lautet: DORA und NIS2 sollten weder vermischt noch getrennt in Silos umgesetzt werden. Wer ihre Unterschiede respektiert und die gemeinsamen operativen Fähigkeiten zusammenführt, schafft eine belastbarere Grundlage für Aufsicht, Krisenmanagement und digitale Resilienz.
