The NIST incident response lifecycle — Preparation, Detection and Analysis, Containment, Eradication and Recovery, Post-Incident Activity — is the framework nearly every mature response function uses, in one form or another. Its value is not the phase names, but the discipline of moving explicitly between them: knowing which phase you are in, and what decisions belong to it.
The phases, and what actually happens in each
- 01Preparation. Named roles across legal, communications, IT and executive leadership. Tested runbooks for the three or four scenarios most likely to hit the organisation (ransomware, business email compromise, cloud tenant takeover, insider exfiltration). Pre-agreed retainers with external counsel, a forensic responder and a PR firm — negotiated at the leisurely pace of a procurement cycle, not the panic of a live incident.
- 02Detection and analysis. Confirming what is actually happening, distinguishing a genuine incident from a noisy alert, and scoping impact against the crown-jewel inventory. Nothing further should move until this step has produced a written incident declaration with a named incident commander.
- 03Containment. Cutting off the intruder's access without destroying the evidence the organisation will need later. This is the phase where preservation and remediation genuinely conflict, and where the response either sets itself up for a defensible investigation or forecloses one.
- 04Eradication and recovery. Removing the cause — not just the symptom — and restoring service in a known-clean state, with the monitoring in place to detect return. Rebuilds should be from verified images, not from the most recent backup taken before the intrusion was detected.
- 05Post-incident activity. A written record of what happened, what worked, what did not, and — crucially — what the organisation has changed as a result. An incident that does not produce concrete changes was not properly reviewed.
The retained team, before the incident
| Role | Retained with | Called at |
|---|---|---|
| Incident commander | Internal, named in advance | T+0 |
| External counsel | Retainer with a firm familiar with UK GDPR and cyber-insurance work | T+0 (before the forensic examiner) |
| Forensic examiner | Retained through counsel for privilege | T+1 hour |
| Cyber insurer | Policy in place with clear notification route | T+2 hours |
| Communications/PR | Retained firm briefed on the organisation | Only when notification is imminent |
The decisions that determine the outcome
- Do we rebuild now or preserve first? Almost always preserve first — see the cyber-forensics piece for why.
- Do we notify the ICO now, or in phases? A phased notification under Article 33 is explicitly permitted; a late single notification is not.
- Do we pay a ransom? A legal decision, not a technical one, engaging sanctions law and insurance-cover conditions. Never made by the IT team alone.
- Do we tell customers now? The answer flows from Article 34's high-risk test and any contractual notification clauses, not from communications instinct.
- Do we call in law enforcement? Action Fraud for the record; the NCA for material or ongoing intrusions; the ICO separately for the data-protection notification.
Every response we have seen go badly was structurally the same problem: nobody was clearly in charge, and everybody was quietly waiting for someone else to make the decision.
Where forensics fits into the response
Forensic evidence work runs in parallel with containment, not after it. The examiner takes memory captures, disk images and log exports before rebuilds begin, so the organisation can answer regulators, insurers and any claimants with confidence about what was affected and what was not. Where the examiner is instructed through counsel, the resulting report is protected by legal professional privilege and can be relied upon in later civil claims without becoming disclosable to the opposing party.
The commonest failure patterns
- No named incident commander — everybody is contributing, nobody is deciding.
- IT rebuilds before evidence is preserved, and the investigation is compromised from hour one.
- The insurer is notified too late, or the wrong panel firm is instructed, and cover is prejudiced.
- External counsel is instructed after the ICO notification is drafted, not before.
- The post-incident review is a slide deck for the board and nothing operational actually changes.
Frequently asked questions
Within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to data subjects. Notification can and often should be phased if the full scope is not yet known.
It is legal in the UK provided the recipient is not a sanctioned entity, but it is rarely wise. Payment does not guarantee decryption or non-publication, and it materially increases the likelihood of a repeat attack. It is a legal, financial and reputational decision — not a technical one.
An internal incident commander with authority to direct across IT, legal, communications and finance. Not the CIO by default, and not an external consultant — the buck must stop with someone who can commit the organisation.
Disaster recovery restores service after any disruption; incident response handles a hostile event where an adversary is or was present. The two overlap but the decision frameworks are different — DR is about time to restore, IR is about evidence, notification and containment.
For minor incidents on systems they manage, sometimes. For anything with regulatory, insurance or litigation exposure, the response should be led independently — the MSP's own configuration and access are part of what needs to be examined.