Auf Basis der Forschungsarbeiten von Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann

Es ist 3 Uhr morgens. Die IT-Abteilung stellt fest, dass Angreifer seit Stunden aktiv in Unternehmenssysteme eingedrungen sind. Der Vorstand wird geweckt. Und dann beginnt eine Frage, die in diesem Moment niemand so genau beantworten kann: Wen müssen wir eigentlich wann informieren – und mit welcher Frist?

In der Praxis ist genau das die Situation, in der viele Unternehmen merken, dass sie die Meldepflichten des europäischen Cybersicherheitsrechts nie wirklich durchdrungen haben. Denn mit DORA, NIS-2 und dem Cyber Resilience Act (CRA) existieren heute drei verschiedene EU-Regelwerke, die alle Meldepflichten bei Cybervorfällen vorsehen – mit unterschiedlichen Fristen, unterschiedlichen Adressaten, unterschiedlichen Behörden und unterschiedlichen Auslösern. Teichmann hat diese komplexe Gemengelage in mehreren wissenschaftlichen Beiträgen systematisch aufgearbeitet. Die Erkenntnisse sind für jedes Unternehmen relevant, das unter mehr als eines dieser Regelwerke fällt.

Warum es drei verschiedene Melderegime gibt

Die Entstehung paralleler Meldepflichten ist kein Versehen des europäischen Gesetzgebers, sondern Ausdruck dreier unterschiedlicher Regulierungslogiken.

NIS-2 richtet sich an Betreiber – also Unternehmen, die kritische Dienste und Infrastrukturen betreiben. Es geht darum, dass Störungen dieser Dienste frühzeitig den Aufsichtsbehörden bekannt werden, damit diese systemische Risiken einschätzen und koordinieren können. NIS-2 ist sektorübergreifend und betreiberbezogen (Teichmann, Neue Cybersicherheitspflichten durch das NIS-2-Umsetzungsgesetz, K&R 2026, S. 26–32).

DORA richtet sich an Finanzunternehmen – also an einen spezifischen Sektor mit besonderer Systemrelevanz. Die Logik ist dieselbe wie bei NIS-2, aber die Anforderungen sind schärfer und detaillierter. Finanzausfälle können das gesamte Wirtschaftssystem destabilisieren, weshalb der Gesetzgeber hier strengere Maßstäbe setzt (Teichmann, Digital Operational Resilience Act – EU-weit einheitliche IT-Sicherheitsregeln für Finanzinstitute, BB 2025, S. 2760–2770).

Der CRA hingegen richtet sich an Hersteller vernetzter Produkte – also nicht an Betreiber, sondern an die Produzenten der Technologie selbst. Wenn eine Schwachstelle in einem Produkt aktiv ausgenutzt wird, muss der Hersteller dies melden, damit die Behörden reagieren und andere Nutzer desselben Produkts warnen können (Teichmann, Cyber Resilience Act – Produktsicherheit, SBOM und Herstellerhaftung entlang des Lebenszyklus, CCZ 2025, S. 165–171).

Das Problem entsteht, wenn dasselbe Unternehmen mehrere Rollen gleichzeitig ausfüllt – was in der Praxis sehr häufig vorkommt. Eine Bank, die eigene Software entwickelt und betreibt, kann gleichzeitig unter DORA als Finanzunternehmen, unter NIS-2 als wesentliche Einrichtung und unter dem CRA als Hersteller fallen. In diesem Moment laufen drei verschiedene Meldepflichten mit unterschiedlichen Fristen parallel.

Die Meldepflichten im Detail: Wer meldet was wann an wen

NIS-2: Das dreistufige Standardmodell. NIS-2 hat das dreistufige Meldeverfahren etabliert, das heute als Referenzmodell für das gesamte europäische Cybersicherheitsrecht gilt. Innerhalb von 24 Stunden nach Bekanntwerden eines erheblichen Vorfalls muss eine Frühwarnung an das BSI erfolgen. Diese Erstmeldung muss noch keine vollständige Analyse enthalten; es genügt die Information, dass ein erheblicher Vorfall stattgefunden hat und eine erste Einschätzung, ob es sich möglicherweise um eine böswillige Handlung handelt. Innerhalb von 72 Stunden folgt die eigentliche Vorfallsmeldung mit einer ersten Bewertung. Spätestens einen Monat nach der Erstmeldung ist ein Abschlussbericht zu erstatten. Ein Vorfall gilt als erheblich, wenn er schwerwiegende Betriebsstörungen oder erhebliche finanzielle Verluste verursacht hat oder verursachen kann – der Maßstab ist also die potenzielle Auswirkung, nicht erst der eingetretene Schaden (Teichmann, Die neue 24-Stunden-Meldepflicht für Cyberangriffe nach ISG, Jusletter, 29. September 2025).

