NIS2 Incident Reporting Playbook: Article 23 Timelines, Templates & CSIRT Procedures

NIS2 Incident Reporting: What Article 23 Requires

The NIS2 Directive (Directive (EU) 2022/2555) introduces the most prescriptive incident reporting regime ever imposed on network and information system operators across the European Union. Article 23 lays down a structured, time-bound process that both Essential and Important entities must follow whenever a significant incident occurs.

Unlike its predecessor (NIS1), which allowed Member States considerable discretion in designing reporting obligations, NIS2 harmonises the timeline, content requirements, and reporting channels across all 27 Member States. The goal is twofold: enable CSIRTs to provide rapid assistance to the affected entity, and give competent authorities the situational awareness needed to protect other organisations and the public.

This playbook walks through every element of the Article 23 obligation — from determining whether an incident is "significant" through to submitting the final report — with practical templates, classification criteria, and lessons from early adopters.

What Constitutes a "Significant Incident" Under NIS2?

Not every security event triggers the Article 23 reporting obligation. The Directive limits mandatory reporting to significant incidents, defined in Article 23(3) as incidents that:

• Have caused or are capable of causing severe operational disruption of the services provided by the entity, or financial loss for the entity concerned;
• Have affected or are capable of affecting other natural or legal persons by causing considerable material or non-material damage.

Two critical points deserve emphasis. First, the test is disjunctive — an incident need only meet one of the two criteria to be significant. Second, the language covers both actual and potential impact. An incident that has not yet caused disruption but is capable of doing so still qualifies. This means organisations cannot wait for harm to materialise before reporting.

Incident Classification Criteria

To determine rapidly whether an incident is significant, organisations should establish pre-defined classification criteria. Below is a recommended framework aligned with Article 23(3):

Organisations should calibrate the specific thresholds (e.g., duration, user count, financial value) to their own operational context and risk appetite. The key principle: when in doubt, report. Over-reporting carries no penalty; under-reporting does.

The 3-Stage Reporting Timeline

Article 23 establishes a phased reporting approach that balances speed with depth. Each stage serves a distinct purpose:

The clock starts when the entity becomes aware of the significant incident. "Awareness" means the point at which the entity has reasonable grounds to believe that a significant incident has occurred — not when the investigation is complete. Early detection capability is therefore critical.

Stage 1: 24-Hour Early Warning

The early warning is the first formal communication to the CSIRT or competent authority. Its purpose is to provide a rapid heads-up so that assistance can be mobilised and other potentially affected entities can be warned.

Required Content

Article 23(4)(a) specifies that the early warning must include:

• Whether the significant incident is suspected of being caused by unlawful or malicious acts
• Whether the incident could have a cross-border impact

Early Warning Template

The early warning is deliberately lightweight. Do not delay submission because your investigation is incomplete. The 72-hour notification provides the opportunity to share a fuller picture.

Stage 2: 72-Hour Incident Notification

The incident notification builds on the early warning with a more comprehensive assessment. By this point, 48 additional hours of investigation should have yielded a clearer understanding of scope, impact, and severity.

Required Content

Article 23(4)(b) requires the incident notification to include:

• An update of the information provided in the early warning
• An initial assessment of the significant incident, including its severity and impact
• Where available, the indicators of compromise (IoCs)

72-Hour Notification Template

If you cannot provide certain fields by the 72-hour deadline, submit what you have and clearly indicate which elements remain under investigation. A partial but timely submission is always preferable to a late but complete one.

Stage 3: 1-Month Final Report

The final report is the most comprehensive submission. It serves as the definitive record of the incident and provides the CSIRT with the intelligence needed to protect the wider ecosystem.

Required Content

Article 23(4)(d) requires the final report to include:

• A detailed description of the incident, including its severity and impact
• The type of threat or root cause that is likely to have triggered the incident
• Applied and ongoing mitigation measures
• Where applicable, the cross-border impact of the incident

Final Report Template

Intermediate Reports for Ongoing Incidents

Not every incident is resolved within a month. Article 23(4)(c) addresses this reality by requiring entities to submit an intermediate progress report if the incident is still ongoing at the one-month deadline.

