How to Build an Incident Response Plan: 6-Phase Framework

An incident response (IR) plan is a documented set of procedures that defines how your organization detects, contains, eradicates, and recovers from cybersecurity incidents. Based on the NIST SP 800-61 framework, an effective IR plan reduces breach costs by an average of USD 473,706 according to IBM's 2024 Cost of a Data Breach Report. With NIS2 now requiring essential and important entities to report significant incidents within 24 hours, having a structured, rehearsed IR plan is no longer optional for European organizations. This guide walks you through the six phases of incident response, the roles required, communication protocols, and how to integrate NIS2 reporting timelines into your plan.

Why Every Organization Needs an Incident Response Plan

Cybersecurity incidents are inevitable. The question is not whether your organization will face a breach, but when and how effectively you will respond. According to the Verizon 2024 Data Breach Investigations Report, 68% of breaches involved a human element, and ransomware was present in 24% of all incidents. Organizations without a formal IR plan take an average of 292 days to identify and contain a breach, compared to 217 days for those with a plan and a dedicated IR team (IBM, 2024).

Beyond operational efficiency, regulatory requirements make IR planning mandatory. The NIS2 Directive (Article 23), GDPR (Article 33), DORA (for financial entities), and PCI DSS all require documented incident response procedures and specific notification timelines. Failure to comply can result in significant penalties, up to EUR 10 million or 2% of global turnover under NIS2.

The 6-Phase Incident Response Framework

The NIST Special Publication 800-61 (Computer Security Incident Handling Guide) defines the industry-standard framework for incident response. While some models use four or five phases, the six-phase model provides the most actionable structure for building and maintaining an IR plan.

Phase 1: Preparation

Preparation is the foundation of effective incident response. This phase happens before any incident occurs and determines how well you can execute the remaining phases.

Key preparation activities include:

• Establish the IR team: Define roles, responsibilities, and escalation paths. At minimum, your team needs an Incident Commander, Technical Lead, Communications Lead, and Legal/Compliance liaison.
• Document procedures: Create detailed playbooks for common incident types: ransomware, data exfiltration, business email compromise, DDoS, insider threats, and supply chain compromise.
• Deploy detection tools: Ensure SIEM, EDR/XDR, and network monitoring tools are properly configured and generating actionable alerts. A SOCaaS provider can deliver these capabilities.
• Establish communication channels: Define out-of-band communication methods (phone trees, encrypted messaging) in case primary systems are compromised.
• Maintain contact lists: Keep updated lists of internal stakeholders, external counsel, cyber insurance carriers, forensic providers, law enforcement contacts, and regulatory notification contacts.
• Conduct training: Ensure all IR team members understand their roles and can execute procedures under pressure.

Phase 2: Identification

Identification is the process of detecting that a security incident has occurred, determining its scope, and classifying its severity. This phase is critical because it sets the tone for the entire response. Mandiant's M-Trends 2024 report found that the median time to identify a breach (dwell time) was 10 days globally, but organizations with 24/7 SOC monitoring reduced this to 6 days. Learn more about reducing dwell time.

Key identification activities:

• Alert triage: Evaluate incoming alerts from SIEM, EDR, IDS/IPS, and user reports to determine if they represent genuine incidents.
• Severity classification: Assign a severity level (Critical, High, Medium, Low) based on the potential business impact, data sensitivity, and systems affected.
• Scope assessment: Determine what systems, data, and users are affected. Identify initial indicators of compromise (IoCs).
• Document everything: Begin a formal incident log. Record timestamps, actions taken, evidence collected, and decisions made. This documentation is essential for regulatory reporting and post-incident analysis.

Phase 3: Containment

Containment prevents the incident from spreading further while preserving evidence for investigation. There are two sub-phases: short-term containment (immediate actions to stop the bleeding) and long-term containment (sustainable measures while you prepare for eradication).

Short-term containment examples:

• Isolate affected endpoints from the network (do not power them off, as this destroys volatile memory evidence).
• Block malicious IP addresses and domains at the firewall and DNS level.
• Disable compromised user accounts.
• Redirect traffic from compromised servers to clean systems.

Long-term containment examples:

• Apply emergency patches to exploited vulnerabilities.
• Implement additional network segmentation.
• Deploy enhanced monitoring on potentially affected systems.
• Set up clean systems in parallel for critical business functions.

The Ponemon Institute found that organizations that contained a breach within 30 days saved an average of USD 1.12 million compared to those that took longer. Speed matters, and automated containment through SOAR playbooks can reduce containment time from hours to minutes.

Phase 4: Eradication

Eradication removes the root cause of the incident from the environment. This is not simply deleting malware; it requires understanding how the attacker gained access and ensuring all persistence mechanisms are removed.

Key eradication activities:

• Root cause analysis: Determine the initial attack vector (phishing email, exploited vulnerability, compromised credentials, supply chain).
• Remove all attacker artifacts: Eliminate malware, backdoors, modified configurations, unauthorized accounts, and persistence mechanisms (scheduled tasks, registry modifications, cron jobs).
• Patch vulnerabilities: Close the entry point that enabled the attack.
• Reset credentials: Force password resets for all affected accounts. Consider resetting service account credentials and rotating certificates if lateral movement occurred.
• Verify eradication: Conduct thorough scans and monitoring to confirm no attacker presence remains.

