NIS2 vs. DORA: Was ist der Unterschied und welche Regulierung trifft mich?

Key Takeaways

• NIS2 ist eine EU-Richtlinie mit breitem Geltungsbereich — sie trifft Unternehmen aus zehn kritischen Sektoren ab definierten Größenschwellen.
• DORA ist eine EU-Verordnung, die ausschließlich den Finanzsektor reguliert und seit Januar 2025 direkt gilt — ohne nationale Umsetzung.
• Finanzunternehmen müssen beide Regelwerke beachten; DORA geht als lex specialis vor, schließt NIS2 aber nicht vollständig aus.
• Wer seinen Geltungsbereich nicht kennt, riskiert empfindliche Bußgelder — und im Ernstfall die persönliche Haftung der Geschäftsführung.

Das Regulierungschaos hat Methode

Seit 2023 reden alle über NIS2. Seit Anfang 2025 ist zusätzlich DORA in aller Munde. Beide Abkürzungen landen regelmäßig auf den Schreibtischen von IT-Leitern und Geschäftsführern — oft ohne ausreichende Erklärung, warum eigentlich und ob beide Vorschriften überhaupt relevant sind.

Das führt zu zwei typischen Fehlern: Entweder ignoriert man beide als "Brüsseler Bürokratie", oder man behandelt sie als dasselbe Regelwerk und verpasst wichtige Unterschiede. Beide Fehler haben reale Konsequenzen. Dieser Artikel sortiert die Fakten: Was regeln NIS2 und DORA jeweils, wen treffen sie, wo überschneiden sie sich — und was sollten Sie jetzt konkret tun?

Was ist NIS2?

NIS2 steht für die EU-Richtlinie 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union. Sie löste die ursprüngliche NIS-Richtlinie von 2016 ab und wurde im Januar 2023 in Kraft gesetzt. Als Richtlinie — nicht Verordnung — musste sie von den EU-Mitgliedstaaten in nationales Recht umgesetzt werden. Deutschland hat dies mit dem NIS2UmsuCG getan, das seit Oktober 2024 gilt.

Geltungsbereich: Wer fällt unter NIS2?

NIS2 unterscheidet zwei Kategorien von Unternehmen:

Wesentliche Einrichtungen (Essential Entities) sind Unternehmen in folgenden Sektoren:

• Energie (Strom, Gas, Öl, Fernwärme)
• Transport (Luft, Bahn, See, Straße)
• Bankwesen und Finanzmarktinfrastrukturen
• Gesundheitswesen
• Trinkwasser und Abwasser
• Digitale Infrastruktur (Cloud-Anbieter, Rechenzentren, DNS-Resolver, TLD-Registrare)
• IKT-Dienste (Managed Service Provider, Managed Security Service Provider)
• Öffentliche Verwaltung
• Raumfahrt

Größenschwelle wesentliche Einrichtungen: mindestens 250 Mitarbeiter oder mindestens 50 Mio. EUR Jahresumsatz und 43 Mio. EUR Bilanzsumme.

Wichtige Einrichtungen (Important Entities) umfassen:

• Post- und Kurierdienste
• Abfallwirtschaft
• Chemiebranche
• Lebensmittelproduktion und -handel
• Verarbeitendes Gewerbe und Maschinenbau (für bestimmte Produktkategorien wie Medizinprodukte und Fahrzeuge)
• Digitale Anbieter (Online-Marktplätze, Suchmaschinen, soziale Netzwerke)
• Forschungseinrichtungen

Größenschwelle wichtige Einrichtungen: mindestens 50 Mitarbeiter und mindestens 10 Mio. EUR Jahresumsatz.

Ausnahmen gelten für Kleinstunternehmen (unter 10 MA) und kleine Unternehmen (unter 50 MA und unter 10 Mio. EUR Umsatz) — außer sie betreiben nachweislich kritische Infrastruktur oder sind anderweitig explizit einbezogen.

Was verlangt NIS2 konkret?

NIS2 formuliert Mindestanforderungen an die Cybersicherheit in neun Bereichen:

