When an alert becomes an incident, a repeatable process keeps a crisis from becoming chaos. Learn the six phases and why preparation decides how the other five go.
Why: incident response follows a repeatable lifecycle — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned (PICERL) — so a stressful event is handled methodically instead of by panic. When: follow the phases in order; skipping containment to rush eradication often destroys evidence or misses attacker footholds. Where: this is the industry-standard model (NIST SP 800-61); the deliverable is a restored, understood, and hardened environment.
PREPARE ─► IDENTIFY ─► CONTAIN ─► ERADICATE ─► RECOVER ─► LESSONS
(before) (is it real, (stop the (remove the (restore (postmortem,
what's the spread) foothold) safely + improve)
scope?) verify)
Don't skip ahead: contain before you eradicate; eradicate before you
recover; ALWAYS finish with lessons learned.Why: the work you do before an incident — runbooks, logging, backups, access, contacts — determines how fast and cleanly you respond, because you cannot build these under fire. When: invest in preparation continuously; an incident is an audit of it. Where: teams that prepared detect and contain in hours; those that did not spend days just figuring out what they have.
PREPARATION checklist (done BEFORE any incident):
[ ] IR plan + runbooks for common scenarios (ransomware, account theft)
[ ] logging + a SIEM already collecting the right data (Detection course)
[ ] tested, offline backups you can actually restore from
[ ] an asset inventory (you can't protect what you don't know exists)
[ ] contacts: on-call, legal, comms, execs, external IR retainer
[ ] out-of-band comms (assume the primary channel is compromised)Why: the first live phase is confirming an alert is a genuine incident and scoping it — which systems, accounts, and data are affected — because the response depends on the blast radius. When: triage the alert (from the SOC), establish a timeline, and declare an incident with a severity. Where: start the timeline immediately and record everything; accurate scoping prevents both overreaction and missed footholds.
IDENTIFY answers three questions:
1. is this a real incident, or a false positive?
2. what is the SCOPE — which hosts, accounts, and data are involved?
3. how SEVERE — impact + urgency -> declares priority and who's paged
Start the incident timeline NOW (what happened, when, who did what).
Under-scoping leaves the attacker a foothold; over-scoping wastes effort.