Incident Response Plan and Security Addendum (NIS2-Ready)

INCIDENT RESPONSE PLAN AND SECURITY ADDENDUM (NIS2-READY)

Organization Name: [________________________________]
Document Reference: [____]-IRP-NIS2-[____]
Effective Date: [__/__/____]
Last Revised: [__/__/____]
Document Owner: [________________________________] (Chief Information Security Officer)
Approved By: [________________________________] (Management Body / Board of Directors)
Classification: Confidential

TABLE OF CONTENTS

1. Purpose, Scope, and Objectives
2. NIS2 Directive Overview and Applicability
3. Governance Structure and Roles
4. Incident Classification Framework
5. Detection, Monitoring, and Initial Reporting
6. Incident Response Workflow
7. NIS2 Regulatory Notification Requirements
8. GDPR Breach Notification Coordination
9. Stakeholder Communications
10. Evidence Preservation and Forensics
11. Third-Party and Supply Chain Coordination
12. Business Continuity and Recovery
13. Post-Incident Review and Lessons Learned
14. Cybersecurity Risk-Management Measures (Article 21)
15. Security Controls Baseline
16. Training and Exercises
17. Policy Governance and Review
18. Appendix A: Incident Severity Matrix
19. Appendix B: NIS2 Notification Checklist and Timeline
20. Appendix C: Communication Templates
21. Appendix D: Vendor Security Addendum Clauses
22. Appendix E: Post-Incident Review Template
23. Sources and References

1. PURPOSE, SCOPE, AND OBJECTIVES

1.1 Purpose

This Incident Response Plan and Security Addendum ("Plan") defines the procedures for detecting, responding to, reporting, and recovering from cybersecurity incidents affecting [________________________________] ("Organization"). The Plan is designed to ensure compliance with the EU NIS2 Directive (Directive (EU) 2022/2555) and corresponding national implementing laws, as well as the General Data Protection Regulation (GDPR) where personal data is involved.

1.2 Scope

This Plan applies to:

☐ All network and information systems operated by or on behalf of the Organization within the European Economic Area (EEA)
☐ All employees, contractors, and third parties with access to the Organization's network and information systems
☐ All services provided by the Organization that fall within the scope of the NIS2 Directive
☐ Supply chain and third-party service providers whose systems or services could affect the Organization's security

1.3 Objectives

☐ Minimize the impact of cybersecurity incidents on the Organization's operations and stakeholders
☐ Comply with NIS2 notification timelines (24-hour early warning, 72-hour notification, 1-month final report)
☐ Coordinate with GDPR breach notification where personal data is involved
☐ Preserve evidence for forensic analysis, law enforcement, and regulatory proceedings
☐ Continuously improve security posture through post-incident analysis

2. NIS2 DIRECTIVE OVERVIEW AND APPLICABILITY

2.1 NIS2 Directive Background

The NIS2 Directive (Directive (EU) 2022/2555) entered into force on January 16, 2023 and required EU Member States to transpose it into national law by October 17, 2024. NIS2 significantly expands the scope of the original NIS Directive, covering more sectors and imposing stricter requirements for cybersecurity risk management and incident reporting.

2.2 Covered Entities

NIS2 applies to essential entities and important entities across the following sectors:

Essential Entities (Annex I):
☐ Energy (electricity, oil, gas, hydrogen, district heating)
☐ Transport (air, rail, water, road)
☐ Banking and financial market infrastructure
☐ Health (hospitals, laboratories, medical devices, pharmaceuticals)
☐ Drinking water and waste water
☐ Digital infrastructure (IXPs, DNS, TLD registries, cloud, data centers, CDNs, trust services, public communications networks)
☐ ICT service management (B2B -- managed service providers, managed security service providers)
☐ Public administration (central government)
☐ Space

Important Entities (Annex II):
☐ Postal and courier services
☐ Waste management
☐ Chemicals
☐ Food production, processing, and distribution
☐ Manufacturing (medical devices, computers, electronics, machinery, motor vehicles)
☐ Digital providers (online marketplaces, search engines, social networking)
☐ Research

2.3 Size Thresholds