1. Risikoanalyse und Sicherheitspolitik — dokumentierte Sicherheitsrichtlinien, regelmäßige Risikobeurteilungen
2. Incident-Management — Meldepflichten: Erstmeldung innerhalb 24 Stunden, Folgebericht nach 72 Stunden, Abschlussbericht nach einem Monat
3. Business Continuity — Backup-Strategien, Notfallpläne, Krisenmanagement
4. Lieferkettensicherheit — Bewertung und Überwachung von Drittanbietern und Dienstleistern
5. Sicherheit in der Systementwicklung — Vulnerability Management, Patch-Management
6. Schulungen — Security-Awareness für alle Mitarbeiter, verpflichtende Schulungen für die Geschäftsführung
7. Kryptographie — Einsatz von Verschlüsselung wo angemessen
8. Zugriffskontrolle und Authentifizierung — MFA, Least Privilege, Zugangskontrollen
9. Sicherheit von Kommunikationskanälen — gesicherte Sprach-, Video- und Textkommunikation

Bußgelder: bis zu 10 Mio. EUR oder 2 % des globalen Jahresumsatzes für wesentliche Einrichtungen, bis zu 7 Mio. EUR oder 1,4 % für wichtige Einrichtungen. Neu und besonders relevant: persönliche Haftung der Geschäftsführung bei nachgewiesener Pflichtverletzung — das ist keine theoretische Drohung, sondern Teil des deutschen NIS2UmsuCG.

Was ist DORA?

DORA steht für den Digital Operational Resilience Act — EU-Verordnung 2022/2554. Als Verordnung gilt DORA direkt in allen EU-Mitgliedstaaten, ohne nationale Umsetzung durch den Gesetzgeber. Sie ist seit dem 17. Januar 2025 vollständig anwendbar.

DORA hat einen fundamentalen Unterschied zu NIS2: Sie gilt ausschließlich für den Finanzsektor.

Geltungsbereich: Wer fällt unter DORA?

DORA erfasst ein breites Spektrum an Finanzunternehmen:

• Kreditinstitute (Banken jeder Größe)
• Zahlungsinstitute und E-Geld-Institute
• Wertpapierfirmen und Investmentgesellschaften
• Versicherungs- und Rückversicherungsunternehmen
• Betreiber von Handelsplätzen
• Krypto-Asset-Dienstleister (gemäß MiCA-Verordnung)
• Ratingagenturen
• Anbieter von Datenmeldediensten
• IKT-Drittdienstleister für Finanzunternehmen — das ist der entscheidende Punkt für IT-Dienstleister außerhalb des Finanzsektors

Gerade dieser letzte Punkt überrascht viele: Ein Softwareentwickler oder Cloud-Anbieter, der Banken oder Versicherungen mit kritischen Diensten beliefert, kann von den europäischen Aufsichtsbehörden als kritischer IKT-Drittdienstleister eingestuft werden — auch wenn er selbst kein Finanzunternehmen ist. Die Einstufung erfolgt durch EBA, ESMA und EIOPA nach definierten Kriterien und zieht direkte Beaufsichtigung nach sich.

Was verlangt DORA konkret?

DORA gliedert sich in fünf Säulen:

1. IKT-Risikomanagement (Art. 5–16)

Ein vollständiges, dokumentiertes IKT-Risikomanagement-Framework ist Pflicht — kein isoliertes Dokument, sondern integriert in die Unternehmensstrategie. Das umfasst Asset-Inventar, laufende Risikoanalyse, Schutzmaßnahmen und kontinuierliche Überwachung aller kritischen Systeme und Prozesse.

2. Management, Klassifizierung und Berichterstattung von IKT-Vorfällen (Art. 17–23)

Detaillierte Meldepflichten mit spezifischen Klassifizierungskriterien für Finanzdienstleister: betroffene Kundenzahl, Transaktionsvolumen, Auswirkungen auf andere Institute, geografische Reichweite. Die Meldeschwellen sind in den DORA-RTS präzise definiert und unterscheiden sich von den NIS2-Schwellen.

3. Tests der digitalen operationalen Resilienz (Art. 24–27)

Jährliche, risikobasierte Tests sind für alle DORA-Verpflichteten Pflicht. Für bedeutende Institute zusätzlich: verpflichtende Threat-Led Penetration Tests (TLPT) alle drei Jahre, durchgeführt von zugelassenen externen Testern nach dem TIBER-EU-Framework. Diese Tests simulieren reale Angreifergruppen und sind erheblich aufwändiger als klassische Penetrationstests.

4. Management des IKT-Drittparteienrisikos (Art. 28–44)

Strenge Anforderungen an Verträge mit IKT-Dienstleistern: Exit-Strategien, Auditrechte, Mindestsicherheitsanforderungen, vollständiges Register aller IKT-Drittdienstleister mit Risikoklassifizierung. Finanzunternehmen müssen sicherstellen, dass ihre Dienstleister vertraglich verpflichtet sind, bei Sicherheitsvorfällen zu melden.

