It is a reasonable question. NIS2 sets specific timeline requirements that are shorter than most organisations are used to. And it is precisely that compressed timeframe that makes incident handling impossible to run as a manual, ad hoc workflow.
What counts as a significant incident?
This is where confusion typically starts. Not every security incident triggers the reporting obligation. NIS2 defines a significant incident as one that has caused, or has the potential to cause, serious operational disruption, financial damage, or impact on other organisations or essential services.
In practice, this means organisations must be able to assess an incident's potential impact quickly, often before the full scope is known. It is a judgement requirement, not just a technical determination.
A common misconception is that the reporting obligation only applies to confirmed breaches. It does not. Suspected incidents with potentially serious impact can also trigger the obligation. This directly affects how a compliance system needs to be configured: detection logic must flag potential events, not only confirmed ones.
The three steps: what is required and when
NIS2 divides the reporting obligation into three distinct steps.
Early warning within 24 hours
As soon as an organisation becomes aware of a significant incident, an early warning must be submitted to the relevant supervisory authority. A full analysis is not required at this stage, but the warning must confirm that an incident has occurred and indicate whether there is any suspicion of unlawful or malicious activity.
Formal notification within 72 hours
Within 72 hours, a more complete notification must be submitted. This should cover the nature of the incident, an initial assessment of impact, and the measures taken. This is the stage where gaps in documentation and internal processes tend to become visible.
Final report within one month
A final report must be submitted within 30 days. It should include a full description of the incident, root cause analysis, remediation actions, and lessons learned.
These are not three separate processes. They are a continuous flow that requires information to be collected, structured and escalated in real time. Organisations attempting to manage this with email and spreadsheets will struggle to meet the timelines.
Who reports to whom?
Supervisory responsibility under NIS2 is distributed across member states and, within each country, often across sector-specific authorities. The authority your organisation reports to depends on the sector you operate in, not a single central body.
This is something that frequently surprises organisations. It is important to have the correct reporting channel built into your compliance system from the start, not something to figure out when an incident actually occurs.
What this means for system design
This is where the operational work begins. Incident reporting under NIS2 is not a communications problem. It is a system design problem.
Hy5 handles this by automatically flagging events that meet the criteria for a significant incident, tracking the timelines for each reporting step, and ensuring the right documentation is available when it is needed. Organisations using Hy5 for incident management do not need to manually monitor whether the 24-hour threshold is about to be breached.
Are you managing incident reporting manually today?
Hy5 automates the detection and flagging of NIS2-reportable events and tracks all timelines in real time. Used by organisations in regulated sectors to operationalise NIS2 without parallel manual processes.
Hy5 kan drastiskt öka effektiviteten och precision för compliancearbete.
