NIS2 incident reporting: timelines, templates and practical steps

How quickly must you report a NIS2 incident?

NIS2 Article 23 imposes a three-stage reporting cadence for significant incidents. You must submit an early warning within 24 hours of becoming aware of the incident. A detailed incident notification follows within 72 hours. A final report, including root cause analysis and remedial measures, is due within one month. Missing the 24-hour window exposes your organisation to enforcement action, fines, and potential personal liability for board members.

The 24-hour early warning is the deadline that breaks most mid-market organisations. Not because they lack the will to report, but because they lack the visibility to classify an incident fast enough. When your logs are scattered across five separate tools, just confirming whether an event qualifies as “significant” can eat up the entire window. Centralised logging changes that equation. A single audit trail that correlates access events, policy violations and security alerts lets you move from detection to classification in minutes rather than hours.

This guide walks through the three reporting phases in detail, explains what goes into each notification, covers the Belgian, Dutch and UK reporting procedures, and provides a step-by-step incident response workflow you can adapt to your organisation.

What NIS2 Article 23 requires

Article 23 replaces the vague “without undue delay” language from the original NIS directive with three hard deadlines. Each phase serves a different purpose, and the information required at each stage is deliberately different.

The clock starts when your organisation “becomes aware” that the incident meets the significance criteria. Not when the attack began. Not when you finished your investigation. The moment you have enough information to classify the event as significant, the 24-hour window opens.

If the incident is still ongoing at the one-month mark, you submit a progress report instead. The final report then follows within one month of resolution.

One detail that catches organisations off guard: Article 23(5) requires the receiving authority to respond to your early warning within 24 hours where possible, including initial guidance on mitigation. This is not a one-way street. The authority is expected to help, particularly if the incident has cross-border implications.

What counts as a significant incident

Not every security event triggers the reporting obligation. Article 23(3) defines a significant incident as one that meets either a qualitative or quantitative threshold.

Operational disruption. The incident has caused or could cause severe disruption to the services you provide. A ransomware attack that encrypts production systems qualifies. A failed phishing attempt that your filters caught does not.

Financial loss. The incident has caused or could cause significant financial loss. Direct costs, recovery expenses, lost revenue and contractual penalties all count.

Third-party damage. The incident has affected or could affect other people or organisations. Data breaches that expose personal information, or supply chain disruptions that cascade to your customers, fall into this category.

Malicious intent. Suspected state-sponsored activity, espionage, or attacks with potential cross-border impact receive priority treatment for early warning purposes.

The European Commission’s Implementing Regulation 2024/2690 adds specific technical thresholds for digital infrastructure providers such as cloud services, data centres and DNS operators. For most mid-market organisations, the practical test is straightforward: if the incident disrupts your services, compromises personal data, or could spread to other organisations, it is significant and the clock starts running.

Build your internal classification matrix around these four criteria before an incident happens. When an alert fires at 2 AM, your on-call engineer should not need to interpret regulatory text. They need a one-page decision tree that tells them: significant or not significant, report or monitor. Platforms like Jimber simplify this step because every access decision, policy violation and security alert already flows through a single control plane. The engineer sees the affected user, the device posture status and the scope of the event in one view, rather than pulling data from three consoles before a classification is even possible.

Where to report in Belgium, the Netherlands and the UK

Belgium

The Centre for Cybersecurity Belgium (CCB) is the national authority. All significant NIS2 incidents must be reported through the Safeonweb@Work portal. CERT.be, the CCB’s operational arm, handles incident coordination and can provide technical assistance during active incidents.

The Belgian reporting form requires your entity classification (essential or important), incident type (ransomware, data leak, system compromise, etc.), exact date and time of detection, a description of how you detected the event, a preliminary impact assessment, whether cross-border effects are suspected, and confirmation of whether multi-factor authentication was active on affected systems.

Belgium was among the first EU member states to transpose NIS2 into national law on 26 April 2024. Incident reporting obligations have been active since 18 October 2024. This is not a future requirement. It applies now.

For organisations working within the CyberFundamentals (CyFun) framework, incident reporting maps directly to the Respond function. CyFun control RS.CO (Communications) requires a documented process for reporting to both internal management and external authorities, including the CCB. The CyFun self-assessment guide covers these controls in detail. Jimber’s CRACy compliance tool maps your existing configuration against the Respond controls, showing where your incident reporting procedure already meets CyFun requirements and where gaps remain.

The Netherlands

The NCSC-NL (Nationaal Cyber Security Centrum) serves as the primary CSIRT for essential entities. The Netherlands activated its Cyberbeveiligingswet (Cybersecurity Act) in Q1 2026, transposing NIS2 into Dutch law. Reporting follows the same 24/72/1-month cadence through the NCSC portal.

