The Incident Lifecycle: From Escalation to Closure
What is it?
Incident response (IR) is the disciplined process of handling a confirmed intrusion from declaration to closure. It runs in ordered phases — preparation, identification, containment, eradication, recovery, and lessons learned (the NIST / PICERL lifecycle). The order is not a suggestion: you contain before you eradicate, and eradicate before you recover, and you never skip ahead. A role — the incident commander — owns coordination so the response does not dissolve into chaos.
Why it matters
Under pressure, the instinct is to 'just clean it up' — pull the plug, delete the malware, restore from backup. Done in the wrong order, that destroys the evidence you need to understand the breach, tips off the attacker, and leaves footholds you never found, so they return. The lifecycle exists precisely to override panic with a sequence that stops the damage without sabotaging the investigation or the recovery.
Where you see it
An incident is declared when triage or a hunt confirms real, significant malicious activity — exactly the live escalation Module 8 produced. From there it is run as a coordinated case: an incident commander, a timeline, defined severity, and hand-offs to containment, forensics and recovery, ending in a documented post-incident review.
What normal looks like
A well-run incident follows the sequence: identify and declare with a severity, contain to stop the spread, scope how far it reached, eradicate every foothold across that scope, recover with validation, then hold a lessons-learned review. Each phase has an owner and is recorded, so anyone can see where the incident stands and what happens next.
What suspicious looks like
A broken response jumps straight to eradication or recovery: wiping the host before scoping (so other compromised machines are missed), restoring from backup before eradication (re-infecting from a foothold left behind), or acting with no commander so three people take conflicting actions. The tell is any step taken out of order or without coordination.
How analysts investigate
When an incident is declared, establish command and severity first, then work the phases strictly in order: contain to halt spread, scope to learn the full reach, eradicate across the whole scope, recover with validation, and close with a review. At each phase ask 'is the previous phase actually complete?' before advancing — the discipline is in refusing to skip.
Common beginner mistakes
- Jumping to eradication or recovery before the intrusion has been scoped.
- Running the response with no incident commander, so actions conflict and gaps open.
- Treating 'the malware is deleted' as the end, skipping recovery validation and lessons learned.
What you will be able to do
- Name the incident-response phases and the order they must run in.
- Explain why order matters — why you never eradicate before scoping.
- Describe the incident commander's role and severity-driven response.
Your hunt found a live intrusion and escalated it. Now what happens is not improvisation — it is a lifecycle with a fixed order, because every out-of-order shortcut has a predictable cost. Wipe first and you lose the evidence and the scope; restore first and you re-infect from a missed foothold. The phases are a discipline that protects you from your own panic.
INCIDENT LIFECYCLE (order is not optional)
PREPARE -> IDENTIFY -> CONTAIN -> ERADICATE -> RECOVER -> LESSONS
^ |
| v
+----- feeds detections & hardening ---------+
contain BEFORE eradicate | scope BEFORE eradicate | validate BEFORE closingTwo things govern the whole response. First, severity: a stealer on a kiosk and a domain-wide ransomware outbreak get very different urgency, escalation and resourcing — you classify severity early because it drives everything after. Second, command: one incident commander coordinates so containment, forensics and recovery do not trip over each other. Order plus command is what turns a crisis into a managed case.
Worked example — what is the first move?
FIN-WS-12: active attacker session, payload beaconing to C2 right now
proposed by teammate: 'wipe and re-image the host immediately to be safe'The answer: no. Wiping now is eradication-and-recovery jammed together, skipping two phases. You have not contained (the attacker is still active and may notice), you have not scoped (you do not yet know how many other hosts share this foothold), and you would destroy the memory and disk evidence that reveals what they did and where else they are. The correct first move is containment — isolate the host from the network to stop the spread while keeping it alive — then scope, then eradicate across everything you found, then recover. The teammate's instinct to act fast is right; the order is wrong.
Recap
- IR runs in ordered phases: identify, contain, eradicate, recover, lessons learned.
- The order is the discipline: contain before eradicate, scope before eradicate, validate before closing.
- Severity and a single incident commander govern the whole response.
Sign in to save your progress on the server.