The NIST SP 800-61 Incident Response Lifecycle

Preparation is the foundation phase. Everything done before an incident occurs belongs here: writing and approving the incident response policy and plan, forming the incident response team, assigning roles, training staff, deploying detection infrastructure, and building relationships with external parties such as law enforcement, legal counsel, and sector-specific information-sharing groups. NIST treats preparation as the most important phase because a poorly prepared team cannot execute the later phases effectively regardless of their individual skill.

The incident response plan defines what an incident is for the organisation, who has authority to declare one, what actions are authorised without additional approval, how incidents are classified by severity, and what external notifications are required. Regulatory requirements shape the last point significantly: the EU General Data Protection Regulation requires notification to supervisory authorities within 72 hours of becoming aware of a personal data breach; the Digital Personal Data Protection Act 2023 in India sets similar obligations; the US does not have a single federal breach notification law but sector-specific rules (HIPAA, SEC, FFIEC) impose their own timelines. The plan must map those obligations before an incident happens.

Preparation also includes assembling forensic toolkits and establishing forensic readiness, which means configuring systems to generate the logs and evidence that will be needed during detection and analysis. A team that discovers mid-incident that audit logging was disabled three months ago, or that log retention was set to three days, cannot recover that evidence. NIST recommends reviewing logging configurations, network flow capture, and endpoint telemetry as part of preparation rather than discovering gaps during a real event.

Detection and Analysis covers identifying that an incident may have occurred, characterising it, and confirming it is a genuine incident rather than a false positive. NIST distinguishes between precursors (signals that an incident may occur in the future, such as a vulnerability scan against your network) and indicators (signs that an incident is occurring or has occurred, such as a known-malicious IP making repeated connection attempts). Most organisations receive far more indicators than they can investigate manually, which is why automated SIEM correlation and tiered alert handling are standard practice.

Analysis has two goals: confirming whether a real incident is underway, and if so, characterising it well enough to make containment decisions. Characterisation includes identifying the attack vector (how the attacker gained access), the systems and data affected, whether the attacker has established persistence, and the likely objectives. This characterisation feeds directly into containment strategy: a ransomware deployment affecting ten servers calls for a different containment approach than an insider exfiltrating files to a personal cloud account.

NIST recommends maintaining an incident tracking system from the moment a potential incident is identified: log every observation, every action taken, every contact made, and every decision with timestamps. This log is both a coordination tool for the response team and a legal and regulatory record. Incident documentation is the foundation for breach notification filings, litigation holds, and post-incident reports.

Containment stops an incident from spreading. NIST divides containment into short-term and long-term strategies. Short-term containment takes immediate action to limit damage: isolating a compromised system, blocking a malicious IP at the firewall, disabling a compromised account. Long-term containment involves more stable measures that can hold while eradication is prepared: applying temporary patches, implementing additional monitoring, or moving systems to a clean backup while the primary is investigated.

Containment decisions involve tradeoffs. Immediate isolation of every affected system is the safest option for preventing spread but alerts the attacker, may destroy volatile evidence, and disrupts operations. Letting a monitored attacker remain while evidence is gathered preserves evidence and may reveal additional infrastructure, but risks further harm. The containment strategy must be decided deliberately, not by default, and documented with the reasoning at the time.

Evidence preservation during containment is part of the forensic readiness posture built in Preparation. NIST recommends acquiring forensic images of affected systems before any remediation changes the disk state, and capturing network traffic logs before affected segments are isolated. Legal hold obligations may apply if litigation is anticipated: in the US, Federal Rules of Civil Procedure impose preservation duties once litigation is reasonably anticipated, and similar rules exist under the UK Civil Procedure Rules and equivalent provisions in EU member-state procedural law.

Eradication removes the root cause from the environment. Common eradication activities include: deleting malware and its associated files and registry entries, closing or patching the vulnerability that was exploited, removing unauthorised user accounts and access tokens, resetting credentials for all accounts that may have been compromised, and confirming that no persistence mechanisms remain. Eradication that misses a persistence mechanism will result in re-infection after recovery, often within hours.

Recovery restores systems to normal operation. NIST recommends restoring from known-clean backups rather than attempting to clean a compromised system in place, because cleaning is error-prone. Before a restored system reconnects to the production network, it should be confirmed clean: verified against the known-clean baseline, patched to close the exploited vulnerability, and monitored closely for signs of re-infection during an initial reconnection period. Recovery is not complete when the system is back online; it is complete when the organisation has reasonable confidence the threat has been removed and the system is operating normally.

In large incidents affecting many systems, eradication and recovery are staged: the most critical systems are recovered first, with less critical ones following. The sequencing depends on business impact assessment, which is another output of the Preparation phase. Organisations that have not mapped their critical systems and their dependencies before an incident discover them the hard way when they must decide in real time which systems to restore first.

Post-Incident Activity is the phase most commonly skipped or compressed, and the one that most directly determines how much better the organisation handles the next incident. NIST recommends holding a lessons-learned meeting within approximately two weeks of incident resolution, while events are still clear in participants' memories. The meeting should include all members of the response team and, where relevant, representatives from affected business units, legal, communications, and management.

A well-run lessons-learned meeting produces specific, actionable outputs: detection rules that would have caught the incident earlier (or would have reduced the false-positive noise that slowed detection), updates to the incident response plan covering gaps that appeared during the response, revised playbooks for the incident type encountered, and a list of Preparation tasks. Those tasks go back into the Preparation phase, closing the lifecycle loop. NIST also recommends measuring response metrics across incidents over time: mean time to detect, mean time to contain, cost per incident, and recurrence rates for the same incident type.

The NIST lifecycle is explicitly cyclic. Post-Incident Activity feeds back into Preparation: every incident generates new intelligence about attacker techniques, new detection gaps, and new process weaknesses that become inputs to updated plans, rules, and training. This feedback loop is what makes an incident response programme improve over time rather than repeating the same failures. Organisations that skip Post-Incident Activity deprive themselves of their most valuable source of programme improvement.

Within the response itself, sequence matters because each phase creates conditions for the next. Attempting eradication before containment is complete means the attacker can re-establish footholds faster than they are removed. Attempting recovery before eradication is verified means restored systems become re-infected immediately. Attempting any of these before adequate analysis has characterised the incident means the team does not know what they are eradicating or where containment boundaries should be drawn. The order is not arbitrary protocol; it reflects the logical dependencies between phases.

Detection and Analysis does not end cleanly when containment begins: new indicators often emerge during containment that require going back to analysis to understand the full scope. Similarly, eradication may reveal additional compromised systems that require another containment decision before recovery can proceed. Real incidents are messier than the clean lifecycle diagram, and NIST acknowledges this: the phases represent logical groupings of activity, not strictly sequential steps that close before the next opens.