The Incident Response Lifecycle, From Alert to Lessons Learned
Incidents are won or lost in the first hour, and the first hour is a terrible time to start figuring out your process. The organisations that come through a breach with their reputation and data intact are rarely the ones with the fanciest tooling — they are the ones who rehearsed the lifecycle, assigned the roles, and made the hard decisions in the calm before, so that under pressure they are executing a plan rather than improvising one.
The widely-used lifecycle — reflected in the NIST and SANS models — breaks response into phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. The names matter less than the discipline they encode: know what you have before it happens, understand what you're seeing, stop the bleeding, remove the attacker cleanly, and — the phase everyone skips — actually learn from it.
Containment is a judgement call, not a reflex
The instinct to immediately pull the plug can be exactly wrong. Isolate a compromised host too soon and you tip off an attacker who then burns their access, deploys ransomware, or destroys evidence. Wait too long and they spread. Good containment is deliberate: understand the scope first, decide whether to observe or cut, and have pre-authorised actions — network isolation, credential resets, key revocation — ready so you are choosing when, not scrambling for how.
The phase everyone skips
Post-incident review is where the return on a bad day is actually collected, and it is the first thing cut when everyone is exhausted and relieved. Skipping it means paying the full cost of an incident and banking none of the learning — the same gap that let the attacker in stays open for the next one. A blameless review that produces concrete, owned actions is what turns an incident from a loss into an investment in not repeating it.
- Assign roles before the incident. Incident commander, communications, technical lead, scribe — decided in advance. Arguing about who is in charge while data exfiltrates is a preventable failure.
- Rehearse with tabletop exercises. Walking through a realistic scenario in a conference room surfaces the broken assumptions — the runbook that references a person who left, the access nobody actually has — cheaply.
- Keep clean, tested backups and know your recovery time. ‘We have backups’ and ‘we have restored from backups recently’ are very different statements, and ransomware finds out which one is true.
- Prepare communications in advance. Regulators, customers, and executives will need to be told. Templates and a decision tree written calmly beat legally-fraught prose written in a panic.
- Ask who your incident commander is and where the current runbook lives. If people hesitate or point to a document nobody has opened this year, your preparation phase is theoretical.
- Pick a plausible scenario — ransomware on a file server — and walk three people through the first hour verbally. The gaps that surface in ten minutes are the ones that would cost you hours during the real thing.
Pressure-testing your response through realistic scenarios, and finding the broken assumptions before an attacker does, is what our assessment and tabletop exercises are built to surface — while it’s still a drill.
An incident response plan is not a document; it is a muscle, and muscles that are never exercised are useless when the weight lands. The teams that stay calm during a breach are calm because they have been here before — in rehearsal, on purpose, with no real attacker watching. Build that readiness in the quiet, because you cannot respond well to an incident you were never prepared for, in an environment you never fully mapped.