NIS2 Incident Response Playbook
24-Hour Early Warning & 72-Hour Detailed Notification Procedures
Article 23 Incident Notification Requirements
Paolo Carner, BARE Consulting

Document Purpose
This playbook provides detailed procedures for managing cybersecurity incidents under NIS2 Directive Article 23 notification requirements. It is designed to enable organizations to meet the mandatory 24-hour early warning and 72-hour detailed notification deadlines while maintaining effective incident response operations.
Scope & Applicability
This playbook applies to:
 •	Essential entities and important entities as defined under NIS2
 •	Cybersecurity incidents with significant impact on service delivery
 •	Incidents meeting notification thresholds per Article 23(3)
Key Regulatory Requirements
NIS2 Article 23 establishes three notification timelines:
 •	24 hours (Early Warning): Initial notification upon becoming aware of a significant incident
 •	72 hours (Detailed Report): Incident notification providing initial assessment, severity, and indicators of compromise
 •	One month (Final Report): Final report including detailed analysis, impact, and remediation measures
CRITICAL: Timelines begin when the organization becomes aware of the incident, not when investigation completes. Delays in notification may result in regulatory penalties.

Incident Classification Framework
Rapid and accurate incident classification is essential for determining notification obligations and response priorities. Classification must occur within the first hour of incident awareness.
Severity Levels
Level	Impact	Examples	NIS2 Notification	
CRITICAL	Severe disruption to essential services; major data breach; operational shutdown	Ransomware encryption of critical systems; loss of service availability >4 hours; exfiltration of sensitive data	REQUIRED
24h early warning + 72h report	
HIGH	Significant service degradation; unauthorized access to systems; potential data exposure	DDoS affecting performance; privilege escalation; compromise of critical vendor	LIKELY REQUIRED
Assess against Article 23(3) thresholds	
MEDIUM	Limited service impact; contained security event; minor policy violations	Malware on isolated workstation; failed phishing attempt; minor misconfigurations	Not typically required unless cross-border impact or critical infrastructure	
LOW	No service impact; routine security events; informational findings	Security scan alerts; blocked attacks; policy violations without compromise	Not required; manage through normal security operations	
When in doubt about notification requirements, consult with legal counsel or information security officer. Over-notification is preferable to under-notification given enforcement risks.
Article 23(3) Notification Thresholds
Incidents must be reported if they have caused or are capable of causing:
 •	Severe operational disruption: Services unavailable or degraded for significant period
 •	Considerable financial loss: Direct costs or business interruption
 •	Material impact: On individuals, organizations, or other entities through availability, authenticity, integrity, or confidentiality impacts

Incident Response Process Overview
The NIS2 incident response process consists of seven phases executed in parallel with notification obligations. Time-critical activities must be prioritized to meet regulatory deadlines.
Phase	Objectives	Key Activities	NIS2 Requirements	SLA	
1. Detection	Identify potential security incident through monitoring, alerts, or reports	Log analysis, alert triage, user reports, third-party notifications	Clock starts when organization becomes aware	—	
2. Classification	Determine severity and notification requirements	Severity assessment, threshold evaluation, stakeholder notification	Assess against Article 23(3) thresholds	1 hr	
3. Early Warning	Submit initial notification to CSIRT	Gather minimum required information; submit via designated channel	Article 23(4) early warning	24 hr	
4. Containment	Stop incident progression and prevent further damage	Isolate systems, block threats, preserve evidence	Document for 72-hour report	Ongoing	
5. Investigation	Determine root cause, scope, and impact	Forensic analysis, timeline reconstruction, impact assessment	Information for detailed notification	Ongoing	
6. Detailed Report	Submit comprehensive incident notification	Compile findings; complete notification form; submit to CSIRT	Article 23(4) detailed notification	72 hr	
7. Recovery	Restore normal operations and implement improvements	Service restoration, remediation, lessons learned	Final report within one month	Ongoing	

Phase 1: Detection
Effective incident detection requires multiple monitoring capabilities and clear escalation procedures. The clock for NIS2 notification begins when the organization becomes aware of the incident, making early detection critical.
Detection Sources
 •	Automated monitoring: SIEM alerts, IDS/IPS, antivirus, endpoint detection, network monitoring
 •	User reports: Employee notifications of suspicious activity via helpdesk or security email
 •	Third-party notifications: Vendor alerts, partner reports, customer complaints, law enforcement contact
 •	Threat intelligence: Industry warnings, dark web monitoring, vulnerability disclosures
