The average time to identify and contain a data breach is 277 days. Organizations with a tested incident response (IR) plan contain breaches 54 days faster than those without one — saving an average of $2.66 million per incident. An IR plan isn’t just good security practice; it’s a measurable financial safeguard.
This guide walks through building an IR plan from scratch, following the NIST SP 800-61 framework — the industry standard for incident response.
The 4 Phases of Incident Response (NIST Framework)
Phase 1: Preparation
Everything you do before an incident occurs. This is the most important phase and the one most organizations neglect. Good preparation means faster, more effective response when an attack actually happens.
Phase 2: Detection and Analysis
Identifying that an incident has occurred, determining its scope, and understanding what’s happening. This phase is often the hardest — attackers average 207 days on a network before being detected.
Phase 3: Containment, Eradication, and Recovery
Stopping the attacker from doing more damage, removing them and their tools from your environment, and restoring systems to normal operation.
Phase 4: Post-Incident Activity
Learning from the incident to prevent recurrence. Documenting lessons learned and improving your defenses.
Phase 1: Preparation — What You Need Before an Incident
IR Team Roles and Contacts
Define who does what during an incident before the incident happens. Minimum roles needed:
- Incident Response Manager: Coordinates overall response, makes decisions, communicates with leadership
- Technical Lead: Leads technical investigation and remediation
- Communications Lead: Handles internal communications, press statements, regulatory notifications
- Legal Counsel: Advises on regulatory obligations, breach notification requirements, law enforcement engagement
- External IR Firm: Have a retainer with a forensics firm before you need them — it’s too late to vet vendors during an active breach
Create an IR contact list with: name, role, cell phone, personal email (in case corporate systems are compromised), and backup contact. Print it. If your email and phones are down during a breach, you need physical copies.
IR Toolkit
Prepare the tools you’ll need in advance:
- Forensic investigation tools: Velociraptor, KAPE, FTK Imager, Autopsy
- Memory capture tools: WinPmem, DumpIt, LiME (Linux)
- Network traffic capture: Wireshark, tcpdump
- Log collection: Configured SIEM (Wazuh, Splunk, ELK)
- Out-of-band communication channel: Signal group, personal phones — anything that doesn’t depend on compromised corporate infrastructure
- Clean investigation workstation: Air-gapped or fresh machine for forensic analysis
Establish a Baseline
You can’t identify abnormal behavior if you don’t know what normal looks like. Document: normal network traffic patterns, typical login times and locations, standard running processes on servers, expected outbound connections. This baseline makes anomaly detection possible.
Phase 2: Detection and Analysis Template
Incident Severity Classification
Define severity levels so the team knows how urgently to respond:
- SEV-1 (Critical): Active breach in progress, ransomware spreading, data actively being exfiltrated, customer PII exposed. Immediate all-hands response.
- SEV-2 (High): Confirmed malware on a system, unauthorized access to sensitive systems, confirmed phishing with credential compromise.
- SEV-3 (Medium): Suspicious activity under investigation, potential policy violation, malware on isolated workstation.
- SEV-4 (Low): Single system anomaly, spam/phishing email that wasn’t clicked, minor policy violation.
Initial Analysis Checklist
- ☐ What systems are affected? (Get a list, isolate from network if active threat)
- ☐ What data may have been accessed or exfiltrated?
- ☐ What is the timeline? (First indicator of compromise)
- ☐ How did the attacker gain initial access?
- ☐ Is the attacker still active in the environment?
- ☐ Are backups intact and unaffected?
- ☐ Does this trigger breach notification obligations? (Get legal counsel involved)
Evidence Preservation
Before doing anything else, preserve evidence. This is critical for forensics, legal proceedings, and insurance claims:
- Take memory dumps of affected systems BEFORE powering them off
- Take disk images BEFORE remediation
- Collect and preserve all relevant logs (firewall, SIEM, authentication, endpoint)
- Document everything with timestamps — what you did and when
- Follow chain of custody procedures if law enforcement may be involved
Phase 3: Containment, Eradication, Recovery
Short-Term Containment
Immediate actions to stop the bleeding without destroying evidence. Options (choose based on situation):
- Isolate affected systems by blocking their network access (VLAN change, firewall rule, unplug network cable)
- Disable compromised user accounts
- Block attacker’s known IP addresses and domains at firewall/DNS
- Revoke compromised API keys and credentials
Eradication
- Remove all attacker tools, malware, and backdoors
- Identify and close the initial access vector
- Scan all systems for related indicators of compromise (IoCs)
- Reset credentials for all potentially compromised accounts — prioritize privileged accounts
- Apply patches for the vulnerability that enabled initial access
Recovery
- Restore systems from clean, verified backups (verify backups weren’t also compromised)
- Rebuild compromised systems from scratch when in doubt
- Verify system integrity before reconnecting to network
- Monitor restored systems closely for 30 days post-incident
- Maintain heightened logging and monitoring during recovery period
Phase 4: Lessons Learned
Within 2 weeks of incident resolution, hold a lessons-learned meeting. Answer these questions:
- What exactly happened, and what was the timeline?
- How was the incident detected? How could detection have been faster?
- What went well in the response?
- What went poorly or was missing?
- What changes to security controls, monitoring, or processes are needed?
- Were procedures documented and followed?
Document findings in a formal post-incident report. Track remediation actions with owners and deadlines. Don’t skip this step — the lessons-learned phase is what prevents the same incident from happening again.
Testing Your IR Plan
An untested IR plan is just a document. Test it regularly through:
- Tabletop exercises: Walk the team through a scenario verbally. “A ransomware alert fires at 2 AM on a Friday — what do you do first?” No real systems involved, pure discussion. Do these quarterly.
- Functional exercises: Actually execute specific parts of the plan (activate the war room, test out-of-band communications, simulate escalation). Annually.
- Full simulation: Red team / blue team exercises where an internal or external red team actually attacks your environment and the IR team responds for real. Annually for mature organizations.
Summary
An incident response plan built before you need it — and tested regularly — is one of the highest-value investments in your security program. It dramatically reduces response time, limits damage, satisfies regulatory requirements, and protects you legally. Start with the four NIST phases, assign clear roles, and run tabletop exercises. You won’t regret it when the real thing happens.