An incident response (IR) plan is a structured approach for handling security breaches and cyberattacks. A well-prepared IR plan reduces damage, recovery time, and costs. In April 2025, NIST released SP 800-61 Revision 3, the first update to its incident response guidance since 2012, aligning IR recommendations with the CSF 2.0 framework and its six functions: Govern, Identify, Protect, Detect, Respond, and Recover.
This guide covers how to build, test, and maintain an IR plan that meets both operational needs and evolving regulatory requirements including SEC disclosure rules and the upcoming CIRCIA reporting mandates. While we present the traditional six-phase IR model that most organizations use operationally, we incorporate r3’s emphasis on governance, shared responsibility, and alignment with the broader CSF 2.0 framework.
IR Plan Foundations
Before defining phases, establish the organizational context.
Governance and Authority
NIST SP 800-61r3 emphasizes that IR is not solely the security team’s responsibility. The IR plan should define an executive sponsor (a C-level officer such as CISO, CTO, or CRO) with authority to make containment decisions including system shutdowns. Define IR team composition to include security analysts, IT operations, legal counsel, PR/communications, HR, and business unit leaders. Establish a decision authority matrix specifying who can authorize system isolation, external communication, law enforcement engagement, and ransom payment decisions. Document the shared responsibility model, clearly delineating what’s handled in-house versus outsourced to MDR providers, IR retainers, or forensics firms.
Communication Plan
Establish out-of-band communication channels that remain operational if primary systems are compromised.
Set up a dedicated Signal/Teams group not dependent on corporate email. Create physical contact cards with IR team members’ personal phone numbers. Prepare pre-drafted notification templates for customers, regulators, employees, and media. Document legal hold procedures for preserving evidence and communications. Designate a spokesperson and establish media response protocols.
Six Phases of Incident Response
1. Preparation
Preparation determines whether your organization can respond effectively when an incident occurs. This phase is continuous, not a one-time activity.
For team readiness, define roles with primary and backup assignments for each function. Ensure IR team members have appropriate access to security tools, network diagrams, and asset inventories. Maintain current contact lists including external parties (legal, forensics, law enforcement, cyber insurance carrier). Conduct quarterly tabletop exercises simulating realistic scenarios (ransomware, data exfiltration, insider threat, supply chain compromise).
For technical preparation, deploy and configure monitoring tools: SIEM, EDR/XDR, NDR, and cloud audit logging. Create runbooks for common incident types including ransomware, BEC, credential compromise, DDoS, data breach, and insider threat. Maintain a forensic toolkit with disk imaging tools, memory capture utilities, and network capture capabilities. Ensure offline access to critical documentation (network diagrams, asset inventories, runbooks) in case primary systems are unavailable. Pre-configure containment actions: network isolation scripts, account disabling procedures, and firewall block rules.
For AI-assisted preparation in 2025-2026, IBM ATOM and similar AI-driven tools can automate initial triage, claiming 70%+ reduction in false positives. AI investigation assistants (Charlotte AI, Purple AI, Copilot for Security) accelerate analyst investigation through natural language querying. Evaluate AI tools for automated evidence collection and timeline reconstruction. Establish policies for AI-assisted vs. human-verified containment decisions.
2. Identification
Detect and determine whether an event is a security incident. The goal is to move from alert to confirmed incident as quickly as possible.
Detection sources include SIEM correlation rules and anomaly detection, EDR/XDR behavioral alerts, network detection and response (NDR) alerts, user reports and helpdesk tickets, threat intelligence feeds and IOC matching, cloud security posture alerts (CSPM, CWPP), and identity threat detection (unusual authentication patterns, impossible travel).
Severity classification:
| Severity | Criteria | Response Time | Examples |
|---|---|---|---|
| Critical (P1) | Active data exfiltration, ransomware executing, critical system compromised | Immediate (< 15 min) | Ransomware deployment, active APT intrusion |
| High (P2) | Confirmed compromise with contained scope | < 1 hour | Compromised admin account, malware on server |
| Medium (P3) | Suspicious activity requiring investigation | < 4 hours | Phishing with credential entry, unusual outbound traffic |
| Low (P4) | Minor security event, low impact | < 24 hours | Failed brute force, policy violation |
Initial documentation should capture time of detection and detection method, affected systems/accounts/data, initial scope assessment, and evidence preservation actions taken.
3. Containment
Limit the scope and impact of the incident. Containment decisions balance stopping the attack against preserving forensic evidence and maintaining business operations.
Short-term containment (minutes to hours) involves isolating affected endpoints from the network (EDR network containment or switch port disable), disabling compromised user accounts and revoking active sessions, blocking attacker IP addresses and domains at the firewall/proxy, redirecting DNS for compromised domains, and preserving memory images and disk snapshots before reimaging.
Long-term containment (hours to days) involves applying temporary firewall rules restricting lateral movement, implementing additional monitoring on adjacent systems, rotating credentials for potentially exposed accounts, deploying emergency patches for exploited vulnerabilities, and standing up clean infrastructure in parallel if needed.
When making containment decisions, consider whether you can contain without alerting the attacker since covert containment preserves intelligence-gathering opportunities. Weigh the business disruption of containment against damage of continued compromise to assess blast radius. Ensure evidence preservation before any destructive actions if you have legal hold obligations.
4. Eradication
Remove the threat from your environment completely. Incomplete eradication leads to reinfection.
Identify the root cause to understand how the attacker gained initial access. Remove all malware, backdoors, webshells, and persistence mechanisms. Revoke and reissue compromised credentials and certificates. Patch the vulnerability that enabled initial access. Verify eradication by hunting for known IOCs and TTPs across the full environment. Check for secondary access since attackers frequently establish multiple persistence paths.
5. Recovery
Restore systems to normal operations with confidence that the threat has been eliminated.
Restore from clean, verified backups (not backups that may contain malware). Rebuild compromised systems from known-good images rather than attempting to clean them. Implement enhanced monitoring on recovered systems for 30-90 days. Gradually return systems to production, starting with least critical. Validate system integrity through security scanning before reconnecting to production networks. Monitor for indicators of recompromise.
6. Lessons Learned
Conduct a post-incident review within 72 hours while details are fresh. This phase is frequently skipped under operational pressure but is critical for improving future response.
The review structure should cover timeline reconstruction (what happened, when, and how was it detected?), response assessment (what worked well? what caused delays?), gap analysis (what visibility, tooling, or process gaps did the incident reveal?), root cause analysis (what underlying conditions enabled the incident?), and action items (specific, assigned, and time-bound improvements).
Deliverables include a post-incident report documenting timeline, scope, impact, and root cause; an updated IR plan incorporating lessons learned; new or improved detection rules for the attack technique; infrastructure or process changes to prevent recurrence; and an executive summary for leadership and board reporting.
Regulatory Reporting Obligations
The regulatory landscape for incident reporting has changed significantly. Your IR plan must account for these timelines.
SEC Cyber Incident Disclosure (Active)
Publicly traded companies must disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality. The disclosure must describe the incident’s nature, scope, timing, and material impact without revealing details that would aid attackers.
CIRCIA (Expected May 2026)
CISA’s CIRCIA final rule, delayed from October 2025 to May 2026, will require 72-hour reporting for substantial cyber incidents and 24-hour reporting for ransomware payments. It covers entities in all 16 critical infrastructure sectors exceeding SBA small business thresholds (approximately 300,000+ entities).
Other Requirements
HIPAA requires breach notification within 60 days for incidents affecting 500+ individuals. GDPR requires 72-hour notification to supervisory authority for personal data breaches. 50 US states have individual breach notification laws with varying timelines (most require notification within 30-60 days). PCI DSS requires immediate notification to card brands and acquiring bank for payment card data compromises. Most cyber insurance policies require notification to the carrier within 24-72 hours, and failure to notify can void coverage.
Testing Your IR Plan
An untested plan provides false confidence. Test regularly using escalating complexity.
Tabletop Exercises (Quarterly)
Walk through a scenario verbally with the IR team and stakeholders. Focus on decision-making, communication, and coordination rather than technical execution.
Sample scenarios include ransomware encrypting 40% of file servers on a Friday night, a threat actor exfiltrating customer database and posting on dark web forum, a compromised service account providing access to CI/CD pipeline, or an insider threat where a departing employee downloads sensitive IP.
Technical Exercises (Semi-Annually)
Execute response procedures against simulated attacks.
Run purple team exercises with controlled adversary simulation. Conduct EDR containment and forensic collection drills. Test backup restoration under time pressure. Execute the communication plan with simulated media inquiries.
Full Simulation (Annually)
Run an unannounced or semi-announced exercise engaging all stakeholders including executive leadership, legal, PR, and business units. Measure response times against SLAs and identify coordination breakdowns.
IR Plan Maintenance
Review and update the plan at minimum semi-annually and after every significant incident. Validate contact lists quarterly since people change roles and phone numbers change. Update runbooks as infrastructure, tools, and threat landscape evolve. Align with frameworks: NIST SP 800-61r3, CSF 2.0, and ISO 27035. Brief new team members and ensure they have access to all IR resources.