1 August 2026By NexCyber Editorial Incident reporting

A single security event can trigger reporting under the CRA, NIS2, GDPR and DORA at once — different deadlines, different recipients, different subjects.

---

The short answer

A single event can put you under four reporting obligations at once, and they do not merge.

CRA Art. 14    24h early warning · 72h notification · final report
               recipient: designated CSIRT + ENISA
               subject: an actively exploited vulnerability in your PRODUCT

NIS2 Art. 23   24h early warning · 72h notification · 1 month final
               recipient: national CSIRT or competent authority
               subject: a significant incident affecting YOUR SERVICES

GDPR Art. 33   72h to the supervisory authority
               subject: a personal data breach

DORA Art. 19   initial · intermediate · final, per RTS timelines
               recipient: your financial-sector competent authority
               subject: a major ICT-related incident

Four subjects, four recipients, four sets of evidence. The event is one; the regulatory objects are not.

---

Why they cannot be collapsed

Each regime asks about a different thing.

The CRA asks about the product. Is a vulnerability in something you placed on the market being exploited?

NIS2 asks about the service. Is the continuity or security of your operations significantly affected?

GDPR asks about the people. Were personal data compromised, and what is the risk to individuals?

DORA asks about financial stability. Did an ICT incident materially affect your critical functions?

The same ransomware event answers all four differently, and an answer that satisfies one will not satisfy the others.

---

The trap: the clocks look identical and are not

CRA and NIS2 both say "24 hours". This creates a false sense of symmetry.

They start on different triggers. The CRA clock starts when you become aware of *active exploitation of a vulnerability in your product*. The NIS2 clock starts when you become aware of a *significant incident affecting your services*.

These can be hours or days apart. You may know a component is being exploited in the wild long before your own services degrade — or your services may fail for reasons that never involve a product vulnerability at all.

Running one clock for both produces a late report on whichever started first.

---

The second trap: you may be the reporter twice, in different roles

A software vendor whose product is exploited, and whose own operations are affected, reports:

as MANUFACTURER   under the CRA, about the product, to CSIRT + ENISA
as ENTITY         under NIS2, about the service, to the national authority

Same company, same day, two files, two different sets of facts. Teams that have not separated these roles in advance tend to write one report and send it twice — which understates one obligation and confuses the other.

---

What a working runbook contains

A trigger table, not a procedure. The first question in an incident is never "what do we do" — it is "which of these has started".

did a vulnerability in a product we placed on the market
get exploited?                          -> CRA clock
are our own services significantly affected?  -> NIS2 clock
were personal data compromised?         -> GDPR clock
are we a financial entity with a major
ICT incident?                           -> DORA clock

Named people per regime, with deputies. Not roles. People, with phone numbers, empowered to notify without approval.

Pre-drafted templates per regime. At hour one you know almost nothing, so each form must be answerable with almost nothing.

A single timeline log, shared. One chronology of what was known when — from which each regime's report is drawn. This is the artefact every authority will ask for, and it cannot be reconstructed afterwards.

---

The organisational failure underneath

Ask who can send a 24-hour early warning to an authority. The answer is usually a committee.

A committee cannot convene inside 24 hours reliably, and never at 2 a.m. on a Saturday.

The clock does not test your forensics. It tests your decision rights. That is a governance fix, and it costs nothing but a decision.

---

What to do about over-reporting

Teams worry that reporting too readily creates exposure. In practice the asymmetry runs the other way:

an early warning that turns out to be nothing   a follow-up
a missing early warning                          a breach of the obligation

Self-reporting is an explicit mitigating factor in the penalty assessment under these regimes. Reticence is not.

Write the threshold low, in writing. Ambiguity resolves toward silence otherwise, and silence is the expensive option.

---

Five things to build before you need them

1The trigger table, on one page, in the runbook.
2Named notifiers per regime, with deputies and authority to act alone.
3Templates per regime, drafted now.
4One shared timeline log, started at first suspicion.
5A written low threshold, so nobody has to be brave at 2 a.m.

---

Test your reporting readiness — free, no account

[Free readiness assessment](/assess) — which reporting regimes reach you
[Compliance responsibility mapper](/resources/responsibility-mapper) — who notifies, per regime
[Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover

---

One Incident, Four Clocks, Four Authorities