One of NIS2’s most demanding practical requirements is staged reporting of significant incidents. During a data leak or disruptive cyberattack, the clock is already running: the first notification is due within 24 hours, not 72. This guide explains significance, deadlines, ownership and preparation for a response process that works under pressure.
When must an incident be reported?
Article 23 requires reporting of significant incidents. An incident may be significant if it causes or could cause severe operational disruption or financial loss, or considerable material or non-material damage to others. Potential impact matters; you do not need to wait for damage to occur.
This article describes the directive’s general framework. Also check Hungarian response procedures, the competent reporting channel and sector-specific thresholds. NIS2 reporting does not replace any parallel GDPR or DORA notification. Quick classification requires criteria and responsible people agreed in advance.
What are the reporting deadlines?
The early warning and incident notification periods begin when the organisation becomes aware of a significant incident. The final report has a different starting point: submission of the incident notification.
| Stage | General deadline | Required information |
|---|---|---|
| Early warning | 24 hours from awareness | Basic facts, suspected malicious activity and cross-border impact |
| Incident notification | 72 hours from awareness | Initial assessment, severity, scope and available indicators of compromise |
| Final report | One month after notification | Root cause, impact, measures taken and planned |
Reports must be submitted without undue delay; the deadlines are upper limits. Article 23(4) provides an exception for trust service providers: significant incidents affecting their services also require the detailed notification within 24 hours.
The first 24 hours are for raising the alert, not for solving the incident. Meeting that deadline depends on named owners and a prepared process.
What about intermediate reports?
An intermediate report may be appropriate during a prolonged response and is required if the authority requests one. It keeps the authority informed between notification and the final report. If the incident is still ongoing when the final report is due, submit a progress report and then the final report within one month of handling the incident.
What makes an incident significant?
The test is impact: severe disruption or financial loss to the entity, or considerable harm to others, whether actual or potential. The sophistication of the attack is not the deciding factor.
Relevant considerations typically include:
- the extent and duration of service disruption;
- the number of affected customers or users;
- the scale and sensitivity of lost or exposed data;
- financial, operational and reputational effects;
- cross-border consequences or supply chain spillover.
Because the first deadlines start at awareness, detection and correct classification are critical. Logging, monitoring and alert handling should be developed through NIS2 preparation and maintained with an effective security officer function.
Who owns reporting?
The organisation’s designated role, usually the Information Security Officer or incident coordinator, operates under senior management oversight. Management remains accountable for risk and incident management measures; delegating reporting does not remove that responsibility.
An effective response requires clear roles:
- Incident owner or coordinator: leads the process, triages events and tracks deadlines.
- Technical team: investigates, contains, restores and preserves evidence.
- Regulatory contact: submits reports and liaises with the authority.
- Management decision-maker: approves response actions and external communications.
- Legal and communications support: addresses GDPR overlap and public communication.
Cover arrangements matter. Incidents do not respect working hours or annual leave, and the clock continues to run.
What must be documented?
Record the whole lifecycle, from detection through closure, including significant actions, decisions and timestamps. This demonstrates a controlled response and supplies the three reporting stages.
At minimum, record:
- the time and method of detection, and the alert source;
- containment and mitigation measures with timestamps;
- the impact on systems, data and users;
- root cause analysis for the final report;
- lessons learned and preventive actions.
The record also supports learning. Recurring patterns reveal control weaknesses and inform continual improvement under ISO/IEC 27001.
How can we prepare?
During an incident, people should be able to execute an established process. A tested incident response plan is the foundation.
A plan with clear roles
Document triage criteria, actions, owners and cover arrangements. Define severity thresholds in advance so that deciding whether to report does not consume hours.
A communication chain and current contacts
Maintain escalation and notification arrangements: who contacts whom, by which channel and by when. Include the regulatory contact, management decision-maker and external legal, communications and technical support, with appropriate 24/7 contact arrangements.
Exercises and testing
Tabletop exercises and simulated incidents reveal bottlenecks and keep teams ready to act within the first day. Our NIS2 2026 guide explains broader preparation priorities.
What if we miss a notification?
Failures can result in regulatory action and fines. The consequences depend on the organisation’s classification, the infringement and applicable Hungarian rules. Management oversight and a traceable response are therefore essential.
How zemITis helps
We support plan development, triage criteria, roles, communication chains and reporting exercises with CISA, CISM and ISO 27001 Lead Auditor expertise and peer-reviewed delivery. Get an estimate on our NIS2 page, then use a free consultation to assess your incident readiness.