5. Vereinbarungen über den Austausch von Informationen (Art. 45)

Freiwilliger, aber regulatorisch geförderter Austausch von Bedrohungsinformationen (Threat Intelligence) zwischen Finanzunternehmen — ein Element, das bei NIS2 nicht in dieser Form vorgesehen ist.

NIS2 vs. DORA: Die wichtigsten Unterschiede im Vergleich

Merkmal	NIS2	DORA
Rechtsform	EU-Richtlinie	EU-Verordnung
Nationale Umsetzung	Ja (z.B. NIS2UmsuCG in DE)	Nein (direkt anwendbar)
Geltungsbereich	Multisektoral (10+ Sektoren)	Nur Finanzsektor
Fokus	Cybersicherheits-Mindeststandards	Operative IT-Resilienz
In Kraft seit	Oktober 2024 (Deutschland)	Januar 2025 (EU-weit)
Größenschwellen	Ja (MA-Zahl und Umsatz)	Weitgehend sektor-definiert
Verpflichtende Pentests (TLPT)	Nicht explizit gefordert	Ja, für bedeutende Institute
Aufsicht über IKT-Dritte	Indirekt über Lieferketten-Pflichten	Direkt durch EBA/ESMA/EIOPA
Bußgelder	Bis 10 Mio. EUR / 2 % Umsatz	Bis 1 % des weltweiten Tagesumsatzes
Meldestelle (Deutschland)	BSI	BaFin

Überschneidung: Was gilt, wenn beide zutreffen?

Finanzunternehmen, die groß genug sind, um unter NIS2 zu fallen — insbesondere Banken und Finanzmarktinfrastrukturen als wesentliche Einrichtungen — stehen vor einer Doppelregulierung. Der EU-Gesetzgeber hat dies antizipiert und in Art. 4 Abs. 2 DORA klargestellt: DORA geht als lex specialis vor, soweit es um IKT-bezogene Anforderungen geht.

Konkret bedeutet das: Ein Kreditinstitut, das DORA vollständig einhält, gilt für die IKT-Risikomanagement-Anforderungen auch als NIS2-konform. DORA-Konformität schließt NIS2-Meldepflichten jedoch nicht automatisch aus — hier müssen beide Regimes parallel beachtet werden, da sich die Meldewege und Schwellen unterscheiden.

Für die Praxis:

• Banken und Versicherungen → primär DORA, ergänzend NIS2 für Bereiche außerhalb des IKT-Risikomanagements (Schulungen, physische Sicherheit)
• IKT-Dienstleister für Banken → DORA (als kritischer Drittanbieter) und ggf. NIS2 (je nach eigener Größe und Sektor)
• Produzierendes Gewerbe, Energie, Gesundheit, Transport → ausschließlich NIS2
• Kleine Zahlungsdienstleister unter NIS2-Schwellenwerten → ausschließlich DORA

Welche Regulierung trifft mein Unternehmen?

Folgen Sie diesem Entscheidungsbaum:

Ist Ihr Unternehmen im Finanzsektor tätig (Bank, Versicherung,
Zahlungsdienstleister, Wertpapierfirma, Krypto-Anbieter)?
├── Ja → DORA ist anwendbar
│   └── Sind Sie groß genug für NIS2 (wesentliche Einrichtung)?
│       ├── Ja → Beide Regelwerke; DORA als lex specialis
│       └── Nein → Primär DORA
└── Nein
    ├── Liefern Sie kritische IKT-Dienste an Finanzunternehmen?
    │   ├── Ja → DORA (als IKT-Drittdienstleister) + ggf. NIS2
    │   └── Nein → Weiter prüfen
    └── Fallen Sie unter einen der NIS2-Sektoren?
        ├── Ja + Schwellenwerte erfüllt → NIS2
        └── Nein → Derzeit keine direkte Pflicht aus NIS2/DORA

Achtung: "Keine direkte Pflicht" ist kein Freifahrtschein. Lieferketten-Anforderungen von NIS2- und DORA-regulierten Kunden erzeugen indirekte Anforderungen — auch ohne eigene regulatorische Einstufung. Wer als Zulieferer von wesentlichen Einrichtungen tätig ist, muss damit rechnen, dass seine Kunden Sicherheitsnachweise, Auditrechte oder Vertragserweiterungen einfordern.

Praktische Hinweise für IT-Verantwortliche

Schritt 1: Scoping-Analyse durchführen

