The Incident Response Lifecycle
An incident is not the time to figure out how to respond — the response has to be planned, practiced, and ready, because under pressure teams do what they have rehearsed. The classic lifecycle (preparation, identification, containment, eradication, recovery, lessons learned) gives that structure, and the single most important phase is the one before any incident: preparation.
This topic frames the whole chapter with the PICERL lifecycle and the plans, roles, and decisions that must exist before the intruder is found — because a team improvising the org chart mid-breach has already lost time it cannot recover.
Preparation — the Phase That Decides the Rest
The IR plan, defined roles (incident commander, communications, technical leads), contact trees, tooling, and access must be ready in advance. A team that improvises structure under pressure loses the critical early time when an intrusion is most contained — preparation is not paperwork, it is the difference between a coordinated response and a panicked one at 2 a.m.
Identification and Scoping
Confirm it is a real incident (not a false positive), classify its severity, and scope it: which systems, accounts, and data are affected. Premature narrow scoping — assuming one host when it is ten — is a classic mistake that lets the attacker persist through a containment that missed most of their footholds. Assume more is affected until the evidence proves otherwise.
Containment, Short and Long Term
Stop the spread — isolate hosts, disable accounts, block command-and-control — without tipping off the attacker prematurely or destroying evidence. There is a real tension here between containing fast and preserving forensics or watching to understand scope, and resolving it deliberately per incident is part of the skill (the next topics go deeper).
Eradication, Recovery, and Lessons
Eradication removes the attacker's access completely — every foothold, persistence mechanism, and credential (Chapter 8) — and recovery restores to known-good and monitors closely for return. Recovering a system that still has the attacker's persistence just restarts the incident. Then comes the blameless lessons-learned review (the final topic), because skipping it guarantees the next incident looks just like this one.
Both describe the same flow with different groupings. NIST (SP 800-61 Rev. 2): Preparation → Detection & Analysis → Containment/Eradication/Recovery → Post-Incident. Note that Rev. 2 was superseded by Rev. 3 (2025), which drops the fixed phase model and instead maps IR activities onto the CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover) — so cite the phase names as Rev. 2, not current NIST guidance.
SANS (PICERL): Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned. Pick one as your team's shared vocabulary and rehearse it.
- No plan or roles defined before an incident, so the team improvises structure under pressure and loses critical early time.
- Premature scoping — assuming the breach is smaller than it is — so containment and eradication miss footholds and the attacker persists.
- Containing so aggressively that you destroy evidence or tip off the attacker before understanding scope, or so slowly that they spread.
- Recovering systems without full eradication, leaving persistence that reignites the incident.
- Skipping the lessons-learned review, so the same incident recurs.
- Invest in preparation: a tested IR plan, clear roles, contact trees, tooling, and access ready before you need them.
- Scope thoroughly before declaring containment complete; assume more is affected until proven otherwise.
- Balance containment speed against evidence preservation and scope understanding, deciding deliberately per incident.
- Eradicate completely — all footholds, persistence, credentials — and monitor closely post-recovery.
- Always run a lessons-learned review and feed its findings back into the program.
Knowledge Check
Which IR phase most determines how well the whole incident goes?
- Preparation — the plan, roles, and tooling ready before any incident occurs
- Recovery, because it is the final step
- Identification, because it comes first during the incident
- Eradication, because it removes the attacker
Why is premature narrow scoping a dangerous mistake?
- It lets the attacker persist through a containment that missed footholds
- It makes the final written incident report far longer than it needs to be
- It always tips off the watching attacker immediately
- It violates data-retention law
Why does recovering a system without full eradication restart the incident?
- Leftover access lets the attacker return
- Recovery corrupts the known-good backups automatically
- Known-good images can never really be trusted
- Recovery always requires paying the attacker
You got correct