The intermediate report should contain:

• A status update on the incident — what has been resolved and what remains ongoing
• Updated severity and impact assessment
• Mitigation measures applied and planned
• Expected timeline for resolution

Once the incident is resolved, the entity must submit the final report within one month of resolution. If the incident persists for an extended period, the CSIRT may request additional intermediate updates at reasonable intervals.

Who to Report To: CSIRT vs Competent Authority

NIS2 gives Member States flexibility in designating reporting channels. In practice, there are two possible recipients:

CSIRT (Computer Security Incident Response Team)

The designated national CSIRT receives incident reports and provides technical assistance. Most Member States have designated the CSIRT as the primary point of contact for incident reports. CSIRTs are typically better equipped to:

• Provide rapid technical assistance during active incidents
• Share anonymised threat intelligence with other affected entities
• Coordinate cross-border incident response through the CSIRTs Network

Competent Authority

The competent authority is responsible for supervision and enforcement. Some Member States may require reporting to the competent authority directly, or to both the CSIRT and competent authority simultaneously. The competent authority's role is primarily:

• Supervisory oversight and compliance enforcement
• Assessing whether the entity's response was adequate
• Determining whether penalties or corrective measures are warranted

Determining Your Reporting Channel

Each Member State's national transposition law specifies the reporting channel. Organisations should:

1. Identify the Member State(s) where they provide services falling within NIS2 scope
2. Check the national transposition law in each relevant Member State
3. Confirm the designated CSIRT and/or competent authority
4. Register contact details and establish reporting procedures in advance
5. Pre-populate reporting templates with entity-specific information

Cross-Border Incident Reporting

Many entities operate across multiple Member States, and incidents frequently have cross-border dimensions. NIS2 addresses this through several mechanisms:

Multi-Member-State Reporting

If an entity provides services in more than one Member State and the incident affects services in multiple jurisdictions, the entity must report to the CSIRT in each affected Member State. In practice:

• The early warning should indicate cross-border potential
• Parallel reports should be submitted to each relevant CSIRT
• The entity should designate a single internal incident commander to ensure consistency across filings

CSIRT Coordination

The CSIRTs Network (established under Article 15) facilitates cross-border coordination. When a CSIRT receives a report with cross-border implications, it:

• Notifies other affected Member State CSIRTs without undue delay
• Shares relevant technical details and IoCs
• Coordinates response measures through the single point of contact

EU-CyCLONe

For large-scale cross-border incidents, the European Cyber Crises Liaison Organisation Network (EU-CyCLONe) supports coordinated management at the operational level. Entities are unlikely to interact with EU-CyCLONe directly, but should be aware that their incident reports may feed into this mechanism if the scale warrants it.

Voluntary Reporting for Non-Significant Incidents

Article 30 of NIS2 permits entities to voluntarily notify the CSIRT of incidents, cyber threats, or near-misses that do not meet the "significant incident" threshold. Voluntary reporting is encouraged because it:

• Strengthens the CSIRT's threat intelligence picture
• May help other entities prepare for emerging threats
• Demonstrates a mature, proactive security posture
• Builds a positive relationship with the CSIRT ahead of any mandatory reporting

Voluntary reports are processed on the same basis as mandatory ones, but no penalties attach to the content or timing of voluntary submissions. Entities that report voluntarily are not subjected to additional obligations solely as a result of reporting.

NIS2 vs GDPR Breach Notification: Key Differences

Many incidents — particularly ransomware attacks and data breaches — trigger obligations under both NIS2 and the GDPR. Understanding the differences is essential for managing parallel reporting streams.

Building an Incident Reporting Capability

Compliance with Article 23 requires more than a template. Organisations need an end-to-end capability that spans detection, classification, escalation, reporting, and follow-up.

1. Detection

You cannot report what you do not detect. NIS2-compliant detection requires:

• Security monitoring: SIEM/SOAR platforms with use cases aligned to NIS2 significant-incident criteria
• Endpoint detection and response (EDR): Visibility across endpoints to detect lateral movement and data exfiltration
• Network monitoring: Anomaly detection, intrusion detection/prevention systems (IDS/IPS)
• Log aggregation: Centralised, tamper-evident logging with sufficient retention (NIS2 does not prescribe a specific period, but 12 months is a reasonable baseline)
• Threat intelligence feeds: Contextual enrichment of alerts to identify campaigns targeting your sector