Generally applies to medium and large enterprises (50+ employees or EUR 10M+ annual turnover/balance sheet). Some entities are covered regardless of size (e.g., trust service providers, TLD registries, DNS service providers, sole providers of essential services in a Member State).

2.4 Organization Applicability

3. GOVERNANCE STRUCTURE AND ROLES

3.1 Management Body Accountability (Article 20)

Under NIS2 Article 20, management bodies of essential and important entities must:

☐ Approve cybersecurity risk-management measures adopted pursuant to Article 21
☐ Oversee the implementation of those measures
☐ Be liable for infringements
☐ Follow cybersecurity training
☐ Offer similar training to employees on a regular basis

3.2 Incident Response Team (IRT)

3.3 Escalation Contacts

4. INCIDENT CLASSIFICATION FRAMEWORK

4.1 Severity Levels

4.2 NIS2 "Significant Incident" Definition (Article 23(3))

An incident is considered significant if:

☐ It has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned
☐ It has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

5. DETECTION, MONITORING, AND INITIAL REPORTING

5.1 Detection Sources

☐ Security Information and Event Management (SIEM): [________________________________]
☐ Intrusion Detection/Prevention Systems (IDS/IPS): [________________________________]
☐ Endpoint Detection and Response (EDR): [________________________________]
☐ Network traffic analysis / anomaly detection
☐ Vulnerability scanning results
☐ Employee reports (via SOC hotline: [________________________________])
☐ Third-party notifications (vendors, CERTs, law enforcement)
☐ Threat intelligence feeds

5.2 Initial Assessment Procedure

Upon detection of a suspected incident:

☐ Step 1: SOC analyst validates the alert and conducts initial triage within [____] minutes
☐ Step 2: Document event in Incident Ticketing System: [________________________________]
☐ Step 3: Record timestamps (UTC), indicators of compromise (IOCs), affected systems, initial scope assessment
☐ Step 4: Classify severity per Section 4.1
☐ Step 5: Escalate to IRT if Medium or above; escalate to CISO and Legal if High or Critical
☐ Step 6: For significant incidents, initiate NIS2 24-hour early warning clock (see Section 7)

6. INCIDENT RESPONSE WORKFLOW

Phase 1: Identification

☐ Validate that an incident has occurred (not a false positive)
☐ Determine scope: affected systems, data, users, services
☐ Identify type: ransomware, data exfiltration, DDoS, insider threat, supply chain compromise, etc.
☐ Assign incident commander (IR Lead or CISO for Critical)

Phase 2: Containment

Short-Term Containment (immediate):
☐ Isolate affected systems from the network
☐ Block malicious IP addresses, domains, and accounts
☐ Disable compromised credentials
☐ Preserve system state for forensics before remediation

Long-Term Containment:
☐ Implement temporary fixes to allow continued operations
☐ Apply emergency patches if applicable
☐ Enhance monitoring on affected and adjacent systems
☐ Establish clean staging environment for recovery

Phase 3: Eradication

☐ Remove all malicious artifacts (malware, backdoors, unauthorized accounts)
☐ Patch exploited vulnerabilities
☐ Harden configurations
☐ Verify removal through scanning and monitoring
☐ Update IOCs in security tools

Phase 4: Recovery

☐ Restore systems from verified clean backups
☐ Validate system integrity before reconnection
☐ Implement enhanced monitoring for recurrence
☐ Gradually restore services with validation at each stage
☐ Confirm with business owners that services are operational

Phase 5: Post-Incident Review

☐ Conduct root cause analysis within [____] business days of incident closure
☐ Document lessons learned
☐ Update security controls, policies, and procedures
☐ Prepare NIS2 final report (see Section 7.3)
☐ Brief management body and Board as appropriate

7. NIS2 REGULATORY NOTIFICATION REQUIREMENTS

7.1 Three-Stage Reporting Timeline (Article 23)

NIS2 Article 23 establishes a mandatory three-stage incident reporting timeline for significant incidents:

Stage 1: Early Warning -- Within 24 Hours

Deadline: Within 24 hours of becoming aware of a significant incident.

Content:
☐ Indication that a significant incident has occurred
☐ Whether the incident is suspected to be caused by unlawful or malicious acts
☐ Whether the incident could have cross-border impact