DORA: Schärfer, schneller, finanzspezifisch. DORA übernimmt das dreistufige Grundmodell, verschärft es aber in mehreren Punkten. Die entscheidende Verschärfung betrifft die Erstfrist: Binnen vier Stunden nach Klassifizierung des Vorfalls als schwerwiegend muss eine Erstmeldung an die BaFin erfolgen – nicht erst nach 24 Stunden. Dies setzt voraus, dass das Finanzunternehmen über effiziente interne Klassifizierungsprozesse verfügt, die eine solche Einschätzung in kurzer Zeit ermöglichen. DORA definiert Schwellenwerte anhand spezifischer finanzieller Kriterien: Anzahl und Anteil betroffener Kunden und Transaktionen, geografische Auswirkungen, Ausfalldauer, Reputationsschäden und finanzielle Verluste. Innerhalb von 72 Stunden folgt die Zwischenmeldung, innerhalb eines Monats der Abschlussbericht – analog zu NIS-2. Da DORA als lex specialis gegenüber NIS-2 gilt, ersetzt die BaFin-Meldung grundsätzlich die BSI-Meldung; beide Behörden koordinieren untereinander (Teichmann, Harmonisierung von Incident-Reporting-Meldefristen nach DORA, NIS2 und CRA, ZRFC 2026, S. 81–88).

CRA: Eine völlig andere Logik. Der CRA führt eine Meldepflicht ein, die strukturell von NIS-2 und DORA abweicht. Es geht nicht um Betriebsstörungen, sondern um Produktschwachstellen. Nach Art. 14 CRA müssen Hersteller vernetzter Produkte aktiv ausgenutzte Schwachstellen binnen 24 Stunden nach Kenntnisnahme an das BSI und parallel an die europäische Cybersicherheitsbehörde ENISA melden. Innerhalb von 72 Stunden folgt eine vollständigere Meldung, innerhalb von 14 Tagen – nicht einem Monat wie bei NIS-2 und DORA – ein Abschlussbericht. Der entscheidende strukturelle Unterschied: CRA-Meldungen betreffen Schwachstellen im Produkt, nicht Vorfälle im eigenen Betrieb. Ein Hersteller muss also nicht melden, weil er selbst Opfer eines Angriffs wurde, sondern weil sein Produkt das Einfallstor für einen Angriff auf jemand anderen war oder sein könnte (Teichmann, CCZ 2025, S. 165–171).

Das Koordinationsproblem: Wenn alle drei Regime gleichzeitig gelten

Die eigentliche Herausforderung entsteht in Konstellationen, in denen ein Unternehmen mehreren Regimen gleichzeitig unterliegt. Das klassische Beispiel ist ein Softwareunternehmen, das Sicherheitslösungen für Banken entwickelt und selbst als kritischer IT-Dienstleister im Finanzsektor tätig ist. Bei einem schwerwiegenden Sicherheitsvorfall kann dieses Unternehmen gleichzeitig betroffen sein als NIS-2-Einrichtung mit Meldepflicht ans BSI innerhalb von 24 Stunden, als CRA-Hersteller mit Meldepflicht über eine aktiv ausgenutzte Produktschwachstelle innerhalb von 24 Stunden an BSI und ENISA, und als IKT-Drittdienstleister unter DORA mit der Pflicht, die betroffenen Finanzunternehmen zu informieren, die ihrerseits binnen vier Stunden an die BaFin melden müssen (Teichmann, ZRFC 2026, S. 81–88).

Was identisch ist – und was nicht

Der Auslöser unterscheidet sich fundamental. NIS-2 löst die Meldepflicht aus bei einem erheblichen Sicherheitsvorfall, der den Betrieb stört. DORA löst sie aus bei einem schwerwiegenden IKT-Vorfall mit konkreten finanziellen Auswirkungen. Der CRA löst sie aus bei einer aktiv ausgenutzten Produktschwachstelle – unabhängig davon, ob der Hersteller selbst operativ betroffen ist.

