Incident Response Lifecycle

The incident response lifecycle is an organized, repeatable way to handle security incidents. It covers detecting an event, analyzing it, containing and removing the threat, and finally recovering systems and learning from what happened. Two models describe it most often. The first is the four-phase model from NIST SP 800-61: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. The second is the six-step SANS model, known as PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned). The lifecycle is a loop, not a line: lessons from each incident feed back into preparation.

What are the phases of the incident response lifecycle?

The models differ in step count, but they describe the same path: from readiness, through detection, to recovery and learning. Below are the phases in NIST terms. We note where SANS splits them more finely.

1. Preparation — everything you do before an incident happens. You stand up a response team (a CSIRT or CERT — the group that handles incidents). You write a plan and policies, and for common scenarios (phishing, ransomware, account compromise) you prepare playbooks, that is ready-made step-by-step procedures. You also deploy data collection (logs, EDR, SIEM, NDR), set up escalation paths and contacts, run table-top exercises, and create and test backups.
2. Detection & Analysis — called Identification in SANS. Here you recognize the signs of an attack: IDS/IPS alerts, SIEM correlation rules, unusual behavior, and indicators of compromise (IoC, traces that point to an attack). You then sort alerts by importance (triage), establish scope and impact, set priority, and notify the right people. This is where MTTD (mean time to detect) is measured.
3. Containment, Eradication & Recovery — NIST groups these three because they overlap in practice. SANS treats them as three separate steps. Containment cuts off the threat: isolating infected machines, blocking accounts and addresses, segmenting the network. Eradication removes the cause: malware, attacker accounts, vulnerabilities and persistence mechanisms (the ways an attacker keeps access). Recovery returns to normal work: restoring systems from trusted backups, checking their integrity, and applying heightened monitoring. This is where MTTR (mean time to respond/recover) is measured.
4. Post-Incident Activity — Lessons Learned in SANS. After it is over, the team meets for a review (post-mortem), rebuilds the timeline of events, assesses how well detection and response worked, updates playbooks, detection rules and controls, and prepares the reporting and documentation needed for compliance.

How does the NIST model differ from the SANS model?

Both describe the same process, but they group it differently and are written for different readers.

• Step count: NIST — 4 phases; SANS — 6 steps (PICERL).
• The middle of the cycle: NIST merges containment, eradication and recovery into one phase. It assumes these activities overlap and that you should not wait for full containment before starting eradication. SANS keeps them separate to give more detail in practice.
• Terminology: SANS says Identification; NIST says Detection & Analysis.
• Who it is for: SANS (PICERL) is practical and operational, written for SOC analysts. NIST historically emphasized policy and compliance (including U.S. federal agencies).

What did NIST SP 800-61 Rev. 3 change?

Revision 3 (2025) moved away from the rigid four-phase diagram. Instead, it ties incident response to the six functions of the NIST Cybersecurity Framework 2.0 (CSF 2.0): GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER. The point is to stop treating response as an island and make it part of the whole security program. Readiness (Govern/Identify/Protect) and event handling (Detect/Respond/Recover) operate in a continuous-improvement loop. The four classic phases are still valid and widely used; Rev. 3 changes the way things are organized more than the activities themselves.

What is the role of SOC, SIEM, SOAR and NDR in the lifecycle?

The lifecycle is a process, and technology supplies the data and automation that shorten the time spent in each phase.

• SOC (Security Operations Center) — the team and processes responsible for monitoring, triage and running the response.
• SIEM — collects logs and events in one place, links them together, raises alerts (detection phase) and serves as an evidence source during analysis.
• NDR (Network Detection & Response) — analyzes network traffic and flow metadata (e.g. NetFlow/IPFIX). It detects lateral movement (an attacker spreading across the network), data exfiltration and communication with attacker servers (C2) that host logs miss. It provides the network context needed to set scope.
• SOAR (Security Orchestration, Automation and Response) — runs playbooks that automate repetitive steps (adding context to an alert, isolating a machine, blocking IoC). It reduces MTTR and offloads analysts.
• EDR/XDR — visibility and actions on the machines themselves (isolation, collecting traces, removing malware) during containment and eradication.

What are incident response playbooks?

A playbook is a ready-made, written, step-by-step procedure for handling a specific incident type (e.g. ransomware, phishing, privileged-account compromise). It says when to trigger it, who is responsible for what and which decisions to make, in what order to contain and remove the threat, and when to consider the case closed. Playbooks make the response more predictable under time pressure, and they are the basis for SOAR automation. They are created during preparation and updated after each incident in post-incident activity.

How is response effectiveness measured (MTTD and MTTR)?

The most common metrics are MTTD (Mean Time to Detect, the average time from a threat appearing to it being detected) and MTTR (Mean Time to Respond or Recover, the average time to react or restore). Lower values mean shorter dwell time, the window during which an attacker operates undetected. More mature teams also track time from detection to containment, the share of incidents handled per playbook, and total incident cost. These figures are gathered in the post-incident phase and used to decide what to improve first.

Why is the incident response lifecycle important for security?

An organized process limits chaos during a real attack. It shortens dwell time, reduces the spread of damage, preserves evidence (chain of custody) and keeps communication consistent, while the learning loop steadily improves detection and controls. Without a repeatable cycle, response is ad hoc, hard to compare across events, and hard to demonstrate in compliance audits (e.g. NIS2, ISO/IEC 27035, DORA).

Learn more

• Inventory — Asset inventory helps scope impacted systems during incident response.
• Intrusion Detecting System — Intrusion detection systems provide alerts that trigger incident response actions.
• Network Forensics — Network forensics supports evidence collection and investigation in incident response.
• NOC (Network Operations Center) — The NOC often detects, escalates, and helps coordinate incident response.
• Root Cause Analysis (RCA) — RCA identifies why the incident happened and supports post-incident improvement.
• Cyber Kill Chain — The cyber kill chain helps map attacker activity across incident response stages.