Initial Response Procedure
Upon detection of a potential incident:
 1.	Document time of awareness: Record exact time organization became aware (this starts NIS2 clock)
 2.	Assign incident ID: Create unique identifier (e.g., INC-2025-001)
 3.	Notify incident response team: Alert on-call responders via designated channel
 4.	Activate incident response: Initiate incident tracking and documentation procedures
 5.	Begin initial triage: Gather preliminary information for classification
CRITICAL: The 24-hour clock starts when the organization becomes aware, even if the incident is still being investigated. Do not delay classification pending complete information.

Phase 2: Classification & Notification Decision
Classification must occur within one hour of detection to allow adequate time for notification preparation. The classification determines response priority and regulatory obligations.
Classification Procedure
Complete the following assessment within 60 minutes:
 1.	Assess service impact: Is essential service delivery disrupted or degraded?
 2.	Evaluate data exposure: Is sensitive data compromised (availability, integrity, confidentiality)?
 3.	Estimate financial impact: Potential direct costs and business interruption
 4.	Determine cross-border implications: Does incident affect services in multiple member states?
 5.	Identify affected stakeholders: Which individuals, organizations, or entities are impacted?
 6.	Assign severity level: Critical, High, Medium, or Low per classification matrix
 7.	Determine notification requirement: Does incident meet Article 23(3) thresholds?
Notification Decision Authority
The following roles have authority to make notification decisions:
 •	Primary: Chief Information Security Officer (CISO) or equivalent
 •	Secondary: Incident Response Manager or Security Operations Center Manager
 •	Escalation: Chief Technology Officer, Chief Operating Officer, or designated management representative
Note: When classification is uncertain or borderline, default to notifying. Legal counsel should be consulted for complex cases, but legal review must not delay meeting the 24-hour deadline.
Stakeholder Notification (Internal)
For incidents requiring NIS2 notification, immediately inform:
 •	Management: Chief Executive Officer, relevant C-level executives
 •	Legal: General Counsel or external counsel for regulatory guidance
 •	Communications: Corporate communications for potential public/customer notification
 •	Compliance: Data Protection Officer if GDPR breach notification may also be required

Phase 3: 24-Hour Early Warning Notification
Article 23(4) requires an early warning within 24 hours of becoming aware of a significant incident. This notification provides CSIRT with immediate awareness but does not require complete investigation results.
DEADLINE: Submit early warning notification within 24 hours of time organization became aware of the incident. Missing this deadline may result in regulatory penalties.
Required Information (Early Warning)
The early warning notification must include, to the extent available:
 •	Entity information: Organization name, contact details, NIS2 registration ID (if assigned)
 •	Incident identifier: Unique internal reference number
 •	Time of awareness: When organization became aware of the incident
 •	Incident type: General category (e.g., ransomware, data breach, DDoS, unauthorized access)
 •	Affected services: Which essential or important services are impacted
 •	Preliminary assessment: Initial understanding of scope and severity
 •	Point of contact: Individual managing incident response (name, role, phone, email)
Submission Procedure
Complete the following steps within the 24-hour window:
 1.	Gather available information: Collect required details (may be incomplete; update in 72-hour report)
 2.	Complete notification form: Use CSIRT-designated format or template
 3.	Obtain internal approval: CISO or designated authority must review and approve
 4.	Submit via designated channel: Use CSIRT notification portal, email, or phone as specified
 5.	Retain confirmation: Document submission timestamp and confirmation receipt
 6.	Update internal stakeholders: Inform management and relevant teams that notification was submitted
Regional Notification Contacts
Belgium
CSIRT Contact: Centre for Cybersecurity Belgium (CCB)
 •	Notification Portal: https://ccb.belgium.be (check current URL)
 •	Email: cert@ccb.belgium.be
 •	Phone: Check CCB website for current 24/7 hotline
Netherlands
Expected CSIRT Contact: National Cyber Security Centre (NCSC-NL)
 •	Current Contact: https://www.ncsc.nl/contact/kwetsbaarheid-melden
 •	Note: Specific NIS2 notification procedures to be established upon implementation (expected Q2 2026)
Organizations should verify current contact information and bookmark notification portals in advance. Test notification procedures during incident response exercises.

Phase 4: Containment
Containment actions occur in parallel with notification activities. The goal is to limit incident impact while preserving evidence needed for investigation and regulatory reporting.
Containment Strategy Selection
Choose containment approach based on incident type and business impact:
 •	Short-term containment: Immediate actions to halt attack progression (network isolation, account disabling)
 •	Long-term containment: Temporary fixes to restore limited operations while preparing permanent remediation
 •	Evidence preservation: Balance containment speed with forensic integrity requirements
