What is an incident response plan?
An incident response plan is a documented, practiced process for detecting, containing, and recovering from security incidents, and for communicating during them. Frameworks like SOC 2 and ISO 27001 expect one, and it is what keeps a bad day from becoming a catastrophe.
Definition
An incident response plan is a written, rehearsed set of procedures that defines how an organization detects, responds to, contains, and recovers from a security incident, and who does what while it happens.
Background
A widely used model (from NIST SP 800-61) describes incident response as a lifecycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. A good plan names roles and an incident commander, defines severity levels, spells out communication (internal, customers, and regulators where breach-notification laws apply), and is tested with tabletop exercises so people know their part before a real event.
Why it matters
Incidents are a matter of when, not if. Under pressure, teams fall back on what they have practiced. A clear, tested plan shortens containment, reduces damage, and keeps communication calm and compliant, and auditors and customers expect you to have one.
Step by step
- Prepare: define roles, severities, tooling, and contacts before anything happens.
- Detect and analyze: recognize an incident and assess its scope and severity.
- Contain: stop the bleeding, isolate affected systems, and preserve evidence.
- Eradicate and recover: remove the cause and restore systems to normal safely.
- Communicate: notify internal stakeholders, and customers or regulators where required.
- Learn: run a post-incident review and feed the lessons back into the plan.
Examples
- A phishing-driven account compromise is contained by disabling the account and rotating credentials, then reviewed to add stronger MFA.
- A tabletop exercise reveals no one knew who could authorize customer notification, which the plan is then updated to fix.
Common mistakes
- Writing the plan and never testing it, so roles are unclear during a real incident.
- Ignoring communication and breach-notification obligations until the clock is already running.
- Skipping the post-incident review, so the same weakness causes the next incident.
FAQ
What are the phases of incident response?
A common model is preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity (lessons learned).
How often should an incident response plan be tested?
Regularly, typically at least annually, using tabletop exercises so the team practices roles and decisions before a real incident.
Do compliance frameworks require an incident response plan?
Yes. SOC 2, ISO 27001, and others expect a documented, operating incident response capability, including evidence that it is tested.
Do this in Keel, not a spreadsheet
Keel is the AI-native GRC platform for SMBs: one control-and-evidence graph across SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, and more. Start free, no credit card.
Start free