Writing an Incident Response Plan You'll Actually Use
A practical guide to building an incident response plan that covers what auditors need and actually works when something goes wrong at 2am.
The phishing email hit at 3:17pm on a Friday. By 4pm, the attacker was authenticated inside a developer's AWS account. The engineer who spotted the alert didn't know if this was a real incident, who owned the response process, or whether to kill the session immediately or wait for approval. He called his manager. His manager called the CTO. The CTO wasn't sure whether they had an incident response plan or where it was.
They did have one. It was a Word doc from 2022, last opened to satisfy a security questionnaire, filed in a shared folder nobody remembered. It covered none of the specifics of an AWS compromise.
An incident response plan is only useful if it exists in a form you can follow under pressure. Here's how to build one that meets the compliance bar and actually works when you need it.
What an IRP is — and what it isn't
An incident response plan is a documented, pre-agreed set of procedures for detecting, containing, and recovering from security incidents. In practice, it's the document that answers: "Who do we call, what do we do first, and what do we have to log?"
What it doesn't need to be: long, formal, or written by lawyers. Most teams do better with a single-page document that gets read during exercises than a forty-page policy living in a GRC tool that never sees daylight. The format matters far less than the specifics. Specifics are the whole point.
The four phases that structure every response
NIST SP 800-61 — the standard reference for incident response — breaks the lifecycle into four phases. Every reasonable IRP follows this arc whether or not it explicitly cites NIST.
Preparation is everything you do before an incident happens: defining what counts as an incident, assigning roles, setting up communication channels, and making sure your monitoring has the visibility you'll need. A team that skips the preparation work fumbles in every phase that follows.
Detection and analysis is where you figure out what's happening. Is this a real incident or a false positive? What systems are affected? How far back does the activity go? Good detection requires logging tuned to catch real events, not default configurations generating noise you've trained yourself to ignore.
Containment, eradication, and recovery is the active response. Containment stops the bleeding — isolating affected systems, revoking compromised credentials. Eradication removes the threat. Recovery restores normal operation. These three steps collapse together in practice, which is why pre-written playbooks for common incident types matter so much: you don't want to design your containment strategy while the attacker is still in the environment.
Post-incident activity is what separates teams that improve from teams that repeat the same incidents. Every declared incident above a certain severity should produce a written retrospective: what happened, what worked, what failed, and what changes are going out as a result with owners and due dates. This is the step most often skipped, and skipping it means you never close the feedback loop.
What SOC 2 auditors actually look for
Incident response sits under CC7.3 through CC7.5 in the SOC 2 Trust Services Criteria. The auditor isn't checking that your plan is eloquently written. They're checking three things:
- Does a documented process exist? The plan needs to be a real artifact, not a verbal understanding.
- Is it being followed? If incidents occurred during the observation window, there should be evidence you followed the process — tickets, logs, communication records, a completed post-mortem.
- Is it being tested? If no real incidents occurred, a tabletop exercise shows the plan was at least walked through by the people who would execute it. Auditors expect at minimum one exercise per year covering a realistic scenario.
The thing that trips teams up most: the plan has to specify communication requirements, including when affected users or customers get notified. The criteria expect a documented notification procedure, not something your CEO improvises at midnight.
Roles: who does what
A plan without named owners is just an essay. Every IRP needs at minimum:
- An incident commander — the single person coordinating the response. Not necessarily technical; their job is decision-making and communication, not forensics.
- A technical lead — the engineer or security person doing the actual triage and containment work.
- A communications owner — who handles internal updates and, if needed, customer-facing statements. In a small company this is often the CEO. Just pick someone before you need them.
- Legal or outside counsel contact — not for every incident, but for anything that touches personal data or creates regulatory exposure.
For most startups and mid-size companies, one person covers multiple roles. That's fine. The IRP just needs to reflect reality, not an org chart you wish you had.
Severity levels
Not every alert is a drop-everything emergency. Building severity levels into the plan lets you calibrate the response without convening a war room over a configuration drift finding. A reasonable starting point:
- P1 (Critical): Active breach, confirmed data exfiltration, ransomware, or service outage with potential data exposure. All hands. Management notified immediately. External legal likely.
- P2 (High): Suspicious access pattern confirmed, credential compromise with uncertain impact, or unauthorized change to a production system. Incident commander activated, response begins within one hour.
- P3 (Medium): Policy violation, anomaly under investigation, failed attack attempt. Assigned to on-call with follow-up documented within 24 hours.
- P4 (Low): Informational findings, misconfiguration without exploitation evidence. Ticket created, tracked in normal workflow.
The right cutoffs depend on your company and what you're protecting. What matters is that your team agrees on the lines before they're under pressure, not while they are.
Test it before you need it
A plan that's never been practiced will fail when used for the first time. In my experience, the failure mode isn't usually a missing procedure — it's that nobody knows where the document is, or the person named as incident commander changed roles eight months ago.
Annual tabletop exercises are the baseline. Pick a realistic scenario — phishing-led credential compromise is the most common starting point — and walk the relevant team through it step by step. Document where the plan works and where it falls apart. The gaps you find in a tabletop are exactly the ones you'd discover at 2am under live fire.
When you're designing the scenario, make it stress-test your actual controls. If you're working on least privilege and MFA enforcement, run the scenario through the lens of what an attacker can do if one of those controls fails. That reveals far more than a generic walkthrough.
Keeping it current
An IRP that reflects your 2023 stack is a document, not a plan. Every significant infrastructure change — a new identity provider, a cloud migration, a new production database — should trigger a review of the relevant playbooks. Personnel changes matter too. If the person listed as technical lead has left the company, the plan is already broken.
Build a review cadence into the maintenance schedule: once a year at minimum, and immediately after any real incident or major infrastructure change. If you're aligning to a framework, your NIST CSF 2.0 mapping should cross-reference your incident response controls specifically so you can see when they drift out of alignment.
The teams that handle incidents well treat the IRP like code: version-controlled, with owners, updated when the underlying system changes. The teams that struggle treat it like a policy artifact — published once, reviewed annually under duress, discovered to be useless at the worst possible moment.