Containment Actions by Incident Type
Incident Type	Immediate Actions	Evidence Preservation	
Ransomware	• Isolate infected systems from network
• Disable user accounts if credential compromise suspected
• Block command-and-control communications
• Preserve ransom note and communications	Disk images before remediation; memory captures; network traffic logs; ransom communications	
Data Breach / Exfiltration	• Block external data transfers
• Revoke compromised credentials
• Disable affected accounts and services
• Monitor for additional exfiltration attempts	Proxy/firewall logs; authentication logs; file access logs; email records	
DDoS Attack	• Activate DDoS mitigation service
• Implement rate limiting
• Filter malicious traffic sources
• Scale infrastructure if possible	Network flow data; attack signatures; source IPs; traffic patterns	
Unauthorized Access	• Disable compromised accounts
• Force password resets
• Revoke active sessions
• Restrict access to affected systems	Authentication logs; access logs; privilege escalation evidence; lateral movement indicators	
vCISO expertise is particularly valuable during containment for: determining appropriate isolation strategies that balance security with business continuity; coordinating technical response across teams; and making risk-based decisions on containment scope.

Phase 5: Investigation & Evidence Collection
Investigation begins during containment and continues through recovery. The goal is to determine root cause, full scope, and impact for the 72-hour detailed notification and final report.
Investigation Objectives
 •	Root cause analysis: How did the incident occur? What vulnerability was exploited?
 •	Timeline reconstruction: When did the incident begin? What was the attack progression?
 •	Scope determination: Which systems were compromised? What data was affected?
 •	Impact assessment: Service disruption duration, data confidentiality breach, financial impact
 •	Indicator identification: Compromised indicators, threat actor TTPs, indicators of compromise
Evidence Collection Checklist
Collect and preserve the following evidence types:
 •	System evidence: Disk images, memory dumps, system configurations, installed software lists
 •	Log evidence: System logs, application logs, security logs, authentication logs, network flow data
 •	Network evidence: Packet captures, firewall logs, IDS/IPS alerts, DNS queries, proxy logs
 •	File evidence: Malware samples, suspicious files, modified files, deleted file recovery
 •	Communications: Phishing emails, ransom notes, attacker communications, user reports
 •	Documentation: Incident timeline, actions taken, decisions made, personnel involved

Phase 6: 72-Hour Detailed Notification
Article 23(4) requires a detailed incident notification within 72 hours. This report must provide a more comprehensive assessment than the early warning, including severity, impact, and indicators of compromise.
DEADLINE: Submit detailed notification within 72 hours of time organization became aware of the incident. This deadline is independent of investigation completion.
Required Information (Detailed Notification)
The 72-hour notification must include:
 •	Incident update: Reference to early warning notification; updated status
 •	Initial assessment: Severity and impact evaluation per Article 23(5) criteria
 •	Type and cause: Incident classification and preliminary root cause (if determined)
 •	Indicators of compromise: IP addresses, domains, file hashes, malware signatures, attack vectors
 •	Cross-border impact: Whether incident affects other member states
 •	Response actions: Containment and mitigation measures implemented
Severity Assessment (Article 23(5))
Assess incident severity considering:
 •	Number of users affected: Scale of service disruption
 •	Duration of incident: How long services were disrupted
 •	Geographical spread: Single location vs. multiple regions/countries
 •	Extent of disruption: Complete outage vs. degraded performance
 •	Economic impact: Financial losses to entity and affected parties
 •	Reputational damage: Impact on public trust and business relationships
Submission Procedure
Complete within 72-hour window:
 1.	Compile investigation findings: Gather all available information (acknowledge if incomplete)
 2.	Complete detailed notification form: Use CSIRT template with all required fields
 3.	Obtain internal approvals: CISO and legal counsel review
 4.	Submit via designated channel: CSIRT portal or specified method
 5.	Retain confirmation: Document submission and receipt
 6.	Plan for final report: Identify information gaps to address in one-month report

Phase 7: Recovery & Final Reporting
Recovery focuses on restoring normal operations, implementing remediation measures, and preparing the final incident report required within one month of initial notification.
Recovery Objectives
 •	Service restoration: Return affected services to normal operational status
 •	System remediation: Remove malware, patch vulnerabilities, rebuild compromised systems
 •	Security hardening: Implement additional controls to prevent recurrence
 •	Validation: Verify that threat is eliminated and systems are secure
