About this interactive
The incident response lifecycle is usually met as a list of seven words in a row — preparation, detection, analysis, containment, eradication, recovery, lessons learned — and a student who can recite that list still cannot say what has to be true before any one of those phases can begin, or what each of them actually changes. Closing that gap is what this set is for, and it is why no card opens with its phase name. Each card describes the work and ends with what that phase changes, so the vocabulary is attached to the behaviour rather than standing in for it. The chronology here is causal rather than conventional, and three constraints do most of the work. The first is that nothing used during an incident can be invented during it. The plan, the named response team, the authority to disconnect a production system without asking permission, the centralised logging that means the evidence exists before anyone needs it, the measured baseline that lets abnormal be recognised at all, the backups that were actually restored in a test rather than merely taken — all of it has to already exist at the moment the alert fires. That is why preparation sits outside the incident entirely, and it is also why it is the phase most often skipped: it is the only one with no incident to justify it. A team that begins writing its plan after the alert is not responding, it is improvising. The second constraint is that you cannot act on what you have not yet understood, and it is the reason detection and analysis are separate cards rather than the single NIST phase they are grouped under. Detection ends at a declaration: this is a real incident and not one of the many false positives that make up most of a queue, so the plan formally starts and the clock starts with it. Analysis is the entirely different job of establishing scope, reconstructing the timeline backwards to the initial point of entry — very often much earlier than the moment of detection — estimating severity so the response is proportionate, and collecting evidence under chain of custody. Collapsing the two is the most expensive mistake in the lifecycle, because a team that acts on the alert alone contains the one host it noticed while three others stay under the attacker's control, and finds out only when the attacker uses them. The third constraint is that the bleeding is stopped before the wound is cleaned. Containment is urgent, reversible and deliberately evidence-preserving: isolate, disable, block, quarantine, segment, and leave the attacker's tooling in place for the analysis that is still running. Eradication is slow and thorough: delete the malware, hunt the persistence mechanisms — the scheduled tasks, the service accounts, the web shells left behind so the attacker can walk back in — rotate the credentials, patch the vulnerability that allowed entry, and rebuild from a known-good image wherever cleaning cannot be proven complete. Run them the other way round and you are removing an attacker's tooling from a system the attacker still reaches, which invites them to put it back. Recovery is where the set makes its one point about who decides: restoring from validated backups, checked against the timeline so that a backup taken after the initial compromise does not reintroduce it, and then a defined watch period, because the commonest failure mode is a cause that was not fully eradicated announcing itself a week later. The incident closes when normal operations are confirmed by the business, not when the technical work stops. The last card is the one students most reliably treat as optional, and the set is built so that it cannot be. Lessons learned produces artifacts rather than feelings — an after-action report, a corrective action plan with owners and dates, updated playbooks, new detection rules for the indicators this incident produced — and every one of those flows straight back into preparation, which is what makes this a loop rather than a line. It also blames the system rather than the people, because a team that expects to be punished for the findings stops reporting incidents and the organisation loses the only signal it had. Seven phases are shipped rather than the four NIST SP 800-61 groups them into, and that is deliberate: the seven-step expansion is what pspo-14's own lessons teach across Preparation (pspo-14-0050), Detecting, Declaring, and Escalating (0080), Containment, Eradication, and Recovery (0090) and Incident Follow-Up (0120), it is what Security+ objective 4.8 enumerates word for word, and it is how the security ladder's own incident-response-lifecycle term is defined. Collapsing it back to four would contradict all three. All seven cards are presented on every run rather than sampled: this is the naturally finite domain the pool guideline makes an exception for — a lifecycle with a phase removed is not a shorter version of the same object, it is a broken chain, and the chain is the entire skill being assessed. This pairs best with the module's own sequence — run it after IR Process (pspo-14-0040) and alongside Containment, Eradication, and Recovery (0090), so that the phases the cards separate are ones the student has already seen taught together.