Detecting a cyber security incident is only the first step. Under NIS2 incident reporting requirements, organizations must also determine whether the incident is reportable, notify the appropriate authority within strict timelines, and continue providing updates as investigations progress.

 

Meeting these obligations requires more than knowing the reporting deadlines. Security, IT, compliance, legal, and management teams need clear processes for classifying incidents, coordinating investigations, gathering evidence, and preparing reports while response activities are still underway.

 

This guide explains the incident reporting requirements under Article 23 of the NIS2 Directive and provides practical guidance on building an incident reporting process that supports ongoing compliance.

 

 

Understanding NIS2 incident reporting obligations

 

Not every cyber security event needs to be reported under NIS2. The Directive requires organizations to report significant incidents that affect, or are capable of affecting, the provision of their services. When determining whether an incident is significant, organizations should consider factors such as:

 

• The severity of operational disruption.
• Financial losses suffered by the organization.
• The number of users or customers affected.
• The duration of the disruption.
• Whether the incident has caused, or could cause, considerable material or non-material damage to other individuals or organizations.

 

Because investigations are often ongoing when an incident is first detected, organizations should establish an internal assessment process that helps security teams quickly determine whether an incident is likely to meet the reporting threshold.

 

NIS2 incident reporting timeline

 

Article 23 introduces a staged reporting process rather than requiring organizations to submit a complete report immediately after an incident occurs.

 

Reporting stage	Timeline	Purpose
Early warning	Within 24 hours of becoming aware of a significant incident	Notify the competent authority or CSIRT that a significant incident has occurred and indicate, where known, whether malicious activity or cross-border impact is suspected.
Incident notification	Within 72 hours of becoming aware	Provide an initial assessment of the incident, including its severity, impact, and available indicators of compromise.
Intermediate report	Upon request	Provide progress updates if requested by the competent authority or CSIRT during the investigation.
Final report	Within one month of the incident notification	Explain the incident, root cause, mitigation measures, impact, and lessons learned. If the incident is still ongoing, submit a progress report followed by a final report within one month after the incident has been resolved.

 

Early warning (within 24 hours)

 

The purpose of the early warning is to alert the relevant authority that a significant incident has occurred. At this stage, organizations are not expected to have completed a full investigation.

 

Include the information available at the time, such as whether malicious activity is suspected or whether the incident could have a cross-border impact. If assistance is required, organizations may also request operational support from the relevant authority.

 

 

Incident notification (within 72 hours)

 

As investigations progress, organizations should submit a more detailed incident notification.

 

This report should update the information provided in the early warning and include an initial assessment of the incident’s severity, operational impact, and, where available, indicators of compromise.

 

Final report

 

The final report provides a complete picture of the incident after investigations have concluded.

 

You should include:

 

• A detailed description of the incident and its impact.
• The likely threat or root cause.
• Mitigation measures that were implemented.
• Where applicable, the cross-border impact of the incident.

 

If the incident has not yet been resolved by the reporting deadline, submit a progress report and provide the final report once the incident has been fully handled.

 

Quick link: NIS2 risk management measures: How to meet Article 21 requirements 

 

Building an incident reporting process for NIS2 compliance

 

Meeting the reporting deadlines begins long before an incident occurs. Establishing clear internal processes helps teams assess incidents consistently, gather the required information quickly, and coordinate reporting activities without delaying incident response.

 

1. Establish incident classification criteria

 

Define how your organization will determine whether an incident is reportable under NIS2.

 

Document the criteria used to assess operational disruption, affected services, financial impact, and potential harm to customers or other organizations. Use predefined criteria to make consistent decisions during high-pressure situations.

 

2. Define reporting roles and responsibilities

 

Incident reporting often involves multiple teams. Assign responsibility for incident detection, technical investigation, regulatory reporting, legal review, management approval, and communication with competent authorities. Clearly document these responsibilities to reduce delays and confusion during an incident.

 

3. Standardize incident documentation

 

Capture incident information using a consistent process rather than collecting information from emails, spreadsheets, or multiple ticketing systems. Your documentation should include affected systems, incident timelines, business impact, containment activities, recovery actions, evidence collected, and decisions made throughout the investigation. Maintain complete records to simplify final reporting and future audits.

 

4. Coordinate security, compliance, and business teams

 

Security teams may investigate the incident, but reporting often requires input from legal, compliance, risk management, communications, and business stakeholders. Establish communication procedures that allow these teams to exchange information quickly while ensuring regulatory reporting remains accurate and consistent.

 

5. Review and improve after every incident

 

Once an incident has been resolved, conduct a structured post-incident review. Identify what worked well, where delays occurred, whether reporting timelines were met, and which processes require improvement. Update incident response procedures, reporting workflows, and risk assessments to strengthen future readiness.

 

Common challenges when meeting NIS2 incident reporting requirements

 

Teams often face challenges in meeting the NIS2 incident reporting requirements. Some of them include:

 

• Determining whether an incident is significant: Organizations often have limited information in the early stages. Establish predefined classification criteria so that security teams make reporting decisions without waiting for the investigation to conclude.

 

• Gathering information within tight reporting deadlines: The 24-hour and 72-hour reporting windows leave little time to collect technical evidence, assess business impact, and prepare notifications. Standardized reporting templates and documented workflows can significantly reduce delays.

 

• Coordinating multiple stakeholders: Incident reporting requires collaboration between technical and non-technical teams. Without clearly defined responsibilities, approvals, and information sharing, the reporting process can slow down.

 

• Maintaining evidence throughout the investigation: Investigation records, system logs, response actions, and communications should be documented throughout the incident. Maintaining evidence as the investigation progresses is more effective than attempting to reconstruct events after the incident has been resolved.

 

How CyberArrow supports NIS2 incident reporting

 

Meeting NIS2 incident reporting requirements requires more than responding to incidents. Organizations also need structured processes to document investigations, maintain evidence, track corrective actions, and demonstrate NIS2 compliance.

 

CyberArrow GRC helps organizations support these activities by enabling teams to:

 

• Track incidents and remediation activities through centralized workflows.
• Maintain complete audit trails and investigation records.
• Assign and monitor corrective actions until completion.
• Collect and organize evidence for regulatory reviews and audits.
• Manage related risks, policies, and compliance activities from a single platform.
• Monitor incident trends and compliance activities through real-time dashboards and reporting.

 

CyberArrow helps organizations improve incident oversight, strengthen regulatory reporting processes, and maintain continuous compliance with NIS2 requirements.

 

 

FAQs