CYBER-06-002-P · Primer — The Incident Response Lifecycle

The idea in one sentence

The incident response lifecycle is NIST's repeatable four-phase loop for handling a security incident — Preparation; Detection & Analysis; Containment, Eradication & Recovery; and Post-Incident Activity — where the end of one incident makes the response to the next one faster.

Why it exists

An intrusion under way is the worst possible moment to be inventing a process. Imagine trying to bake a cake while the oven is on fire: you’ll scramble, drop ingredients, and end up with a mess you can’t eat. Without a rehearsed plan, an incident is pure chaos: three people SSH into the same box and step on each other, someone reboots the server and wipes the memory‑resident malware you needed as evidence, the legal team learns about it from a journalist, and — because nobody wrote down what happened — the same phishing lure lands the same way next month. NIST SP 800-61 exists to replace that scramble with a checklist everyone rehearsed while it was calm. It turns "we got hacked, now what?" into a set of named phases with owners, entry criteria, and hand‑offs, so that under pressure the team executes a plan instead of improvising one.

How it works

The lifecycle has four phases, and the arrows between them matter as much as the boxes. Preparation is everything you do before an incident: deploy EDR and centralize logs in a SIEM, write playbooks, set an on‑call rota, stock a jump kit, and run tabletop exercises. Most of the real work lives here. Detection & Analysis is the phase you actually notice — an alert fires (say Wazuh flags suspicious PowerShell spawning from a Word document), an analyst triages it in the SIEM, correlates related signals, and decides: real incident or false positive, and how big? This phase is iterative — new evidence loops you back to re‑scope. Containment, Eradication & Recovery is the response: first contain (network‑isolate the affected hosts, disable the compromised account) to stop the bleeding, then eradicate (remove the malware and its persistence, reset credentials), then recover (reimage, restore from clean backups, and monitor for reinfection before declaring "business as usual"). Post‑Incident Activity is the lessons‑learned review: what let this in, what slowed us down, and what one detection or control would catch it faster — and those answers feed straight back into Preparation.

A worked example: an EDR alert triggers on three workstations at 09:12 AM. Analysis shows a single phishing email that harvested user jdoe’s credentials and dropped a loader on the three hosts. The team isolates all three hosts and disables jdoe’s account by 09:45 AM (33 minutes). Eradication removes the loader, deletes the persistence registry key, and forces a password reset for 12 accounts by 10:30 AM. Recovery re‑images the three machines, restores user data from the latest backup, and monitors for beaconing until 12:00 PM, when the hosts are declared clean. Post‑incident review discovers the mail filter missed the lure because the rule allowed “*.docx” attachments from trusted domains; the team adds a new rule and writes a Sigma detection, closing the door for the next attack.

See it — the four phases are a loop, not a line

flowchart LR
  A["Preparation"] --> B["Detection &<br/>Analysis"]
  B --> C["Containment,<br/>Eradication &<br/>Recovery"]
  C --> D["Post-Incident<br/>Activity"]
  D -->|"lessons learned"| A
  B -->|"new evidence"| B

The one gotcha

The single thing to remember is the lifecycle is a continuous loop, not a one‑off checklist. The most common failure is treating incident response as a linear to‑do list—contain, wipe, close, and move on—while silently skipping Post‑Incident Activity because the fire is out and everyone is exhausted. Skipping that final phase means you never fix the mail filter that let the phishing email in, so the same attacker walks through the same door next month and you fight an identical incident from scratch. Equally dangerous is reversing the middle steps: jumping straight to eradication and reimaging before you’ve contained and collected evidence. Destroying artifacts early erases the forensic trail you need to understand the full scope, leaving hidden footholds alive. Always contain first, preserve evidence, then eradicate, and close the loop each time.

The one-line takeaway

Incident response is a loop — every incident should make the next one shorter.

Where you'll meet it

You will run this loop with real tools. Detection & Analysis lives in a SIEM — Wazuh, OpenSearch, or Graylog (or their commercial cousins Splunk and Microsoft Sentinel) — correlating logs, often with Sigma rules translated to your query language. Containment and eradication run through EDR/XDR: Wazuh, osquery, or Velociraptor let you isolate a host and hunt down persistence remotely. Case management and evidence tracking happen in TheHive with Cortex for automated enrichment, and repetitive steps get automated in a SOAR platform like Shuffle. You map the adversary's observed behavior to MITRE ATT&CK to reason about what else they might do, and you feed and consume threat intelligence through platforms like MISP and CISA advisories. NIST SP 800-61 Rev. 3 (2025) reframes this same lifecycle around the CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover), and the SANS PICERL model (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) is the same loop with six labels — so whichever framework your shop cites, you are running these phases.

Named concepts: incident response lifecycle, preparation, detection and analysis, containment eradication and recovery, post-incident activity