Phase 5: Recovery

Recovery restores affected systems and services to normal operations. This phase must be conducted carefully to avoid reintroducing the threat or triggering additional issues.

Key recovery activities:

• Restore from clean backups: Verify backup integrity before restoring. Ensure backups pre-date the initial compromise.
• Rebuild compromised systems: For severely compromised systems, rebuild from known-good images rather than attempting to clean them.
• Implement enhanced monitoring: Increase monitoring sensitivity for recovered systems for at least 30-60 days post-recovery to detect any resurgence.
• Gradual service restoration: Bring systems back online in stages, validating each before proceeding to the next.
• Confirm business operations: Verify that all business functions are operating correctly and that data integrity has been maintained.

Phase 6: Lessons Learned

The lessons learned phase is the most frequently skipped but arguably the most valuable. According to the SANS Institute, only 42% of organizations conduct formal post-incident reviews, despite evidence that organizations that do experience 29% fewer repeat incidents.

Key activities:

• Post-incident review meeting: Conduct within 1-2 weeks of incident closure. Include all IR team members and relevant stakeholders.
• Document findings: What happened, when, how it was detected, what worked well, what failed, and what needs improvement.
• Update the IR plan: Revise procedures, playbooks, and contact lists based on lessons learned.
• Improve defenses: Implement technical controls to prevent recurrence. Update detection rules to catch similar attacks faster.
• Share intelligence: If appropriate, share IoCs and TTPs with sector-specific ISACs (Information Sharing and Analysis Centers) and trusted peers.

IR Team Roles and Responsibilities

Role	Responsibilities	Typical Background
Incident Commander	Overall coordination, decision authority, stakeholder communication	CISO, Security Director, or senior security manager
Technical Lead	Technical investigation, forensics coordination, containment decisions	Senior SOC analyst, security engineer, or forensics specialist
Communications Lead	Internal communications, media relations, customer notifications	PR/Communications director or designated spokesperson
Legal/Compliance Liaison	Regulatory notifications, legal privilege, contract review, law enforcement coordination	General counsel, privacy officer, or external legal firm
IT Operations Lead	System restoration, backup management, infrastructure changes	IT director or senior systems administrator
Business Liaison	Business impact assessment, business continuity decisions	Business unit leaders or COO

NIS2 Incident Reporting Timeline

The NIS2 Directive imposes strict incident reporting requirements on essential and important entities. Your IR plan must integrate these timelines explicitly:

Timeline	Requirement	Content
24 hours	Early warning	Initial notification to CSIRT/competent authority. Must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it could have cross-border impact.
72 hours	Incident notification	Update the early warning with an initial assessment of severity and impact, including IoCs where applicable.
1 month	Final report	Detailed description of the incident including root cause, mitigation measures applied, and cross-border impact if any.

GDPR Article 33 separately requires notification to the supervisory authority within 72 hours for personal data breaches. Your IR plan should include parallel notification workflows for both NIS2 and GDPR when personal data is involved.

The Critical Role of Tabletop Exercises

An IR plan that has never been tested is a plan that will fail when needed. Tabletop exercises are structured, scenario-based discussions where the IR team walks through a simulated incident to test procedures, identify gaps, and improve coordination.

Best practices for tabletop exercises:

• Frequency: Conduct at least two exercises per year, with different scenarios each time.
• Scenarios: Include ransomware, data exfiltration, business email compromise, insider threat, and supply chain attack scenarios.
• Participants: Include executives, legal, communications, IT, and business unit leaders, not just the security team.
• Inject timeline pressure: Simulate NIS2's 24-hour reporting deadline to test whether your team can gather sufficient information in time.
• Document outcomes: Record gaps identified and create action items with owners and deadlines.

The Ponemon Institute reports that organizations conducting regular tabletop exercises reduce breach costs by an average of USD 232,008 and identify breaches 26 days faster.

Building Your IR Plan: Template Structure

A complete IR plan document should include these sections:

1. Purpose and scope: What the plan covers, which systems and entities are included.
2. Roles and responsibilities: IR team roster with contact information and alternates.
3. Incident classification: Severity levels (Critical/High/Medium/Low) with clear criteria for each.
4. Notification procedures: Internal escalation paths and external notification timelines (NIS2, GDPR, sector-specific).
5. Response procedures by incident type: Specific playbooks for ransomware, data breach, BEC, DDoS, insider threat.
6. Communication templates: Pre-drafted templates for internal communications, regulatory notifications, customer notifications, and media statements.
7. Evidence handling: Chain of custody procedures, forensic image collection, log preservation requirements.
8. Recovery procedures: Backup verification, system rebuild standards, service restoration checklist.
9. Post-incident review process: Timeline, participants, reporting template.
10. Plan maintenance: Review schedule, update triggers, version control.

Orizon's Oversight service includes incident response support as part of its managed security operations, helping organizations detect incidents faster, contain them effectively, and meet NIS2 reporting obligations. For organizations subject to NIS2, our service integrates NIS2 compliance support directly into the incident handling workflow.