Most compliance writing treats reporting obligations one regulation at a time. That is fine until a real incident lands, because a single event rarely respects those boundaries. An actively exploited flaw in a connected product can, in the same afternoon, trigger a Cyber Resilience Act early warning, a NIS2 significant-incident notification, and a GDPR personal data breach report. Three clocks, three recipients, three formats, all started by one event.
This post maps the obligations against each other so you can see where they overlap, where they differ, and why running them out of three separate inboxes is how deadlines get missed.
Three Regimes, Three Clocks
CRA Article 14
The Cyber Resilience Act binds manufacturers placing products with digital elements on the EU market. Article 14 sets two triggers and a staged timeline for each.
For an actively exploited vulnerability in your product:
- Early warning within 24 hours of becoming aware
- Full notification within 72 hours
- Final report within 14 days of a corrective measure becoming available
For a severe incident affecting the security of the product:
- Early warning within 24 hours
- Notification within 72 hours
- Final report within one month
Reports go to the CSIRT designated as coordinator and to ENISA, through the single reporting platform once it is live.
NIS2 Article 23
If your organisation is an essential or important entity under NIS2, a significant incident carries its own staged duty, owed by you as an operator, not as a product maker.
- Early warning within 24 hours of becoming aware
- Incident notification within 72 hours, with an initial assessment, severity, impact and any indicators of compromise
- Intermediate report on the authority's request
- Final report within one month of the notification
Reports go to the CSIRT or the competent authority of your Member State. The same event that triggers a CRA product report can therefore trigger a separate NIS2 operator report, on a parallel 24 and 72 hour track, to a recipient that may or may not be the same body.
GDPR Article 33
If the incident exposed personal data, the General Data Protection Regulation adds a third clock.
- Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware
- Where the breach is likely to result in a high risk to individuals, Article 34 requires you to inform the affected people as well, without undue delay
This clock answers to your data protection authority, which is a different body again, and the content it wants is about data subjects and harm, not about the product defect.
Where They Overlap and Where They Diverge
The deadlines look similar on paper, which is exactly the trap. The 24 and 72 hour figures repeat, but the moment the clock starts, the recipient, and the required content all differ.
| Trigger | First deadline | Recipient | Focus | |
|---|---|---|---|---|
| CRA Art. 14 | Exploited vuln or severe incident in the product | 24h early warning | Coordinator CSIRT and ENISA | The product defect |
| NIS2 Art. 23 | Significant incident to the entity | 24h early warning | National CSIRT or competent authority | Operational impact |
| GDPR Art. 33 | Personal data breach | 72h notification | Data protection authority | Risk to individuals |
A few points are worth holding onto.
The starting gun differs. CRA and NIS2 run from when you become aware of the incident or exploitation. GDPR runs from awareness of the breach. In a messy real incident these moments can be hours or days apart, so the three clocks rarely start together even when one event causes all of them.
The recipients differ. A coordinator CSIRT, a national competent authority, and a data protection authority are three offices with three intake channels. None of them will accept a copy of the report you sent to another.
The content differs. ENISA wants the vulnerability and the corrective measure. The NIS2 authority wants operational severity and indicators of compromise. The data protection authority wants the categories of data, the number of people affected, and the likely consequences for them.
What overlaps is the 24-hour reflex. Across CRA and NIS2 the law now expects you to say something meaningful within a day, before you have a full picture. That early warning is not a formality. It is the obligation most likely to be missed, because it falls in the first chaotic hours when the team is still establishing what happened.
The Practical Problem
The danger is not ignorance of any single rule. Most teams can recite the 72-hour GDPR deadline. The danger is the collision. When one event starts three clocks, the work splinters across legal, security and the data protection officer, each watching their own regulation, each assuming someone else has the others covered. The early warning that needed to go out at hour 23 slips because everyone was drafting the report due at hour 72.
A workable process treats these as one workflow with three outputs, not three workflows.
- One intake, one timestamp. Record the moment of awareness once, because every clock is measured from a version of it. Argue later about which version applies to which regime. Do not lose the timestamp.
- One triage that asks all three questions at once. Is this an exploited vulnerability or severe product incident? Is it a significant incident to us as an operator? Did it touch personal data? The answers are not mutually exclusive.
- Parallel drafts, not sequential. The 24-hour warnings for CRA and NIS2 should be prepared together while the GDPR assessment runs alongside, not after.
- One audit trail. When an authority asks why a report arrived when it did, you want a single record showing what you knew and when, across all three duties.
Beyond the Big Three
The same pattern repeats in adjacent regimes. Financial entities under DORA face major ICT incident reporting on their own staged timeline. Telecoms carry breach duties under the ePrivacy rules. Sector regulators for medical devices and machinery add their own product reporting. The names change, the structure does not. A trigger, a short fuse for the first signal, a fuller report later, owed to a specific authority in a specific format.
If you build the discipline once, around a single source of truth for what happened and when you knew it, each new regime becomes another output of the same process rather than another silo to staff.
Where CVD Portal Fits
CVD Portal already runs the front of this pipeline. A vulnerability arrives through your coordinated disclosure portal, gets triaged, and feeds the CRA Article 14 reporting workflow with the deadlines tracked against the moment of awareness. The obligations above are the natural extension of that same spine. One event, one timestamp, one triage, and a clear view of every clock it started.
If you are mapping your own notification obligations and want to see how the CRA piece works today, that is the part of the portal you can use right now.