2. Classification

Once an event is detected, the incident classification framework (see above) determines whether it meets the "significant incident" threshold. Key elements:

• Pre-defined classification criteria documented in the incident response procedure
• Decision tree or flowchart for rapid classification (aim for <30 minutes)
• Designated personnel authorised to make the classification decision
• Escalation path if classification is uncertain (default: treat as significant)

3. Escalation

The 24-hour clock demands rapid escalation. Build an escalation matrix that includes:

• SOC/security team → Incident commander (on-call rotation)
• Incident commander → CISO / Head of IT
• CISO → Senior management and legal counsel
• Designated reporter → CSIRT (via pre-established channel)
• DPO (if personal data involved) → DPA under GDPR

4. Reporting

The reporting function should be operationalised with:

• Pre-populated templates for each reporting stage (see checklists above)
• CSIRT contact details and submission mechanisms (secure portal, encrypted e-mail, or dedicated hotline) pre-configured
• A designated reporter and deputy who have been trained on the process
• A secure internal tracker that logs all submissions, timestamps, and acknowledgements

5. Follow-Up

After reporting, the entity must:

• Respond to any requests for information from the CSIRT or competent authority
• Submit intermediate and final reports within the prescribed timelines
• Implement the CSIRT's recommendations where applicable
• Conduct and document a formal post-incident review
• Update the incident response procedure based on lessons learnt

Reporting Checklists by Stage

Use these checklists to ensure completeness at each stage of the reporting process.

Pre-Incident Preparedness Checklist

• CSIRT/competent authority contact details confirmed and tested
• Reporting templates pre-populated with entity information
• Designated reporter and deputy assigned and trained
• Incident classification criteria documented and approved
• Escalation matrix documented with contact details for all on-call personnel
• Legal counsel briefed on dual NIS2/GDPR obligations
• Cross-border reporting procedures documented (if multi-Member-State operations)
• Reporting process tested within the last 12 months

24-Hour Early Warning Checklist

• Incident detected and classified as significant (or potentially significant)
• Incident commander designated
• Early warning template completed
• Malicious/unlawful cause assessment included
• Cross-border potential assessment included
• Report submitted to designated CSIRT/competent authority
• Submission timestamp and acknowledgement recorded
• Internal stakeholders notified (CISO, legal, executive sponsor)

72-Hour Notification Checklist

• Early warning reference number included
• Updated description of incident provided
• Severity and impact assessment completed
• IoCs shared (where available)
• GDPR parallel reporting confirmed (if personal data involved)
• Cross-border update provided
• Customer/user communication plan confirmed
• Report submitted and acknowledged

Final Report Checklist

• Complete incident timeline documented
• Root cause confirmed with evidence
• Full impact assessment (operational, financial, reputational)
• All mitigation measures documented (applied and ongoing)
• Cross-border impact confirmed
• Lessons learnt recorded
• IoC package finalised for CSIRT sharing
• Report submitted within 1 month of notification (or 1 month of resolution for ongoing incidents)

Testing and Exercising the Reporting Process

A reporting process that has never been tested is a process that will fail under pressure. NIS2 Article 21(2)(c) requires entities to implement "business continuity" measures, and Article 21(2)(f) requires "policies and procedures to assess the effectiveness of cybersecurity risk-management measures." Incident reporting exercises fulfil both requirements.

Types of Exercises

• Tabletop exercises: Scenario-based discussions where participants walk through an incident narrative and discuss decisions. Low cost, high value for testing classification and escalation logic.
• Functional drills: Timed drills that test specific elements — e.g., "Can we submit a complete early warning within 60 minutes of incident declaration?"
• Full-scale simulations: End-to-end exercises simulating a real incident across detection, classification, escalation, reporting, and recovery. These may involve the CSIRT as an exercise participant.
• Announced vs unannounced: Unannounced exercises (where only exercise controllers know) provide the most realistic test of response capability.

Exercise Frequency