United Kingdom

The UK operates under its own NIS Regulations 2018 (as amended), which pre-date NIS2 and differ in scope. The UK government has proposed updates to align more closely with NIS2, but the current framework uses sector-specific competent authorities rather than a single national portal. Check your sector regulator for the applicable reporting procedure.

How to meet the 24-hour deadline

This is where theory meets operational reality. The 24-hour window sounds tight. For organisations with centralised visibility, it is entirely manageable. For organisations that still collect logs manually from separate firewalls, endpoint tools and cloud applications, it is nearly impossible.

The problem is not writing the report. The early warning is deliberately light: confirm the incident, flag whether it looks malicious, note cross-border risk, describe initial containment. You can complete that form in 30 minutes.

The problem is reaching the point where you can confidently say “yes, this is significant” within the first few hours. That requires correlating data from multiple sources to understand what happened, what was affected, and how far the incident has spread.

Why dispersed logging fails the deadline. A typical mid-market setup has firewall logs in one console, endpoint alerts in another, cloud application logs in a third, and VPN access records somewhere else entirely. Pulling data from each system, normalising timestamps, and cross-referencing events manually is a multi-hour exercise even before you start analysis. Research from IBM’s 2025 Cost of a Data Breach report found that incidents involving compromised credentials take an average of 186 days to identify. Even well-resourced teams rarely complete initial triage in under 8 hours when working across disconnected tools.

How centralised logging solves it. When all access decisions, network activity and security alerts flow through a single platform, correlation happens automatically. An anomalous login from an unfamiliar location, followed by lateral movement to a file server, followed by a data exfiltration attempt, shows up as a connected sequence rather than three isolated alerts in three separate dashboards.

Jimber’s single management console correlates access events, policy violations and security alerts in one audit trail. Because all traffic passes through the SASE control plane, the full attack path is visible from a single interface: the initial entry point, the lateral movement, the affected systems and data. This lets your security lead determine whether an incident meets the significance threshold within minutes rather than hours, turning the 24-hour deadline from a scramble into a structured process.

The same audit trail generates the timestamped, immutable evidence that the final report requires one month later. Platforms like Jimber produce version-controlled logs of every access decision and policy change, which can be exported directly for the CCB’s reporting portal. No manual log aggregation. No evidence gaps.

Practical tip. Run a tabletop exercise simulating a ransomware incident. Start the clock when the first alert fires. Track how long it takes your team to confirm significance using your current tooling. If you cannot reach a classification decision within 4 hours, you have a visibility problem that process improvements alone will not fix.

Building your incident reporting procedure

A documented procedure that your team can follow under pressure is worth more than any framework diagram. Here is a step-by-step workflow, structured around the NIS2 reporting phases.

Step 1: Detect and triage (hour 0-2)

Your monitoring systems flag an anomaly. The on-call engineer checks the alert against your classification matrix. In a consolidated SASE environment like Jimber, that alert already contains the user identity, device posture status and accessed resources, giving the engineer the context to classify within minutes rather than hours. Key questions at this stage: is service availability affected? Is personal data potentially compromised? Does the incident appear to be malicious? Could it affect other organisations?

If any answer is “yes” or “likely yes”, classify as significant and start the 24-hour clock.

Step 2: Contain and escalate (hour 2-6)

Isolate affected systems. Disable compromised accounts. Block malicious IPs. Simultaneously escalate to your incident response lead and legal/compliance contact. The people who will submit the early warning need to know now, not at hour 22.

Step 3: Submit the early warning (hour 6-24)

Draft and submit the 24-hour notification through the Safeonweb@Work portal (Belgium), NCSC portal (Netherlands), or your sector regulator (UK). Include only what you know at this point. The CCB prefers an honest “unknown” in a timely filing over a detailed report submitted at hour 25.

Step 4: Investigate and gather evidence (hour 24-72)

Use your centralised logs to reconstruct the attack timeline. Identify indicators of compromise: IP addresses, file hashes, exploited vulnerabilities. Quantify the impact: number of affected users, systems, data records. Assess whether the incident has sectoral or supply chain implications.

Step 5: Submit the 72-hour notification (hour 48-72)

This update should contain validated technical detail. Severity assessment, IOCs, remediation actions taken, and an analysis of whether the incident affects other organisations or sectors. If you also have a GDPR notification obligation (personal data involved), synchronise the 72-hour submissions for consistency.

Step 6: Root cause analysis and final report (week 1-4)

After containment, conduct a post-mortem. Identify the root cause, document the complete incident timeline, and describe the permanent measures you are implementing to prevent recurrence. Submit the final report within one month.

What to prepare before an incident happens

Having these items ready before you need them saves hours during a live incident:

