Based on the research work of Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann

It is 3 a.m. The IT department detects that attackers have been actively penetrating corporate systems for hours. The board of directors is woken up. And then a question begins that no one can answer with certainty at this very moment: Who do we actually have to inform and when – and within what deadline?

In practice, this is precisely the situation in which many companies realize that they have never truly penetrated the reporting obligations of European cybersecurity law. Because with DORA, NIS-2, and the Cyber Resilience Act (CRA), there are today three different EU regulatory frameworks that all provide for reporting obligations in the event of cyber incidents – with different deadlines, different recipients, different authorities, and different triggers. Teichmann has systematically analyzed this complex situation in several scientific contributions. The findings are relevant for any company that falls under more than one of these regulatory frameworks.

Why there are three different reporting regimes

The emergence of parallel reporting obligations is not an oversight by the European legislator, but rather an expression of three different regulatory logics.

NIS-2 is aimed at operators – i.e., companies that operate critical services and infrastructures. The goal is to ensure that disruptions to these services are reported to supervisory authorities at an early stage so that they can assess and coordinate systemic risks. NIS-2 is cross-sectoral and operator-related (Teichmann, Neue Cybersicherheitspflichten durch das NIS-2-Umsetzungsgesetz, K&R 2026, pp. 26–32).

DORA is aimed at financial entities – i.e., a specific sector with particular systemic relevance. The logic is the same as for NIS-2, but the requirements are stricter and more detailed. Financial failures can destabilize the entire economic system, which is why the legislator sets stricter standards here (Teichmann, Digital Operational Resilience Act – EU-weit einheitliche IT-Sicherheitsregeln für Finanzinstitute, BB 2025, pp. 2760–2770).

The CRA, on the other hand, is aimed at manufacturers of connected products – i.e., not at operators, but at the producers of the technology itself. If a vulnerability in a product is actively exploited, the manufacturer must report this so that authorities can react and warn other users of the same product (Teichmann, Cyber Resilience Act – Produktsicherheit, SBOM und Herstellerhaftung entlang des Lebenszyklus, CCZ 2025, pp. 165–171).

The problem arises when the same company fulfills multiple roles simultaneously – which is very common in practice. A bank that develops and operates its own software can simultaneously fall under DORA as a financial entity, under NIS-2 as an essential entity, and under the CRA as a manufacturer. At that moment, three different reporting obligations with different deadlines run in parallel.

The reporting obligations in detail: Who reports what, when, and to whom

NIS-2: The three-stage standard model. NIS-2 established the three-stage reporting process, which is now considered the reference model for the entire European cybersecurity law. An early warning must be sent to the BSI within 24 hours of becoming aware of a significant incident. This initial report does not yet need to contain a complete analysis; it is sufficient to state that a significant incident has occurred and to provide an initial assessment of whether it might be a malicious act. Within 72 hours, the actual incident report follows with an initial assessment. A final report must be submitted no later than one month after the initial report. An incident is considered significant if it has caused or is capable of causing severe operational disruption or significant financial loss – the yardstick is therefore the potential impact, not merely the damage already incurred (Teichmann, Die neue 24-Stunden-Meldepflicht für Cyberangriffe nach ISG, Jusletter, September 29, 2025).

DORA: Stricter, faster, finance-specific. DORA adopts the basic three-stage model but tightens it in several respects. The crucial tightening concerns the initial deadline: an initial report must be sent to BaFin within four hours of classifying the incident as major – not within 24 hours. This requires the financial entity to have efficient internal classification processes in place that enable such an assessment in a short period of time. DORA defines thresholds using specific financial criteria: number and proportion of affected clients and transactions, geographical impact, duration of downtime, reputational damage, and financial losses. The intermediate report follows within 72 hours, and the final report within one month – analogous to NIS-2. Since DORA is considered lex specialis to NIS-2, the BaFin report generally replaces the BSI report; both authorities coordinate with each other (Teichmann, Harmonisierung von Incident-Reporting-Meldefristen nach DORA, NIS2 und CRA, ZRFC 2026, pp. 81–88).