• Tabletop exercises: at least twice per year
• Functional drills: at least annually
• Full-scale simulation: at least every two years, or annually for Essential entities
• After any significant process change or personnel turnover in the incident response team

Post-Exercise Actions

• Document findings and improvement actions
• Update templates, contact lists, and escalation matrices
• Brief senior management on exercise outcomes
• Track corrective actions to closure

Common Mistakes in NIS2 Incident Reporting

Based on experience with early NIS2 adopters and NIS1 reporting lessons, the following mistakes are frequently observed:

1. Waiting for certainty before reporting: The 24-hour clock starts at awareness, not at confirmation. Delaying the early warning until root cause is confirmed is the single most common violation.
2. Confusing NIS2 and GDPR timelines: The NIS2 early warning is 24 hours (not 72). Organisations accustomed to GDPR's 72-hour deadline sometimes assume the same applies to NIS2.
3. No pre-established CSIRT relationship: Entities that have never contacted their CSIRT before the first real incident waste critical time establishing communication channels.
4. Incomplete classification criteria: Without pre-defined thresholds, the "significant or not?" debate consumes hours that should be spent on containment and reporting.
5. Single point of failure in reporting personnel: If only one person knows the process and they are unavailable, the obligation is missed. Always designate a deputy.
6. Forgetting cross-border obligations: Entities operating in multiple Member States may report to one CSIRT but neglect others.
7. Treating the final report as optional: Some entities submit the early warning and notification but fail to follow through with the final report. This is a compliance failure.
8. Failing to preserve evidence: In the rush to restore services, forensic evidence is destroyed. Ensure evidence preservation is built into the response process before eradication begins.
9. Not documenting the decision not to report: If an incident is assessed as non-significant, document the classification rationale. This protects the entity if the assessment is later challenged.
10. Ignoring voluntary reporting opportunities: Near-misses and below-threshold incidents provide valuable intelligence. Voluntary reporting builds goodwill with the CSIRT.

Penalties for Failure to Report

NIS2 introduces significant penalties for non-compliance with incident reporting obligations. The penalty framework distinguishes between Essential and Important entities:

Penalties apply not only to failure to report but also to late reporting. Submitting an early warning at hour 30 instead of hour 24 is technically non-compliant, even if the content is adequate. The seriousness of the penalty will, however, take into account factors such as the gravity, duration, and consequences of the non-compliance.

For Essential entities, competent authorities may go beyond fines: they can temporarily suspend or prohibit a natural person who holds managerial responsibility from exercising their functions. This personal liability provision is intended to ensure that senior management takes incident reporting obligations seriously.

Frequently Asked Questions

What counts as a significant incident under NIS2?

A significant incident is one that has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The test covers both actual and potential impact — you cannot wait for harm to materialise before classifying an incident as significant.

How quickly must I report an incident under NIS2?

NIS2 requires a 3-stage process: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours with an updated assessment, and a final report within one month of the incident notification. If the incident is ongoing at the one-month mark, an intermediate progress report is required instead, with the final report due within one month of resolution.

Who do I report NIS2 incidents to?

Incidents must be reported to the designated CSIRT (Computer Security Incident Response Team) or, where applicable, the competent authority in the Member State where the entity provides its services. If the entity operates across multiple Member States, it must report to the CSIRT in each Member State where services are affected. Check your national transposition law for the specific reporting channel.

What is the difference between NIS2 and GDPR breach notification?

NIS2 focuses on significant incidents affecting network and information systems and requires an early warning to the CSIRT within 24 hours. GDPR focuses on personal data breaches and requires notification to the Data Protection Authority within 72 hours. An incident may trigger both obligations simultaneously — for example, a ransomware attack on a hospital affecting patient records. Organisations must maintain parallel processes and ensure consistent reporting across both regimes.

What penalties apply for failure to report incidents under NIS2?

For Essential entities, penalties can reach up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. For Important entities, penalties can reach up to EUR 7 million or 1.4% of total worldwide annual turnover. Member States may also impose periodic penalty payments. For Essential entities, competent authorities may additionally request the temporary suspension of managerial functions for individuals responsible for the non-compliance.