How to implement NIS2 incident reporting using AI

Overview

You'll learn how to use AI to build a complete NIS2 incident reporting capability aligned with Article 23. This guide covers incident significance criteria, the mandatory 24-hour/72-hour/one-month reporting workflow, early warning templates, incident notification formats with indicators of compromise (IOCs), final report structure with root cause analysis, voluntary reporting of threats and near-misses, and integration with your national CSIRT.

Who this is for

This guide is for:

• Incident response managers and SOC leads building NIS2-compliant reporting workflows

• CISOs responsible for establishing incident reporting capabilities that meet Article 23 timelines

• Compliance officers who need to ensure reporting procedures satisfy supervisory authorities

• Security consultants implementing incident reporting for clients across NIS2-regulated sectors

• Management body members who must understand their notification obligations and oversight responsibilities

Before you begin

You will need:

• An ISMS Copilot account (free trial available)

• Your NIS2 entity classification (essential or important) -- see How to Get Started with NIS2 Implementation Using AI

• Contact details for your national CSIRT and competent authority

• Your Incident Response Policy (see How to Create NIS2 Cybersecurity Policies Using AI for generation guidance)

• Understanding of your critical services and systems from your risk assessment (see How to Conduct NIS2 Risk Assessment Using AI)

Understanding NIS2 incident reporting requirements

What Article 23 demands

Article 23 of the NIS2 Directive establishes a multi-stage notification framework for significant incidents. Each stage has specific content requirements and deadlines.

Reporting stage

Deadline

Content requirements

Recipient

Early warning

Within 24 hours of becoming aware

Indication of whether the incident is suspected to be caused by unlawful or malicious acts; indication of whether it could have cross-border impact

National CSIRT or competent authority

Incident notification

Within 72 hours of becoming aware

Update to early warning; initial assessment of severity and impact; indicators of compromise (IOCs) where available

National CSIRT or competent authority

Intermediate report

Upon request of CSIRT or competent authority

Relevant status updates on incident handling and recovery

National CSIRT or competent authority

Final report

Within one month of the incident notification

Detailed description of incident including severity and impact; type of threat or root cause; applied and ongoing mitigation measures; cross-border impact (if applicable)

National CSIRT or competent authority

Progress report (for ongoing incidents)

At the one-month mark if incident is still ongoing

Progress update in lieu of final report; final report due within one month of incident resolution

National CSIRT or competent authority

What makes an incident "significant"

Article 23(3) defines a significant incident as one that:

• (a) Has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned

• (b) Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

The European Commission may further specify incident significance criteria through implementing acts. National transposition laws may also define additional or more specific thresholds. Your organization must establish internal classification criteria that align with these definitions.

Voluntary reporting

Article 23 also encourages voluntary reporting of:

• Near-misses (incidents that could have caused significant impact but were prevented or detected early)

• Significant cyber threats that could potentially cause significant incidents

• Information that could help prevent or respond to incidents affecting other entities

Step 1: Build your incident classification matrix

Defining significance thresholds

Before you can report incidents, you need clear, unambiguous criteria for determining when an incident crosses the "significant" threshold and triggers NIS2 reporting obligations.

1. Generate the classification matrix:

   "Create a comprehensive incident classification matrix for NIS2 Article 23 compliance at our [sector] organization (classified as [essential/important] entity). The matrix should include: four severity levels (Critical, High, Medium, Low) with clear criteria for each. For each level, define: operational impact thresholds (service disruption duration, percentage of users affected, degradation level), financial impact thresholds (direct costs, potential regulatory penalties, revenue loss), data impact thresholds (records exposed, data types affected, confidentiality/integrity/availability impact), third-party impact (number of entities affected, sector-wide impact potential), and reputational impact. Clearly mark which severity levels constitute a 'significant incident' under Article 23(3) and trigger mandatory reporting. Include sector-specific examples for [sector]."

2. Create the triage decision tree:

   "Create a decision tree for first responders to quickly determine whether an incident is 'significant' under NIS2 Article 23 and requires reporting. The decision tree should be usable within 30 minutes of incident detection. Include yes/no questions covering: (1) Is service delivery affected or at risk? (2) Does the incident affect critical systems or data? (3) Could it impact other entities or persons? (4) Is there evidence of malicious or unlawful activity? (5) Could there be cross-border impact? Map each path to a classification level and the required response actions."

3. Generate sector-specific significance examples:

   "Generate 15 realistic incident scenarios for a [sector] organization and classify each as significant or non-significant under NIS2 Article 23(3). For each scenario, explain the classification rationale. Include scenarios that are borderline to illustrate where judgment calls are needed. This will serve as a training reference for our incident response team."

Step 2: Create the 24-hour early warning workflow and template

Understanding early warning requirements

