The short answer
For a significant incident, NIS2 requires a staged notification to your CSIRT or competent authority: an early warning within 24 hours of becoming aware, a fuller incident notification within 72 hours, intermediate updates on request, and a final report within one month. Where relevant, you must also inform the recipients of your services. The clock starts at awareness — not at full understanding.
First: what counts as a “significant incident”?
Article 23 gives two triggers. An incident is significant if it:
- has caused, or is capable of causing, severe operational disruption of your services or financial loss for your entity; or
- has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage.
Note the phrase capable of causing — you do not wait for the damage to materialise. For certain digital sectors (cloud, DNS, data centres, managed service providers and others), Implementing Regulation (EU) 2024/2690 sets concrete thresholds for when an incident is significant. For entities not covered by specific implementing thresholds, significance must be assessed against the general Article 23 criteria, the applicable national rules and any relevant sector guidance. The assessment criteria should be defined before an incident and documented internally.
Two quick examples
- Ransomware that stops a service or causes serious operational, financial or customer impact is likely to meet the significance test. Notify without undue delay when the criteria are met; do not wait for a complete forensic investigation or final root-cause analysis.
- A blocked phishing attempt with no resulting compromise is unlikely, by itself, to qualify as a significant incident requiring NIS2 notification. The conclusion depends on actual or potential impact, compromise evidence, affected services and the applicable national or sector rules.
The three deadlines, and what goes in each
| Deadline | What it is | What it must contain |
|---|---|---|
| 24 hours from awareness | Early warning | That a significant incident occurred; whether you suspect it was caused by unlawful or malicious acts; whether it could have cross-border impact. |
| 72 hours from awareness | Incident notification | Updates the early warning: your initial assessment of severity and impact, and indicators of compromise where available. |
| 1 month after the 72h notification | Final report | Detailed description of the incident, its severity and impact; the threat type or root cause; mitigation applied and ongoing; cross-border impact where relevant. If the incident is still ongoing, a progress report instead — with the final report one month after you close it. |
Two calibrations that keep the table honest. The 24-hour report is an early warning, not a completed forensic investigation — and the 72-hour notification contains the information reasonably available at that time. In between, the authority or CSIRT can request intermediate status updates, and ongoing incidents move to progress reporting with the final report following once handling ends, under the rules above.
Additional or sector-specific reporting rules may apply. Where a sector-specific Union legal act imposes cybersecurity risk-management and incident-reporting requirements that are at least equivalent, it may operate as lex specialis for those obligations. This must be assessed regime by regime.
Who else must be told
- Recipients of your services — where a significant incident may adversely affect them, you must notify them without undue delay, including measures they can take in response.
- Recipients potentially affected by a significant cyber threat — where relevant, including protective measures they can take.
- Separate regimes can apply in parallel — most commonly GDPR: if the incident results in a personal data breach, notification obligations to the data-protection authority may apply, under GDPR's own test and timeline, separately from the NIS2 significance assessment.
Romania implementation note
Reporting channels, forms and portals differ by member state. What follows is one national example, not the universal EU process:
- Romanian essential and important entities report through the national process coordinated by DNSC; the staged 24-hour / 72-hour / final-report approach is preserved.
- PNRISC is the relevant national incident-reporting process/platform.
- Verify the current DNSC instructions, contacts and forms before relying on your incident plan — procedures and portals evolve, and the middle of an incident is the wrong moment to discover that.
Legal requirement vs good practice
- Legal requirement: the staged reports above, to the CSIRT or competent authority designated by your member state, using the national channel and forms.
- Good practice (what makes the deadlines achievable): a written definition of “significant” for your business; a 24/7 escalation path with named people; the authority's contact and portal bookmarked before you need them; report templates pre-filled with your entity details; evidence-preservation habits (don't wipe and reinstall the one machine that explains the incident); an out-of-band communication channel in case email is down or compromised.
The part nobody plans for: reporting while firefighting
The 24- and 72-hour clocks run during your worst day — while systems are down and the team is containing the incident. The practical fix is separation of duties: one person owns containment, another owns the reporting track. If your entire technical response is one person, that is itself a finding — and one of the strongest arguments for having an external response team on call.
Sources
This article is general information about EU legislation, not legal advice. Reporting channels, forms and some thresholds are defined by national transposition and sector rules — confirm specifics with your national CSIRT or competent authority (in Romania: DNSC) or legal counsel. This article reflects the legislation in force on the last-reviewed date; proposed amendments are not treated as adopted law.