CRA: A completely different logic. The CRA introduces a reporting obligation that structurally deviates from NIS-2 and DORA. It is not about operational disruptions, but about product vulnerabilities. According to Art. 14 CRA, manufacturers of connected products must report actively exploited vulnerabilities to the BSI and, in parallel, to the European Union Agency for Cybersecurity (ENISA) within 24 hours of becoming aware of them. Within 72 hours, a more complete report follows, and within 14 days – not one month as in the case of NIS-2 and DORA – a final report. The crucial structural difference is that CRA reports concern vulnerabilities in the product, not incidents in one's own operations. A manufacturer therefore does not have to report because they themselves became the victim of an attack, but because their product was or could be the gateway for an attack on someone else (Teichmann, CCZ 2025, pp. 165–171).

The coordination problem: When all three regimes apply simultaneously

The real challenge arises in scenarios where a company is subject to multiple regimes at the same time. The classic example is a software company that develops security solutions for banks and itself acts as a critical IT service provider in the financial sector. In the event of a major security incident, this company can be affected simultaneously as a NIS-2 entity with an obligation to report to the BSI within 24 hours, as a CRA manufacturer with an obligation to report an actively exploited product vulnerability to the BSI and ENISA within 24 hours, and as an ICT third-party service provider under DORA with the obligation to inform the affected financial entities, which in turn must report to BaFin within four hours (Teichmann, ZRFC 2026, pp. 81–88).

What is identical – and what is not

The trigger differs fundamentally. NIS-2 triggers the reporting obligation for a significant security incident that disrupts operations. DORA triggers it for a major ICT-related incident with concrete financial impacts. The CRA triggers it for an actively exploited product vulnerability – regardless of whether the manufacturer itself is operationally affected.

The initial deadline varies: 24 hours under NIS-2 and CRA, four hours under DORA. For financial entities, the DORA deadline is therefore the strictest – and it begins not when the incident becomes known, but at the time of internal classification as major.

The reporting authority is different: NIS-2 and CRA report to the BSI, DORA to BaFin. CRA reports also go to ENISA at the European level. The final report is due after one month under NIS-2 and DORA, and after just 14 days under CRA. And the content differs: NIS-2 and DORA focus on the operational incident, while the CRA focuses on the product vulnerability and patch status.

The GDPR as a fourth layer

In addition to DORA, NIS-2, and CRA, there is a fourth reporting obligation that applies to many cyber incidents: the General Data Protection Regulation. If personal data is affected – which is the case in most attacks on corporate systems – there is a reporting obligation to the competent data protection supervisory authority within 72 hours under Art. 33 GDPR. The GDPR report runs parallel to the cybersecurity reports and is addressed to a separate authority. Coordination is necessary to ensure that contradictory information is not sent to different authorities. Teichmann emphasizes that many companies underestimate this parallel structure and, in an emergency, get entangled in contradictory communication obligations (Teichmann, CCZ 2025, pp. 165–171).

What this means in practice

Every company must first understand which regimes it falls under. This is not a trivial question – a medium-sized software company that develops products for industrial customers and thereby acts as an IT service provider for NIS-2 entities can fall under all three frameworks.

The reporting process must be defined precisely and in advance. Who decides whether an incident is reportable? Who is responsible for the report? What template is used? These decisions cannot be made for the first time in a crisis situation – certainly not in view of four-hour deadlines.

Communication with different authorities must be coordinated. If an incident simultaneously triggers a NIS-2 report to the BSI, a DORA report to BaFin, and a GDPR report to the data protection authority, these reports must be consistent. Contradictory information can damage the trust of the supervisory authorities.

And all reports, the underlying facts, and the timeline of decisions must be documented in an audit-proof manner. In the aftermath of an incident, authorities will check whether the reporting deadlines were met – and the burden of proof lies with the company (Teichmann, ZRFC 2026, pp. 81–88).

Conclusion: Know the complexity before the clock starts ticking

DORA, NIS-2, and CRA all have the same basic goal: authorities should be informed quickly when a cyber incident occurs or a vulnerability is exploited. But the ways to achieve this differ in deadlines, authorities, triggers, and content.

Teichmann's research shows that those who only understand these differences when an emergency occurs have already lost. The four-hour deadline under DORA, the 24-hour deadline under NIS-2, the 14-day CRA final report deadline – these are not abstract legal provisions. They are operational requirements that must already be anchored in every affected company today.

All sources refer to published scientific contributions by Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann. The complete bibliography is documented in the list of publications (as of May 2026).