Submitted to: Competent authority and/or CSIRT designated for the Organization's sector and Member State.

Form/Method: [________________________________]

Stage 2: Incident Notification -- Within 72 Hours

Deadline: Within 72 hours of becoming aware of the significant incident.

Content:
☐ Update of the information from the early warning
☐ Initial assessment of the incident, including:

• Severity and impact
• Indicators of compromise (where available)
• Mitigation measures applied and ongoing
  ☐ Where applicable, cross-border impact information

Stage 3: Final Report -- Within 1 Month

Deadline: Within one month after submission of the incident notification (or upon request by the competent authority/CSIRT).

Content:
☐ Detailed description of the incident, including severity and impact
☐ Type of threat or root cause likely leading to the incident
☐ Applied and ongoing mitigation measures
☐ Cross-border impact (where applicable)

If the incident is ongoing at the 1-month mark, a progress report must be submitted, with the final report due within one month of the Organization's handling of the incident.

7.2 Additional Reporting Obligations

☐ Cross-border coordination: If the incident has cross-border implications, the competent authority must inform relevant authorities in other Member States and ENISA
☐ Recipient notification: Where appropriate, affected recipients of services must be notified of the incident and any measures they can take (Article 23(1))
☐ National implementing law: Check each applicable Member State's transposition for any accelerated timelines or sector-specific additions: [________________________________]

7.3 Notification Log

8. GDPR BREACH NOTIFICATION COORDINATION

Where a cybersecurity incident also involves a personal data breach under the GDPR:

8.1 Supervisory Authority Notification (Article 33)

☐ Notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach (unless unlikely to result in risk to individuals)
☐ If notification cannot be made within 72 hours, provide reasons for delay
☐ Content: nature of breach, categories/numbers of data subjects and records, contact details of DPO, likely consequences, measures taken

8.2 Data Subject Notification (Article 34)

☐ If the breach is likely to result in a high risk to the rights and freedoms of individuals, notify affected data subjects without undue delay
☐ Content: nature of breach, DPO contact, likely consequences, measures taken
☐ Exceptions: encryption, subsequent measures eliminating high risk, or disproportionate effort (with public communication alternative)

8.3 Coordination Between NIS2 and GDPR

☐ The NIS2 and GDPR reporting timelines are independent -- both must be satisfied
☐ The 72-hour GDPR clock starts upon "awareness" of the breach, which may differ from the NIS2 incident awareness trigger
☐ The DPO and Legal/Compliance Lead must coordinate to ensure both streams are managed concurrently
☐ A single incident may require notifications to multiple supervisory authorities (NIS2 competent authority, GDPR supervisory authority, and potentially data subjects)

9. STAKEHOLDER COMMUNICATIONS

9.1 Internal Communications

☐ Notify executive leadership and management body immediately for High/Critical incidents
☐ Brief affected business units on impact and expected recovery timeline
☐ HR notification if employee data is affected
☐ Legal/compliance briefing for regulatory and litigation considerations

9.2 External Communications

☐ Affected customers, partners, and vendors as required by contract or law
☐ Coordinate messaging with GDPR data subject notifications
☐ Media handling per pre-approved templates (Appendix C)
☐ Regulatory authority notifications (NIS2, GDPR, sector-specific)
☐ Law enforcement where criminal activity is suspected

9.3 Communication Approval

All external communications regarding incidents must be approved by:
☐ CISO
☐ Legal/Compliance Lead
☐ Communications Lead
☐ Executive Sponsor (for Critical incidents)

10. EVIDENCE PRESERVATION AND FORENSICS

☐ Preserve all logs, system images, network captures, and relevant data in tamper-evident storage
☐ Document chain of custody for all forensic evidence
☐ Use forensically sound tools and methods for data collection
☐ Maintain forensic notes with timestamps, actions taken, and personnel involved
☐ Engage third-party forensic experts when specialized analysis is required: [________________________________]
☐ Coordinate with legal counsel to establish and maintain attorney-client privilege over investigation materials where appropriate
☐ Ensure evidence preservation does not conflict with data minimization/deletion obligations under GDPR