• Pre-populated reporting templates with your organisation’s CCB registration details, sector classification and contact information
• A classification matrix mapping incident types to NIS2 significance criteria
• An escalation matrix with names, roles and contact details for the 24-hour, 72-hour and final report submissions
• A communication plan covering internal notification (board, legal, PR) and external notification (CCB, DPA, affected third parties)
• Evidence of regular testing: tabletop exercise reports, simulation results, procedure review dates

Your NIS2 compliance checklist covers the broader audit preparation, including the incident reporting controls that conformity assessment bodies expect to see documented.

NIS2 vs GDPR vs DORA reporting: when do they overlap?

A single cyber incident can trigger reporting obligations under multiple regulations simultaneously. This is not a theoretical edge case. A ransomware attack on a hospital that encrypts patient records triggers NIS2 (service disruption), GDPR (personal data breach), and potentially sector-specific health regulations. The Belgian hospital ransomware attack earlier this year illustrated exactly this overlap.

For financial services organisations, DORA generally takes precedence over NIS2 as lex specialis. But Belgian and Dutch regulators have confirmed that a dual reporting obligation can exist for incidents that affect both ICT resilience and general network security. If you operate in financial services, the DORA register of information and SASE for financial services under DORA guides cover the financial sector requirements in depth.

The practical takeaway: maintain a single incident register that tracks all notifications across all applicable regulations. Timestamp every submission. Ensure that the facts you report to the CCB, the DPA and your financial regulator are consistent. Inconsistencies between parallel notifications create legal exposure that is entirely avoidable. A SASE platform like Jimber generates the same timestamped event logs for all three reporting streams from one audit trail, so the facts in your NIS2 early warning, your GDPR notification and your DORA report are always aligned.

FAQ

How long do you have to report a NIS2 incident?

You must submit an early warning within 24 hours of becoming aware that a significant incident has occurred. A detailed incident notification follows within 72 hours. A final report with root cause analysis is due within one month. If the incident is still ongoing at the one-month mark, submit a progress report and file the final report within one month of resolution.

What happens if you miss the 24-hour deadline?

Failure to notify your national authority within the required timeframes can result in administrative fines. For essential entities in Belgium, fines can reach EUR 10 million or 2% of worldwide annual turnover, whichever is higher. For important entities, the cap is EUR 7 million or 1.4% of turnover. Beyond fines, the CCB can suspend certifications, publicly disclose non-compliance, and in cases of repeated negligence, temporarily restrict management functions. NIS2 board liability in Belgium covers the personal liability implications for directors and officers.

Does NIS2 incident reporting overlap with GDPR?

Yes. If a cyber incident involves personal data, you may need to notify both your national CSIRT (under NIS2) and your Data Protection Authority (under GDPR) within 72 hours. The two notifications serve different purposes: NIS2 focuses on service continuity while GDPR focuses on data protection. Prepare both submissions in parallel and ensure the reported facts are consistent.

Who is responsible for NIS2 reporting in Belgium?

The Centre for Cybersecurity Belgium (CCB) is the competent authority. All significant incidents must be reported through the Safeonweb@Work portal. CERT.be handles operational incident coordination. The responsibility for ensuring timely reporting sits with the organisation’s management body. Under Belgian law, board members who fail to oversee cybersecurity implementation face personal liability.

What tools help meet the 24-hour reporting deadline?

The 24-hour window requires rapid incident classification, which depends on centralised visibility across your network, endpoints and cloud applications. A SASE platform like Jimber consolidates all access logs, policy events and security alerts into a single audit trail, reducing time-to-classify from hours to minutes. SIEM tools can serve a similar correlation function, but mid-market organisations often find that a unified SASE platform provides both the security controls and the logging visibility without the complexity of a standalone SIEM deployment.

Do Belgian organisations need to follow CyFun for incident reporting?

CyFun is the CCB’s implementation framework for NIS2 in Belgium. Its Respond function (controls RS.RP, RS.CO, RS.AN, RS.MI) directly maps to the Article 23 reporting requirements. Essential entities must achieve at least Basic or Important CyFun verification by 18 April 2026. Even if your organisation is classified as important rather than essential, implementing the Respond controls provides a structured, auditable approach to incident reporting that satisfies both NIS2 and CyFun requirements.

The 24-hour reporting deadline rewards preparation, not improvisation. Organisations with centralised logging and a pre-built reporting procedure can meet it comfortably. Those still working across disconnected tools will struggle every time. Jimber’s SASE platform provides the single audit trail, real-time alerting and immutable event logs that turn NIS2 incident reporting from a regulatory scramble into a documented, repeatable process. Book a demo to see how consolidated visibility makes the 24-hour window manageable for your team.