The early warning is your first communication to the national CSIRT or competent authority. It must be submitted within 24 hours of becoming aware of a significant incident. The content requirements are deliberately minimal to enable rapid reporting -- you are not expected to have a complete picture at this stage.

1. Generate the early warning template:

   "Create a NIS2 Article 23 early warning report template for our [sector] organization. The template must include all fields required within the 24-hour window: reporting entity identification (name, NIS2 registration number, sector, entity classification), incident identifier (internal reference number), date and time of awareness, brief incident description (what happened, what systems/services are affected), whether the incident is suspected to be caused by unlawful or malicious acts (yes/no/unknown with rationale), whether it could have cross-border impact (yes/no/unknown with rationale), initial scope assessment (services affected, geographic scope), contact person for follow-up (name, role, phone, email, secure communication channel), and any immediate actions taken. Format as a form that can be completed in 15 minutes."

2. Build the early warning workflow:

   "Create a step-by-step workflow for submitting the NIS2 24-hour early warning, from incident detection to report submission. Include: (1) detection and initial triage (target: 2 hours), (2) significance assessment using our classification matrix (target: 1 hour), (3) notification of incident manager and CSIRT liaison (target: 30 minutes), (4) early warning report completion (target: 30 minutes), (5) internal approval (CISO or designated authority) (target: 1 hour), (6) submission to national CSIRT via [specify channel], (7) internal documentation and tracking. Include time targets for each step that ensure the 24-hour deadline is met with margin. Specify who is responsible for each step, escalation procedures if responsible persons are unavailable, and after-hours procedures."

Step 3: Create the 72-hour incident notification workflow and template

Understanding notification requirements

The 72-hour incident notification updates the early warning with additional detail. By this stage, your investigation should have progressed enough to provide an initial assessment of severity, impact, and indicators of compromise.

1. Generate the incident notification template:

   "Create a NIS2 Article 23 incident notification template (72-hour report) for our organization. Include all required fields: reference to the early warning report, updated incident description with additional detail, initial assessment of incident severity (using our classification matrix), assessment of impact -- services affected, number of users/entities impacted, duration of disruption, indicators of compromise (IOCs) where available -- IP addresses, domains, file hashes, malware signatures, TTPs (Tactics, Techniques, Procedures) observed, attack vector identification (if known at this stage), affected systems and networks, initial containment and mitigation measures taken, assessment of cross-border impact, assessment of whether the incident was caused by unlawful or malicious acts, and any assistance requested from CSIRT. Include an appendix section for technical IOC details."

2. Build the IOC collection procedure:

   "Create a procedure for collecting and formatting indicators of compromise (IOCs) for NIS2 incident notification. Cover: types of IOCs to collect (network indicators, host indicators, email indicators, file indicators), collection methods and tools, evidence preservation and chain of custody, IOC formatting standards (STIX/TAXII where applicable), classification of IOCs (TLP marking -- Traffic Light Protocol), what to include in the 72-hour report versus what to share separately with CSIRT, and how to handle sensitive IOCs that could reveal internal architecture."

3. Build the 72-hour notification workflow:

   "Create a detailed workflow for the NIS2 72-hour incident notification. Include: investigation activities to complete within the 72-hour window (log analysis, forensic triage, IOC extraction, impact assessment), evidence collection and preservation steps, report drafting process with input from technical team/legal/communications, internal review and approval chain, submission procedure to national CSIRT, stakeholder notification (management body, affected parties, law enforcement if applicable), and documentation requirements. Specify roles, time targets, and escalation procedures."

Step 4: Create the one-month final report workflow and template

Understanding final report requirements

The final report is the most comprehensive submission and must include a detailed description of the incident, root cause analysis, and mitigation measures. If the incident is still ongoing at the one-month mark, submit a progress report and deliver the final report within one month of incident resolution.

1. Generate the final report template:

   "Create a NIS2 Article 23 final incident report template for our [sector] organization. Include all required sections: (1) Executive Summary (one-page overview for management and authority review), (2) Incident Timeline (chronological sequence from first indicators through detection, reporting, containment, eradication, and recovery, with timestamps), (3) Detailed Incident Description (systems affected, attack vector, threat actor assessment, data impacted), (4) Severity and Impact Assessment (final assessment of operational, financial, data, and third-party impact using our classification matrix), (5) Root Cause Analysis (technical root cause, contributing factors, systemic weaknesses that enabled the incident), (6) Indicators of Compromise (complete IOC list with classifications), (7) Applied Mitigation Measures (immediate containment, eradication actions, recovery steps), (8) Ongoing Mitigation Measures (long-term fixes, control improvements, monitoring enhancements), (9) Cross-Border Impact Assessment, (10) Lessons Learned and Preventive Recommendations, (11) Appendices (technical evidence, timeline details, IOC details). Format for submission to national CSIRT."