11. THIRD-PARTY AND SUPPLY CHAIN COORDINATION

11.1 Vendor Notification Requirements

☐ Maintain up-to-date contact list for critical suppliers and service providers
☐ Contractually require vendors to notify the Organization of incidents impacting shared services within [____] hours (recommend: 24 hours maximum)
☐ Include right-to-audit and cooperation clauses (see Appendix D)
☐ Assess supply chain incident impact on the Organization's NIS2 compliance

11.2 Supply Chain Security (Article 21(2)(d))

NIS2 Article 21(2)(d) specifically requires entities to address supply chain security, including:

☐ Security-related aspects concerning relationships between the entity and its direct suppliers or service providers
☐ Assessment of overall quality, resilience, and cybersecurity practices of suppliers
☐ Vulnerabilities specific to each direct supplier and service provider
☐ Results of coordinated security risk assessments of critical supply chains

12. BUSINESS CONTINUITY AND RECOVERY

☐ Activate Business Continuity Plan (BCP) for incidents affecting critical services
☐ Invoke Disaster Recovery Plan (DRP) if infrastructure is compromised
☐ Establish Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for critical systems
☐ Prioritize recovery of services within NIS2 scope
☐ Document recovery actions and timeline

13. POST-INCIDENT REVIEW AND LESSONS LEARNED

☐ Conduct post-incident review within [____] business days of incident closure
☐ Include all IRT members and relevant stakeholders
☐ Document in Post-Incident Review Template (Appendix E)
☐ Identify root cause, contributing factors, and control gaps
☐ Develop remediation action plan with owners and deadlines
☐ Update incident response plan, security controls, and training based on findings
☐ Report lessons learned to management body
☐ Feed findings into the NIS2 final report

14. CYBERSECURITY RISK-MANAGEMENT MEASURES (ARTICLE 21)

NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organizational measures to manage cybersecurity risks, based on an all-hazards approach. The following measures must be addressed:

☐ (a) Policies on risk analysis and information system security
☐ (b) Incident handling (this Plan)
☐ (c) Business continuity and crisis management, including backup management and disaster recovery
☐ (d) Supply chain security (Section 11)
☐ (e) Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure
☐ (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
☐ (g) Basic cyber hygiene practices and cybersecurity training
☐ (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption
☐ (i) Human resources security, access control policies, and asset management
☐ (j) Use of multi-factor authentication or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems

15. SECURITY CONTROLS BASELINE

15.1 Technical Controls

15.2 Organizational Controls

☐ Information security management system (ISMS) -- ☐ ISO 27001 certified ☐ Aligned but not certified
☐ Written security policies reviewed annually
☐ Security awareness training for all personnel
☐ Vendor/supplier security assessment program
☐ Change management procedures
☐ Physical security controls
☐ HR security (background checks, access revocation upon departure)

16. TRAINING AND EXERCISES

16.1 Training Requirements

☐ Management body: cybersecurity training at least annually (NIS2 Article 20(2))
☐ All employees: security awareness training at least annually
☐ IRT members: incident response technical training at least annually
☐ Specialized training for SOC analysts, forensic investigators
☐ Training records maintained for at least three (3) years

16.2 Exercises

17. POLICY GOVERNANCE AND REVIEW

• Document Owner: Chief Information Security Officer
• Review Frequency: Semi-annually, and after every significant incident
• Approval Authority: Management body / Board of Directors
• Next Scheduled Review: [__/__/____]
• Version History:

APPENDIX A: INCIDENT SEVERITY MATRIX

APPENDIX B: NIS2 NOTIFICATION CHECKLIST AND TIMELINE

Early Warning (24 Hours)

☐ Incident identified as significant
☐ Clock started: [__/__/____ __:__ UTC]
☐ Early warning prepared with:

• ☐ Confirmation of significant incident
• ☐ Suspected unlawful/malicious act assessment
• ☐ Cross-border impact assessment
  ☐ Submitted to competent authority/CSIRT: [__/__/____ __:__ UTC]
  ☐ Reference number received: [________]

Incident Notification (72 Hours)

☐ Deadline: [__/__/____ __:__ UTC]
☐ Notification includes:

• ☐ Updated information from early warning
• ☐ Initial assessment of severity and impact
• ☐ Indicators of compromise
• ☐ Mitigation measures applied
• ☐ Cross-border impact details
  ☐ Submitted: [__/__/____ __:__ UTC]

Final Report (1 Month)

☐ Deadline: [__/__/____]
☐ Report includes:

• ☐ Detailed incident description
• ☐ Type of threat / root cause
• ☐ Applied and ongoing mitigation measures
• ☐ Cross-border impact
  ☐ Submitted: [__/__/____]

APPENDIX C: COMMUNICATION TEMPLATES

C.1 Internal Notification Template

Subject: [SEVERITY LEVEL] Cybersecurity Incident -- [Brief Description]

Date/Time: [__/__/____ __:__ UTC]
Incident ID: [________]
Severity: ☐ Low ☐ Medium ☐ High ☐ Critical
Summary: [________________________________]
Impact: [________________________________]
Actions Taken: [________________________________]
Next Steps: [________________________________]
Contact: [________________________________]

C.2 Customer/Partner Notification Template

[Customize per legal and regulatory requirements]

Dear [Customer/Partner],

We are writing to inform you of a cybersecurity incident that may affect [services/data]. [Description of incident, impact, and measures taken.] We recommend [any actions the recipient should take]. For questions, contact [________________________________].

C.3 Media Holding Statement

[Organization] is aware of a cybersecurity incident affecting [brief description]. We are actively investigating with the support of [internal/external experts]. We have notified the relevant authorities and are taking all appropriate measures to contain the incident and protect our stakeholders.

APPENDIX D: VENDOR SECURITY ADDENDUM CLAUSES

The following clauses should be incorporated into contracts with third-party vendors and service providers:

☐ Incident notification: Vendor must notify the Organization of any security incident affecting shared services or data within [____] hours of discovery
☐ Cooperation: Vendor must cooperate with the Organization's incident response efforts, including providing logs, access, and technical assistance
☐ Audit rights: Organization reserves the right to audit vendor security controls annually and upon any incident
☐ Compliance: Vendor must maintain cybersecurity measures consistent with NIS2 Article 21 requirements
☐ Subprocessor notification: Vendor must notify the Organization before engaging subprocessors and ensure equivalent security obligations
☐ Remediation: Vendor must implement remediation measures identified through audits or incident reviews within agreed timelines
☐ Termination: Organization may terminate for material breach of security obligations

APPENDIX E: POST-INCIDENT REVIEW TEMPLATE

SOURCES AND REFERENCES

• NIS2 Directive (Directive (EU) 2022/2555) -- https://eur-lex.europa.eu/eli/dir/2022/2555
• NIS2 Article 21 (Cybersecurity Risk-Management Measures) -- https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
• NIS2 Article 23 (Reporting Obligations) -- https://www.nis-2-directive.com/NIS_2_Directive_Article_23.html
• GDPR Articles 33-34 (Breach Notification) -- https://gdpr-info.eu/art-33-gdpr/
• ENISA NIS2 Implementation Guidance -- https://www.enisa.europa.eu/
• NIS2 Directive Transposition Tracker -- https://ecs-org.eu/activities/nis2-directive-transposition-tracker/
• ISO/IEC 27001:2022 -- https://www.iso.org/standard/27001
• ISO/IEC 27035 (Incident Management)
• NIST Cybersecurity Framework 2.0 -- https://www.nist.gov/cyberframework
• NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide)

PENALTIES AND ENFORCEMENT

Essential Entities

• Administrative fines up to EUR 10,000,000 or 2% of total worldwide annual turnover (whichever is higher)
• Management body members may be held personally liable and subject to temporary suspension

Important Entities

• Administrative fines up to EUR 7,000,000 or 1.4% of total worldwide annual turnover (whichever is higher)

GDPR (if personal data involved)

• Additional fines up to EUR 20,000,000 or 4% of total worldwide annual turnover under GDPR Article 83

This document is a template provided for informational purposes only and does not constitute legal advice. It must be reviewed and customized by qualified legal counsel in each applicable EU Member State before implementation. National transposition laws may impose additional or different requirements.