Two reportable events
Actively exploited vulnerability. A vulnerability in your product for which there is reliable evidence that a malicious actor has exploited it in a system without permission. Note: exploitation anywhere, not necessarily against your customer.
Severe incident having an impact on the security of the product. An incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect availability, authenticity, integrity or confidentiality — including where malicious code execution is achieved, or where a compromise of your development or production environment could affect products.
The clocks
Both use the same three-stage cadence, submitted through the single reporting platform to the CSIRT designated as coordinator and to ENISA:
| Stage | Deadline | Content |
|---|---|---|
| Early warning | 24 hours from becoming aware | That the event happened; whether exploitation is suspected to be malicious; Member States likely affected |
| Vulnerability / incident notification | 72 hours from becoming aware | General information available: severity, impact, corrective or mitigating measures taken or advised, indicators of compromise where applicable |
| Final report | 14 days after a corrective measure is available (vulnerabilities) or one month after the notification (incidents) | Description of the vulnerability including severity and impact, information on the malicious actor if available, details of the security update or corrective measures |
You must also inform affected users of the incident or vulnerability without undue delay, and where necessary tell them the risk-mitigation and corrective actions they can take.
Why 24 hours is an organisational problem
Twenty-four hours from awareness means the clock can start on a Friday evening at a support inbox. To make it survivable:
- Define "awareness" internally and train first-line support and the
security@triage rota to recognise the trigger. - Pre-register on the reporting platform and pre-fill your organisation and product data. Discovering your credentials do not work at hour 20 is a self-inflicted wound.
- Keep a decision tree on one page: is it our product? is there evidence of exploitation in the wild? then file the early warning — an early warning is not an admission and can be withdrawn or refined at 72 hours.
- Nominate a named reporter and a deputy, with out-of-hours contact details, and rehearse the process at least annually.
Interaction with disclosure
Reporting and public disclosure are different duties on different clocks. Report to ENISA/CSIRT at 24/72 hours regardless of fix status; disclose publicly once the security update is available. Do not delay the regulatory report to keep an embargo, and do not publish exploit-enabling detail in the early warning.
Coordination with other regimes
A severe incident can trigger CRA reporting, NIS2 obligations if you are an essential or important entity, and GDPR breach notification if personal data is involved. The deadlines and recipients differ. Build one incident playbook that fans out to all applicable regimes from a single internal trigger, rather than three processes that each discover the incident separately.