Recovery Procedure
Execute recovery in a controlled, validated manner:
 1.	Develop recovery plan: Document restoration sequence, dependencies, validation steps
 2.	Remediate vulnerabilities: Patch systems, update configurations, harden security controls
 3.	Restore from clean backups: Use verified clean backups or rebuild systems from trusted sources
 4.	Test systems thoroughly: Validate functionality and security before production deployment
 5.	Implement enhanced monitoring: Add detection rules specific to incident indicators
 6.	Restore service gradually: Phased restoration with continuous monitoring
 7.	Validate complete recovery: Confirm normal operations and absence of residual compromise
Final Report (One Month)
Submit final incident report to CSIRT within one month. Content requirements:
 •	Comprehensive incident description: Complete timeline, root cause analysis, attack methodology
 •	Final impact assessment: Definitive service disruption, data exposure, financial impact
 •	Response effectiveness: Evaluation of containment and recovery measures
 •	Remediation actions: Security improvements implemented
 •	Lessons learned: Process improvements, control enhancements, training needs
Post-Incident Review
Conduct internal review within two weeks of incident closure:
 •	Incident response effectiveness: Did procedures work as intended? Were timelines met?
 •	Detection capability gaps: How was incident discovered? Could it have been detected earlier?
 •	Technical control deficiencies: Which security controls failed or were bypassed?
 •	Process improvements: Update playbooks, documentation, training materials
 •	Management reporting: Brief board and executives on incident and improvements

Roles & Responsibilities
Clear role definition is essential for effective incident response. Organizations should document responsibilities and ensure 24/7 availability of key personnel.
Role	Responsibilities	Decision Authority	
Incident Commander
(CISO or designee)	Overall incident coordination; classification decisions; regulatory notification approval; executive communication	Containment strategy; notification decisions; communication authority; escalation to management	
Technical Lead
(IT/Security Manager)	Technical response coordination; investigation leadership; evidence collection; system remediation	Technical containment actions; forensic procedures; recovery sequencing	
Legal Counsel	Regulatory compliance guidance; notification review; external communication approval; law enforcement liaison	Regulatory obligations; external communications; legal disclosures	
Communications Lead	Internal communications; customer notification; media relations; public statements	External messaging; public statements	
Business Representative	Business impact assessment; service prioritization; customer liaison; operational decisions	Service restoration priorities; business continuity activation	
Documentation Lead	Incident timeline maintenance; action tracking; notification preparation; evidence cataloging	Documentation accuracy and completeness	
Organizations without full-time security leadership often engage virtual CISO services to fill the Incident Commander role during major incidents. This provides experienced leadership for classification, notification decisions, and coordination.

Tools & Templates
The following tools and templates support efficient incident response and regulatory notification. Organizations should customize these resources to their specific environment and test them during exercises.
Required Documentation
 •	Incident Response Plan: Overall framework and procedures (this playbook)
 •	Contact Lists: Incident response team, management, CSIRT, vendors, law enforcement
 •	Notification Templates: Pre-formatted templates for 24h and 72h notifications
 •	Classification Matrix: Quick reference guide for severity determination
 •	Evidence Collection Procedures: Step-by-step forensic evidence handling
 •	Communication Templates: Internal announcements, customer notifications, media statements
Essential Tools
 •	Incident Tracking System: Centralized platform for documenting incidents, actions, evidence
 •	Secure Communication Channel: Encrypted platform for incident team coordination
 •	Forensic Tools: Disk imaging, memory capture, log analysis, malware analysis
 •	Threat Intelligence: IOC databases, threat actor profiles, vulnerability information
 •	Evidence Storage: Secure, tamper-evident storage for forensic evidence
Readiness Requirements
Maintain incident response readiness through:
 •	Annual plan review: Update procedures, contacts, and tools
 •	Quarterly exercises: Tabletop exercises testing notification procedures
 •	Team training: Role-specific training for incident response team members
 •	Tool validation: Test forensic tools, notification portals, communication channels
 •	Contact verification: Confirm accuracy of all contact lists and escalation procedures

Document Control & Maintenance
Document Information
Document Title:	NIS2 Incident Response Playbook	
Version:	1.0	
Effective Date:	[To be determined by implementing organization]	
Review Frequency:	Annually or following major incidents	
Document Owner:	Chief Information Security Officer	
Approval Authority:	Management Body	
Revision History
Version	Date	Author	Changes	
1.0	Dec 2025	Paolo Carner, BARE Consulting	Initial release	
Organizations should customize this playbook to their specific environment, update contact information, and validate procedures through regular testing. Incident response effectiveness depends on preparation, practice, and continuous improvement.