Organizations with a tested incident response plan contain breaches in 73 days on average. Organizations without one take 197 days. That 124-day gap costs roughly $1 million in additional breach costs according to IBM’s 2025 Cost of a Data Breach report. The IR plan does not need to be 200 pages. It needs to be specific enough that the on-call analyst at 2 AM knows exactly what to do and who to call without improvising. Here is how to build one.
Before an Incident: The Preparation Phase
Most IR plans fail during incidents because they were written by legal and never tested by the people who actually respond. Build the foundation before you need it:
- Define your IR team: Name specific people for each role — Incident Commander, Technical Lead, Legal/Compliance, Communications Lead, and Executive Sponsor. Include backup contacts. Update quarterly.
- Establish your severity classification: P1 (business-critical systems down, active breach, data exfiltration confirmed) through P4 (no customer impact, no data at risk). Severity determines response speed and escalation path.
- Pre-negotiate external resources: Retain an IR firm (Mandiant, CrowdStrike Services, Secureworks, or a regional firm) before you need them. Retainer agreements give you priority response and fixed pricing. Without a retainer, you compete with every other breach victim for availability.
- Run tabletop exercises quarterly: Two hours, a realistic scenario, the right people in the room. Not a lecture — a discussion of what each person would do at each decision point. Find gaps before attackers do.
Phase 1: Detection and Analysis
The clock starts the moment you suspect an incident. Not when it is confirmed — when you suspect it. The detection source matters: SIEM alert, EDR detection, user report, third-party notification, or (worst case) ransomware note. Whatever the source, the first action is the same: open an incident ticket, document everything from the start, and activate the IR team.
During analysis, answer three questions before containment:
- What systems are affected? (Initial scope)
- Is the attacker still present? (Active vs. historical incident)
- Is data being exfiltrated right now? (Escalates urgency of containment)
Evidence preservation: Before you touch anything, capture forensic artifacts: memory dumps from affected systems, log exports from the relevant time window, network captures if available. Containment that destroys evidence creates legal and insurance problems downstream.
Phase 2: Containment
Containment decisions involve tradeoffs between speed and evidence preservation. Short-term containment isolates affected systems to stop ongoing damage; long-term containment addresses the attack vector to prevent re-infection.
- Isolate, do not power off. Pulling a network cable preserves memory artifacts that powering down destroys. Volatile memory often contains decryption keys, attacker tools, and active network connections.
- Block attacker infrastructure. Push IOCs (IPs, domains, file hashes) to your firewall, EDR, and DNS filter immediately. Check threat intelligence feeds for related infrastructure.
- Disable compromised accounts. Do not just reset passwords — disable accounts entirely during investigation. Attackers with existing sessions can maintain access through password resets.
- Preserve the attack path. Before remediating the initial access vector, document it thoroughly. You need to understand how they got in to confirm that the vector is truly closed after remediation.
Scope creep is real: Initial containment often identifies additional affected systems not in the original scope. Budget time and capacity for scope expansion — most ransomware incidents that appear to affect 20 systems actually affect 80-200 when fully investigated.
Phase 3: Eradication
Remove all attacker presence from the environment. This includes: malware and attacker tools on compromised systems, unauthorized accounts and backdoors created during the intrusion, persistence mechanisms (scheduled tasks, registry run keys, WMI subscriptions, cron jobs), and any modified legitimate binaries. Use your EDR’s threat hunting capability to search for IOCs and MITRE ATT&CK techniques observed during the incident across the entire environment — not just the initially identified systems.
Phase 4: Recovery
Restore affected systems from clean backups or rebuild from known-good images. Verify that restored systems do not contain attacker persistence before returning them to production. Harden the environment against recurrence: apply patches that addressed the initial access vector, implement additional monitoring, and consider deploying deception technologies (honeypots) in the affected segments.
Monitor intensively for 30 days post-incident. A significant percentage of attacks involve a secondary payload or additional attacker foothold not discovered during initial investigation. Increased logging verbosity and lower alerting thresholds during this period are appropriate.
Phase 5: Notification and Legal Requirements
- GDPR: 72-hour notification to supervisory authority from when you became aware
- US state laws: Range from 30 days (California) to 90 days depending on state and data type
- SEC (public companies): Material cybersecurity incidents must be disclosed within 4 business days of determination that the incident is material
- HIPAA: 60 days from discovery for breach affecting 500+ individuals; annual notification for smaller breaches
- Cyber insurance carrier: Most policies require notification within 24-72 hours of discovery to preserve coverage
Post-Incident Review
Conduct a post-incident review within two weeks while details are fresh. The review is not a blame session — it is a structured analysis of: what happened and when (full timeline), how the attacker got in, what detection controls failed and why, what slowed the response, and what specific improvements will prevent recurrence. Assign owners and deadlines to every action item. Update your IR plan with lessons learned before filing it away.
Takeaway: The organizations that respond effectively to breaches rehearse their response plan before they need it. Schedule a tabletop exercise in the next 60 days. Read NIST SP 800-61 Rev 3 for the authoritative IR framework. Review our Security Tools page for IR platform and forensics tool recommendations.
🔗 Further Reading
Frequently Asked Questions
What is the NIST Incident Response framework?
The NIST Incident Response framework, defined in NIST Special Publication 800-61, organizes incident response into four phases: Preparation (building IR capability before incidents occur), Detection and Analysis (identifying and validating incidents), Containment, Eradication, and Recovery (stopping the attack and restoring systems), and Post-Incident Activity (lessons learned and documentation). The framework emphasizes that preparation — IR plan documentation, team training, and tabletop exercises — is as important as the response itself.
What is the difference between containment and eradication in incident response?
Containment stops the spread of an incident and limits damage while the investigation continues. It includes isolating affected systems, blocking attacker infrastructure, and disabling compromised accounts. Eradication removes all traces of the attacker from the environment: deleting malware, closing backdoors, removing unauthorized accounts, and patching the exploited vulnerability. Containment is immediate; eradication follows after full scope determination to ensure all attacker presence is removed simultaneously.
When must a GDPR data breach be reported?
Under GDPR Article 33, a personal data breach must be reported to the relevant supervisory authority within 72 hours of the organization becoming aware of it, if the breach is likely to result in a risk to individuals' rights and freedoms. Under Article 34, if the breach is likely to result in a high risk to individuals, those individuals must also be notified without undue delay. Low-risk breaches (e.g., encrypted device with no evidence of access) may not require individual notification but must be documented internally.
What should be included in a cyber incident response plan?
A comprehensive incident response plan should include: scope definition and plan objectives; incident classification and severity levels (P1-P4); IR team roles and contact information with backups; escalation procedures and communication trees; specific playbooks for common incident types (ransomware, BEC, data breach, DDoS); evidence preservation procedures; containment decision criteria; notification requirements (legal, regulatory, insurance, customers); external resource contacts (IR firm retainer, legal counsel, PR); and post-incident review process.