2. Generate the root cause analysis methodology:

   "Create a root cause analysis (RCA) methodology for NIS2 incident final reports. Include: RCA techniques suitable for cybersecurity incidents (Five Whys, Fishbone/Ishikawa, Fault Tree Analysis), how to distinguish between proximate cause and root cause, template for documenting the RCA process and findings, how to identify contributing factors (technical, process, human, organizational), how to derive corrective and preventive actions from root causes, and how to present RCA findings to both technical audiences and the management body."

3. Build the progress report template for ongoing incidents:

   "Create a NIS2 progress report template for incidents still ongoing at the one-month mark. Include: reference to original early warning and notification, current incident status and response phase, updated impact assessment, actions taken since last report, ongoing containment and eradication measures, estimated timeline for resolution, and any updated IOCs or threat intelligence."

Step 5: Build incident response playbooks

Scenario-specific playbooks with NIS2 reporting integrated

Playbooks translate your incident response policy and reporting workflows into specific, actionable procedures for common incident types. Each playbook should integrate NIS2 reporting milestones into the response workflow.

1. Generate a ransomware playbook:

   "Create a comprehensive ransomware incident response playbook for our [sector] organization with NIS2 Article 23 reporting integrated. Include: detection triggers and initial indicators, immediate containment actions (network isolation, credential rotation), NIS2 significance assessment (ransomware affecting essential/important services is almost always significant), 24-hour early warning trigger and completion, evidence preservation (do not power off encrypted systems, capture memory), forensic investigation steps, IOC extraction for 72-hour notification, eradication steps (malware removal, access vector closure), recovery from offline backups, data exfiltration assessment, 72-hour notification completion with IOCs, law enforcement coordination, ransom payment decision framework, service restoration verification, one-month final report with root cause analysis, and post-incident improvements."

2. Generate a data breach playbook:

   "Create a data breach incident response playbook with NIS2 Article 23 and GDPR Article 33/34 reporting integrated. Cover: detection and data exposure assessment, scope determination (what data, how many records, what categories), NIS2 significance assessment, 24-hour early warning, containment of unauthorized access, GDPR 72-hour notification assessment (parallel to NIS2 reporting), IOC collection and 72-hour NIS2 notification, affected individual notification assessment (GDPR Article 34), forensic investigation and evidence preservation, one-month NIS2 final report, and coordination between NIS2 CSIRT reporting and GDPR DPA notification."

3. Generate a DDoS attack playbook:

   "Create a DDoS incident response playbook for our [sector] organization with NIS2 reporting. Cover: detection (traffic anomalies, service degradation monitoring), initial assessment (volumetric, protocol, or application layer attack), NIS2 significance assessment (is service delivery to users/dependent entities affected?), 24-hour early warning if significant, DDoS mitigation activation (upstream filtering, CDN, scrubbing services), ongoing service monitoring, IOC collection (source IPs, attack signatures, patterns), 72-hour notification if applicable, investigation of DDoS as potential distraction for secondary attack, and post-incident analysis."

4. Generate a supply chain compromise playbook:

   "Create a supply chain compromise incident response playbook with NIS2 reporting. Cover: detection of supplier compromise (vendor notification, anomalous behavior from trusted software/services), impact assessment on our systems and data, NIS2 significance assessment (supply chain compromise often has cross-border implications), 24-hour early warning with cross-border impact assessment, containment (isolate affected supplier connections, revoke credentials, block compromised updates), coordination with the compromised supplier, assessment of lateral movement, IOC extraction and sharing, 72-hour notification, notification of downstream entities we serve, and one-month final report with supply chain lessons learned."

5. Generate sector-specific playbooks:

   "Create an [OT/ICS compromise | healthcare system disruption | financial system breach | energy grid incident] response playbook specific to our [sector] with NIS2 reporting integrated. Address sector-specific considerations such as [safety implications, patient impact, financial market stability, energy supply continuity] and coordination with sector-specific authorities."

Step 6: Establish CSIRT integration and communication channels

Connecting with your national CSIRT

NIS2 requires reporting to your national CSIRT (Computer Security Incident Response Team) or designated competent authority. Each EU member state has designated specific authorities and established reporting mechanisms.

1. Identify your reporting authority:

   "Help me identify the NIS2 competent authority and CSIRT for [member state]. Provide: the official name and contact information, the reporting portal or submission method, any specific report formats required by this member state's transposition law, registration requirements, and any sector-specific reporting channels that may apply to our [sector]."