Die Erstfrist variiert: 24 Stunden unter NIS-2 und CRA, vier Stunden unter DORA. Für Finanzunternehmen ist die DORA-Frist damit die schärfste – und sie beginnt nicht beim Bekanntwerden des Vorfalls, sondern beim Zeitpunkt der internen Klassifizierung als schwerwiegend.

Die Meldebehörde ist unterschiedlich: NIS-2 und CRA melden ans BSI, DORA an die BaFin. CRA-Meldungen gehen zusätzlich an ENISA auf europäischer Ebene. Der Abschlussbericht ist nach NIS-2 und DORA nach einem Monat fällig, nach CRA bereits nach 14 Tagen. Und der Inhalt unterscheidet sich: NIS-2 und DORA fokussieren auf den Betriebsvorfall, der CRA auf die Produktschwachstelle und den Patch-Status.

Die DSGVO als vierte Schicht

Neben DORA, NIS-2 und CRA existiert noch eine vierte Meldepflicht, die bei vielen Cybervorfällen greift: die Datenschutz-Grundverordnung. Wenn personenbezogene Daten betroffen sind – was bei den meisten Angriffen auf Unternehmenssysteme der Fall ist –, besteht nach Art. 33 DSGVO eine Meldepflicht an die zuständige Datenschutzaufsichtsbehörde innerhalb von 72 Stunden. Die DSGVO-Meldung läuft parallel zu den Cybersicherheitsmeldungen und hat eine eigene Behörde als Adressat. Koordination ist nötig, damit nicht widersprüchliche Informationen an verschiedene Behörden gehen. Teichmann betont, dass viele Unternehmen diese Parallelstruktur unterschätzen und sich im Ernstfall in widersprüchlichen Kommunikationspflichten verstricken (Teichmann, CCZ 2025, S. 165–171).

Was das für die Praxis bedeutet

Jedes Unternehmen muss zunächst verstehen, unter welche Regime es fällt. Dies ist keine triviale Frage – ein mittelgroßes Softwareunternehmen, das Produkte für Industriekunden entwickelt und dabei als IT-Dienstleister für NIS-2-Einrichtungen auftritt, kann unter alle drei Regelwerke fallen.

Der Meldeprozess muss vorab und präzise definiert werden. Wer entscheidet, ob ein Vorfall meldepflichtig ist? Wer ist verantwortlich für die Meldung? Welche Vorlage wird verwendet? Diese Entscheidungen können nicht in einer Krisensituation zum ersten Mal getroffen werden – schon gar nicht angesichts von Vier-Stunden-Fristen.

Die Kommunikation mit verschiedenen Behörden muss koordiniert werden. Wenn ein Vorfall gleichzeitig eine NIS-2-Meldung ans BSI, eine DORA-Meldung an die BaFin und eine DSGVO-Meldung an die Datenschutzbehörde auslöst, müssen diese Meldungen konsistent sein. Widersprüchliche Informationen können das Vertrauen der Aufsichtsbehörden beschädigen.

Und alle Meldungen, die zugrunde liegenden Fakten und die Chronologie der Entscheidungen müssen revisionssicher dokumentiert werden. Im Nachgang eines Vorfalls werden Behörden prüfen, ob die Meldefristen eingehalten wurden – und die Beweislast liegt beim Unternehmen (Teichmann, ZRFC 2026, S. 81–88).

Fazit: Komplexität kennen, bevor die Uhr tickt

DORA, NIS-2 und CRA haben alle das gleiche Grundziel: Behörden sollen schnell informiert werden, wenn ein Cybervorfall stattfindet oder eine Schwachstelle ausgenutzt wird. Aber die Wege dahin unterscheiden sich in Fristen, Behörden, Auslösern und Inhalten.

Teichmanns Forschung zeigt: Wer diese Unterschiede erst versteht, wenn der Ernstfall eintritt, hat bereits verloren. Die Vier-Stunden-Frist unter DORA, die 24-Stunden-Frist unter NIS-2, die 14-tägige CRA-Abschlussfrist – das sind keine abstrakten Rechtsvorschriften. Es sind operative Anforderungen, die in jedem betroffenen Unternehmen heute schon verankert sein müssen.

Alle Quellenangaben beziehen sich auf veröffentlichte wissenschaftliche Beiträge von Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann. Die vollständige Bibliographie ist im Publikationsverzeichnis (Stand Mai 2026) dokumentiert.