Klären Sie zunächst intern: In welchem Sektor ist das Unternehmen tätig? Welche Umsatz- und Mitarbeiterzahlen gelten? Werden Finanzunternehmen mit IKT-Diensten beliefert? Diese drei Fragen bestimmen Ihren Geltungsbereich zuverlässiger als jeder externe Berater ohne diese Grundinformationen.

Schritt 2: Gap-Analyse gegen das relevante Regelwerk

Sobald der Geltungsbereich feststeht, folgt ein Abgleich des Ist-Stands gegen die konkreten Anforderungen. Für NIS2 in Deutschland bieten das BSI und der VdS konkrete Prüflisten (VdS 10000). Für DORA haben EBA, ESMA und EIOPA detaillierte Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS) veröffentlicht — diese sind verbindlich und präzisieren die Verordnungstexte erheblich.

Schritt 3: Meldewege und Incident-Response aufbauen

Sowohl NIS2 als auch DORA verlangen strukturierte Meldeprozesse mit engen Zeitfenstern. Unter NIS2 meldet man in Deutschland an das BSI, unter DORA an die BaFin. Stellen Sie sicher, dass klare interne Eskalationspfade existieren — Ersterkennung, Analyse, Meldung, externe Kommunikation — bevor ein Vorfall eintritt. Ein Incident-Response-Plan, der erst nach einem Angriff geschrieben wird, nützt nichts.

Schritt 4: Lieferkette und Drittanbieter dokumentieren

In der Praxis wird das Drittanbieter-Management am häufigsten unterschätzt. Erstellen Sie ein vollständiges Register Ihrer kritischen IKT-Dienstleister: Cloud-Provider, Managed Services, Softwarehersteller, Telekommunikationsanbieter. Prüfen Sie pro Dienstleister: Bestehen Auditrechte? Gibt es SLAs mit Sicherheitsbezug? Sind Datenschutz und Informationssicherheit vertraglich verankert? Gibt es eine Exit-Strategie, wenn der Anbieter ausfällt oder insolvent wird?

Dieses Register ist sowohl unter NIS2 (Lieferkettensicherheit) als auch unter DORA (IKT-Drittparteienregister) eine explizite Anforderung — und es ist erfahrungsgemäß das Erste, was Auditoren anfordern.

Schritt 5: Kontinuierliches Monitoring statt Einmal-Projekt

Beide Regelwerke lassen sich nicht mit einmaligen Projekten erledigen. NIS2 verlangt regelmäßige Risikoanalysen, DORA verlangt laufende Überwachung aller IKT-Systeme. Das setzt eine technische Infrastruktur voraus, die Logs zentralisiert, Anomalien erkennt und Vorfälle dokumentiert — nicht nur für den Auditfall, sondern für den Betrieb.

Fazit: Zwei Regelwerke, ein gemeinsames Ziel

NIS2 und DORA verfolgen dasselbe übergeordnete Ziel: die digitale Widerstandsfähigkeit europäischer Unternehmen zu stärken. Sie unterscheiden sich im Geltungsbereich, in der Tiefe der Anforderungen und in der Rechtsform. Für die meisten deutschen KMU außerhalb des Finanzsektors ist NIS2 das relevante Regelwerk. Für Finanzunternehmen ist DORA die primäre Pflicht — ergänzt durch NIS2 dort, wo keine lex specialis greift. Und für IT-Dienstleister, die Finanzunternehmen beliefern, kann DORA auch ohne eigene Finanztätigkeit relevant werden.

Die entscheidende Erkenntnis für IT-Verantwortliche: Compliance ist kein Zustand, den man einmal erreicht. Beide Regelwerke verlangen kontinuierliches Monitoring, strukturiertes Incident-Response und laufende Dokumentation. Eine SIEM-Plattform, die Logs aus Microsoft 365, Azure AD, Endpunkten und Netzwerkkomponenten zentralisiert und auswertet, ist dabei keine Kür — sie ist die technische Grundlage dafür, Meldepflichten einhalten und Auditoren gegenüber Nachweise führen zu können.

Vyrex Security betreibt ein managed SIEM/SOC speziell für mittelständische Unternehmen, die NIS2- oder DORA-Anforderungen nicht mit internen Ressourcen allein stemmen können. Ob Sie Ihre Meldeprozesse absichern, Ihre Log-Infrastruktur für BSI- oder BaFin-Audits aufbereiten oder einen strukturierten Incident-Response-Prozess aufbauen müssen — wir liefern technische Umsetzung, keine Beratungsfolien.