2. Create the CSIRT communication procedure:

   "Create a CSIRT communication procedure for our NIS2 incident reporting. Cover: primary and backup submission methods (online portal, email, phone), secure communication channels for sharing sensitive IOCs, designated CSIRT liaison persons (primary and backup, with 24/7 coverage), escalation procedures if CSIRT communication channels are unavailable, handling of CSIRT guidance and instructions received during incident response, information classification and handling (what can be shared, TLP markings), and coordination with CSIRT for multi-entity incidents."

Step 7: Build voluntary reporting procedures

Near-miss and threat reporting

NIS2 encourages (but does not mandate) voluntary reporting of near-misses, significant cyber threats, and information that could help prevent incidents affecting other entities. Establishing voluntary reporting demonstrates mature security governance and builds goodwill with supervisory authorities.

1. Generate a voluntary reporting procedure:

   "Create a voluntary incident and threat reporting procedure for NIS2 compliance. Cover: definition of reportable near-misses (incidents prevented by controls, detected phishing campaigns, blocked intrusion attempts), definition of reportable threats (intelligence on imminent threats to our sector, newly discovered vulnerabilities in widely-used systems), reporting format for voluntary notifications (lighter than mandatory reports, focused on actionable intelligence), internal process for deciding when to submit voluntary reports, anonymization considerations where applicable, and benefits of voluntary reporting (relationship with CSIRT, sector intelligence sharing)."

Step 8: Implement reporting metrics and continuous improvement

Measuring incident reporting effectiveness

Article 21(2)(f) requires assessment of the effectiveness of your cybersecurity measures. Your incident reporting capability should be regularly measured and improved.

1. Define reporting KPIs:

   "Create a set of KPIs for measuring the effectiveness of our NIS2 incident reporting capability. Include: mean time to detect significant incidents, mean time from detection to early warning submission, percentage of early warnings submitted within 24 hours, percentage of notifications submitted within 72 hours, percentage of final reports submitted within one month, quality score for report completeness and accuracy, number of incidents correctly classified as significant vs non-significant, tabletop exercise performance scores, time to establish CSIRT communication during incidents, and management body reporting frequency on incident metrics."

2. Create the post-incident review procedure:

   "Create a post-incident review procedure that specifically evaluates our NIS2 reporting performance. After each significant incident (and selected non-significant incidents), review: (1) was the incident correctly classified for NIS2 significance? (2) were all reporting timelines met? (3) was the report content complete and accurate? (4) was CSIRT communication effective? (5) were all internal stakeholders notified appropriately? (6) what improvements are needed in our detection, triage, or reporting workflows? Document findings and track corrective actions."

Common incident reporting challenges and solutions

Challenge

Risk

Solution

Unclear significance criteria

Late reporting or over-reporting

Implement the classification matrix and decision tree with sector-specific examples

No after-hours coverage

Missing the 24-hour deadline for incidents detected outside business hours

Establish 24/7 on-call rotation with authority to submit early warnings

IOC collection gaps

Incomplete 72-hour notification

Integrate IOC collection into standard forensic procedures; pre-configure collection tools

Root cause analysis depth

Final reports that fail to satisfy supervisory authorities

Use structured RCA methodology; look beyond proximate cause to systemic factors

GDPR/NIS2 coordination

Duplicate or conflicting notifications to different authorities

Create unified notification workflow that addresses both NIS2 and GDPR requirements

CSIRT communication failure

Cannot submit reports during a major incident

Establish backup communication channels; test regularly

Legal concerns about disclosure

Delayed reporting due to legal review bottlenecks

Pre-approve reporting templates; involve legal in playbook development, not per-incident approval

Next steps

With your incident reporting capability established, you have addressed one of the most time-sensitive and scrutinized areas of NIS2 compliance.

Continue with the next guide in this series:

• Supply chain security: See How to Manage NIS2 Supply Chain Security Using AI for building the supply chain risk management capability required by Article 21(2)(d) -- including how supply chain incidents feed into your reporting workflows

If you have not yet completed earlier steps, see:

• How to Get Started with NIS2 Implementation Using AI for scoping and governance setup

• How to Conduct NIS2 Risk Assessment Using AI for the risk assessment that informs your incident classification

• How to Create NIS2 Cybersecurity Policies Using AI for the policy framework that governs your incident response

For ready-to-use incident reporting prompts, explore the NIS2 Directive Prompt Library. For a comprehensive overview of all NIS2 requirements, see the NIS2 Compliance Guide for In-Scope Companies.

Getting help

For additional support with NIS2 incident reporting:

• Ask ISMS Copilot: Use your NIS2 workspace for incident reporting questions, template customization, and playbook development

• Simulate incidents: Ask ISMS Copilot to generate realistic incident scenarios for tabletop exercises and team training

• Review reports: Upload draft incident reports and ask for completeness review against Article 23 requirements

• National requirements: Ask about specific reporting formats, portals, or additional requirements imposed by your member state's transposition law