How Do You Build an Incident Response Plan That Works?

Most organizations don't fail at incident response because they lack tools. They fail because nobody agreed in advance who does what, and the first real incident becomes a meeting instead of a response.

Start with the phases, not the playbook

NIST SP 800-61 lays out four phases: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity. That order matters. Teams love to jump straight to containment because it feels productive, but if you haven't done the preparation work, you don't know your own network well enough to contain anything cleanly.

Preparation means asset inventories that are actually current, not the spreadsheet from 2022. It means knowing your log retention window (if it's 7 days and the attacker had 30 days of dwell time, you've already lost the timeline). It means pre-staged forensic tooling — Velociraptor, KAPE, or even a documented tar/dd procedure for disk images — so nobody's downloading tools onto a compromised host during an active incident.

Define severity levels before you need them

A SEV1 (active data exfiltration, ransomware detonation, domain admin compromise) needs a different response than a SEV3 (isolated malware on one unprivileged workstation). Write this down as a matrix: impact vs. scope vs. confidence. Assign each severity a required response time and an escalation path. If your incident commander for a SEV1 is the same person who has to approve every $500 purchase order, you've built a bottleneck into your own emergency process.

The incident commander role isn't optional

One person runs the incident. Not the most senior engineer by default — the person best suited to coordinate, delegate, and make containment calls under pressure. This person doesn't necessarily touch a keyboard during the response; they track the timeline, manage communication with legal and leadership, and decide when to pull the trigger on isolating a segment or taking a system offline.

Without this role, you get five people SSH'd into the same box, none of them talking to each other, and no one capturing volatile memory before someone reboots the machine to "see if it fixes it."

Containment decisions that actually matter

The hardest call in most incidents is: isolate now, or observe a little longer to understand scope? Pulling network access too early tips off an attacker still moving laterally and destroys your chance to see their next move. Waiting too long lets ransomware finish encrypting shares.

A reasonable middle ground: use network segmentation and EDR isolation (CrowdStrike, Defender for Endpoint, SentinelOne all support this) to cut a host off from lateral movement while keeping it powered on for memory capture. Full shutdown should be a last resort — it kills volatile evidence and, for ransomware cases, can trigger anti-forensic behavior baked into some payloads.

Logging gaps you'll regret during, not before

Windows Event Log defaults are not enough. If you don't have Sysmon deployed with a decent config (SwiftOnSecurity's or Olaf Hartong's baseline configs are a solid starting point), you'll be reconstructing process trees from fragments. On the network side, NetFlow or Zeek logs matter more than most orgs realize until they need to answer