A security team that has just confirmed a serious incident usually assumes its first job is to understand what happened. Under NIS2 its first job is partly to tell someone - within hours, before the picture is complete. The reporting obligation is not one deadline but three, running in sequence from a single starting gun, and the teams it catches out are the ones built to investigate first and disclose later.
So it is worth walking the three clocks in order: what each one requires, when the counting starts, and why the staging is built this way.
When the clock starts: becoming aware
Before the deadlines mean anything, you need the moment they run from - and under NIS2 that moment is awareness, not certainty. The clock starts when the entity becomes aware of a significant incident, not when it has finished understanding it.
This is the detail that catches teams out, because the instinct is to wait until you know what happened before telling anyone. NIS2 inverts that: it wants the first flag raised while you are still working out the picture.
So the practical capability the timeline demands is not faster investigation - it is faster escalation: the ability to recognise "this looks significant" and start the clock deliberately, rather than let awareness sit unacknowledged in an inbox.
Clock one: the 24-hour early warning
The first deadline is an early warning, due within 24 hours of awareness.
It is deliberately light. At 24 hours you are not expected to know the cause, the full scope, or the fix - you are expected to have told the authority that something significant appears to be happening, with whatever you know so far, including whether it looks like the result of unlawful or malicious action.
The point of the early warning is speed over completeness. It exists so that the authorities - and, through them, potentially other entities at risk - learn early, while there is still time for the information to be useful. Treating it as a mini-report to be perfected is the wrong instinct; treating it as a fast flag you can send on partial information is the right one.
Clock two: the 72-hour notification
The second deadline, within 72 hours of awareness, is the fuller incident notification.
By this point more is expected: an initial assessment of the incident, its severity and impact, and where available the indicators of compromise.
This is the stage that most resembles what people picture as "reporting an incident" - a substantive account of what is known three days in. It builds on the early warning rather than replacing it, which is why the two are best thought of as one escalating disclosure rather than two separate filings. The 72-hour mark is the checkpoint where "something is happening" has to become "here is our assessment of what is happening."
Clock three: the one-month final report
The third deadline, within one month of the notification, is the final report.
This is the full account: a detailed description of the incident, its severity and impact, the root cause or threat type behind it, and the mitigation measures taken.
The one-month report is where the obligation closes the loop - not just "what happened" but "why it happened and what we did about it." If the incident is still ongoing at the one-month mark, the expectation shifts to a progress report, with the final report following once the matter is resolved.
The point of this stage is accountability after the fact: a documented, considered account a supervisor can assess, rather than the fragmentary picture available in the first hours.
Why three stages instead of one
Read together, the three clocks are a single mechanism with a clear logic: raise the alarm fast, assess quickly, explain fully. Each stage trades completeness for speed in a different proportion - the 24-hour warning is almost all speed, the one-month report almost all completeness, and the 72-hour notification sits deliberately in between.
For an organisation, the implication is that incident response and incident reporting are not the same capability and cannot be run as one.
You can have a strong technical response and still miss the 24-hour clock, because the response team is heads-down fixing the problem while nobody has the job of escalating it to the authority. The staging only works if someone owns the reporting track in parallel with the fixing track, from the moment awareness is established.
One contrast worth noting: DORA runs faster
If your organisation is also a financial entity under DORA, be aware the clocks are not identical. DORA's incident-reporting timeline for major ICT incidents is tighter at the front, its initial notification window is shorter than NIS2's 24 hours.
The implication is not that you run two reporting processes, but that an entity in scope for both has to build to the stricter clock, because meeting the faster deadline satisfies the slower one, not the other way round.
That is the only cross-regime point worth making here. The rest of the time, for a NIS2-only entity, the three clocks above are the obligation in full, and the capability that meets them is the ability to escalate on awareness, not the ability to investigate quickly.
Frequently asked questions
What are the NIS2 incident reporting deadlines?
Montro's summary: NIS2 Article 23 sets three staged deadlines, all running from the point the entity becomes aware of a significant incident. An early warning within 24 hours; a fuller incident notification within 72 hours; and a final report within one month.
Each builds on the last, trading speed for completeness as the picture develops, the 24-hour warning is a fast flag, the one-month report a full account.
When does the NIS2 reporting clock start?
When the entity becomes aware of a significant incident, not when it has fully understood or resolved it.
This is the point most often misjudged, because the instinct is to investigate before disclosing. NIS2 expects the first flag raised while the picture is still forming, which means the capability it really demands is fast escalation, not fast investigation.
What has to be in the NIS2 early warning versus the final report?
The 24-hour early warning is deliberately minimal - notice that a significant incident appears to be occurring, with whatever is known so far, including whether it looks malicious.
The one-month final report is the full account: detailed description, severity and impact, root cause or threat type, and the mitigation measures applied. The 72-hour notification sits between them, adding an initial assessment of severity and impact.
Is the NIS2 reporting timeline the same as DORA's?
No. An entity in scope for both will find DORA's initial notification window for major ICT incidents is tighter at the front than NIS2's 24-hour early warning.
An organisation subject to both does not run two parallel processes so much as build to the stricter deadline, since meeting the faster clock satisfies the slower one. For a NIS2-only entity, the three Article 23 clocks are the complete picture.
