Analyst Field Guide · Security Operations
From the alert to the after-action: a calm, repeatable way to run a security incident — limit the harm, keep the evidence, restore trust, and come out of it stronger. Aligned to NIST SP 800-61 Revision 3 (CSF 2.0).
Incident response is decision-making under uncertainty, against a clock, with an adversary who gets a vote. The goal isn't to look calm — it's to limit harm, preserve the evidence that lets you understand what happened, and restore trustworthy operation, in that order. Panic destroys evidence and skips containment; a method keeps you moving even when you don't yet know the full picture.
First, a distinction that decides everything downstream. An event is any observable occurrence; an alert is an event a tool thought worth flagging; an incident is a confirmed (or high-confidence) adverse event that harms — or threatens — confidentiality, integrity, or availability. Most alerts are not incidents. Declaring an incident is a deliberate act with a definition behind it, not a vibe.
The responder's mindset, in four habits:
Incident response is the security sibling of root-cause analysis: IR is what you do while the building is on fire; RCA is the disciplined why you run afterward. Containment leans on segmentation and least privilege (Zero Trust); triage leans on calibrated judgment (Critical Thinking). This guide assumes those and focuses on running the incident.
The current model — NIST SP 800-61 Revision 3 (April 2025) — reframes incident response around the six CSF 2.0 Functions rather than the older, rigid four-phase lifecycle. The point of the change: IR isn't a thing you switch on for two days around an event; it's woven into ongoing risk management, with improvement running continuously.
The older four-phase lifecycle (Preparation → Detection & Analysis → Containment/Eradication/Recovery → Post-Incident Activity) wasn't wrong — it's the operational flow a responder still runs, and Rev 3 maps it into the Functions. The rest of this guide walks that operational flow, because that's what you do at 2 a.m.: prepare → detect & triage → contain → preserve evidence → eradicate → recover → learn.
You fight like you train. Almost everything that determines how an incident goes is decided before it starts — under Govern, Identify, and Protect.
Every hour spent here pays back tenfold during an incident. The difference between a two-hour containment and a two-week one is almost always something that was — or wasn't — done in advance.
Detection turns telemetry into an alert; triage turns an alert into a decision. The core question is the one from calibrated analysis: given the base rate — most alerts of this type are false — what about this one is actually diagnostic of a real incident? Don't anchor on the alert's name; confirm from evidence, and be willing to declare on high-confidence signal rather than waiting for certainty you'll never have mid-incident.
Once you suspect a real incident, classify its severity — that's what decides who gets paged and how fast. Severity is impact against urgency/spread:
Declaring is a threshold, and crossing it changes the mode: it pages the responders, starts the clock and the timeline, and hands authority to an incident commander. Under-declaring ("let's watch it") is how a contained problem becomes a breach; over-declaring burns the team's credibility and stamina. Both are failures of the same missing thing — clear declaration criteria set in advance.
Containment buys time and stops the harm from spreading while you figure out the rest. It comes in two moves: short-term (isolate right now — pull the network cable/segment, disable the account, block the C2 domain) and long-term (durable changes that hold while you rebuild clean).
Isolating loudly tips the attacker off (they may burn what they have, or trigger destructive payloads); watching quietly risks more damage and data loss. There's no universal right answer — it's a judgment call weighing evidence value against ongoing harm, and it's the incident commander's to make, ideally with legal in the loop. What's not a judgment call: preserve evidence while you contain — isolate the host, don't wipe it.
Evidence lets you scope the incident (how far did it go?), understand it (how did they get in?), and — if it comes to it — support legal or law-enforcement action. Careless response destroys it, and you rarely get a second capture.
Some evidence evaporates faster than others; capture in order of volatility (the principle behind RFC 3227). Roughly: memory and live network state → running processes and connections → the disk → centralized logs → backups/archive. A reboot to "fix" a host throws away the memory and volatile state — often the most valuable evidence there is.
Eradication removes the adversary's access and closes the way they got in. The failure mode here is treating a symptom as the cause — deleting the malware you found while leaving the web-shell, the backdoor account, or the unpatched vulnerability that let them in.
If the attacker has several footholds, evicting them one at a time is a game of whack-a-mole that alerts them to burn what's left. Where feasible, plan a coordinated eviction — close the identified accesses together — so you don't fight the same intruder twice.
Recovery returns systems to trustworthy production — deliberately, with validation, watching for the attacker's return.
Closing an incident restores operation and shrinks the risk that was exploited — it does not make the system "secure" in the abstract. State the residual risk: what you couldn't fully rule out, what you're watching, and what the post-incident review still needs to run down. Declaring victory too early — before eradication is confirmed — is a leading cause of the same attacker returning within days.
Ransomware is the incident most teams actually face, and it bends several phases at once. Containment becomes a race — isolate affected hosts and segments fast to stop the encryption spreading — but resist yanking power: memory can hold keys and evidence, so capture it per the order of volatility (see the Logging & Evidence guide) before you image and rebuild. Recovery leans entirely on backups, whose value was decided long before the incident: they must be tested and kept offline or immutable, because attackers target backups first. And modern ransomware is usually double extortion — data is stolen before it's encrypted — so restoring from backup ends the outage but not the breach: the exfiltrated data is still gone, which is a disclosure and legal matter, not just an IT one. The pay-or-don't-pay question is a business, legal, and sometimes sanctions decision (paying can be prohibited, and never guarantees a working key or that copies are deleted) — get counsel and, where appropriate, law enforcement involved early rather than deciding under pressure. None of this is a "secure" recovery: it restores service and closes the encryption vector while the exposure of stolen data remains.
Communication is a workstream, not an afterthought — and mishandling it can cause more lasting damage than the incident. Run it on two tracks.
Leadership needs impact and decisions, not packet captures. Legal and compliance need to be in early (they shape what's preserved, what's said, and what must be reported). Responders need a single source of truth — one channel, one current picture — and a set update cadence, so people stop interrupting the responders to ask "what's happening?"
Customers, partners, regulators, and possibly law enforcement. Who is authorized to speak externally is decided in advance (§3), and messaging goes through legal and comms. Say what you know, avoid speculation, and don't over-promise a resolution time mid-incident.
Breach-notification duties (who must be told, and how fast) vary widely by jurisdiction, sector, and contract, and they change. Do not assume a specific deadline or trigger from memory — the clock may start at "discovery," definitions of "breach" differ, and contractual duties can be stricter than law. Involve legal at declaration so the obligations are assessed against current, applicable rules, not a remembered figure.
The incident isn't over when service is restored — it's over when you've learned from it. Rev 3 makes this explicit: improvement is continuous, not a single meeting at the end.
Track how long attackers dwell before detection, and how long from detection to containment. Those two numbers — not the count of alerts — tell you whether your program is actually getting better.
Is it a real incident? (evidence, not the alert name) → declare + assign an incident commander → start the timeline → contain the immediate harm → preserve evidence (don't reboot/wipe) → open the comms channel.
Prepare → Detect & triage → Contain → preserve evidence → Eradicate (all footholds + the vector) → Recover (known-good, validate, watch) → Learn. Maps to NIST 800-61 Rev 3: Govern/Identify/Protect · Detect/Respond/Recover · Improve.
Impact × spread → a pre-agreed SEV scale that decides who's paged and how fast. Under-declaring lets a contained issue become a breach; over-declaring burns the team.
Contain before you investigate · collect most-volatile evidence first · assume more than one foothold · reset exposed credentials · get legal in early · never call it "secure" — state residual risk.
Blameless review · reconstruct the timeline & dwell time · hand the "why" to RCA · action items with owners → feed Preparation.
Framework: NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (finalized April 2025), which supersedes Revision 2 and its four-phase lifecycle. Verify the current revision and your applicable regulatory/contractual obligations before formal use — incident-response guidance and breach-notification rules both change. The severity matrix and SEV levels are illustrative; your organization defines them. Order-of-volatility follows the principle in RFC 3227. Companion to the Root Cause Analysis Field Guide (the "why" after the incident), Zero Trust and Access Decision (containment, blast radius, least privilege), Critical Thinking (triage judgment and calibration), and Troubleshooting.