Incident Response Steps: The 6-Phase Process

A SOC analyst gets an EDR alert at 03:40: a finance workstation is beaconing to an IP nobody recognizes. What happens in the next ten minutes is decided entirely by whether the team has a plan. With one, the analyst pulls up the malware playbook, checks the severity matrix, isolates the host through the EDR console, snapshots memory, and pages the on-call lead, all from a runbook that already answered every question. Without one, the same analyst spends those ten minutes deciding whether this even counts as an incident, who to call, and whether unplugging the box will destroy something legal needs later. The attacker uses the gap.

The incident response steps are the ordered phases a team runs to take a security incident from first alert to closure: preparation, identification, containment, eradication, recovery, and lessons learned. They are not a checklist you tick once. Each step is a set of decisions with an owner, executed under pressure, and each one sets up the next. Skip preparation and identification stalls. Rush containment and you destroy the evidence eradication needs.

This guide walks all six steps in operational detail: what each one actually does, the order it runs in and why, the frameworks the steps come from (NIST SP 800-61 and SANS PICERL), and the incident response plan that makes the steps executable instead of improvised. It is written for the people who run them: SOC analysts, incident responders, and DFIR practitioners.

Where the incident response steps come from: NIST and SANS

The six steps are not arbitrary. They come from two frameworks that almost every IR program is built on, and the steps map cleanly between them.

NIST SP 800-61 is the standard most auditors and compliance frameworks reference. Its long-running four-phase lifecycle (from Revision 2) is: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. In April 2025, NIST published Revision 3, which retires the standalone four-phase diagram and instead maps incident response onto the six functions of the Cybersecurity Framework (CSF) 2.0: Govern, Identify, Protect, Detect, Respond, and Recover. Revision 2 was withdrawn when Revision 3 superseded it. The phase names changed; the underlying work did not.

The SANS model, known as PICERL, is the one operators reach for because it splits the work into the six discrete steps a real response actually has: preparation, identification, containment, eradication, recovery, and lessons learned. That granularity is the point. In a live incident, containment, eradication, and recovery are three separate decisions with three separate owners and three separate exit criteria, so splitting them out matches how the response is run.

This guide follows the SANS six-step sequence because it is the most practical operational spine. Map it to NIST for your audit and reporting, and you have one process that satisfies both. The two are the same lifecycle described at different resolutions, not competing methods. For the broader concept and the team behind it, see incident response.

Step 1: Preparation

Preparation is everything you do before an incident to make the other five steps possible, and it is the step that decides the outcome of all the rest. A response is only as fast as its preparation was thorough.

The work of this phase:

• Write the incident response plan and the per-scenario playbooks (covered in its own section below).
• Build and train the team. Name the incident commander, the analysts, the forensic responders, and the people outside security (legal, communications, executives) the plan will pull in.
• Define what an incident is and how severity is rated. A blocked phishing attempt and an active ransomware event are not the same incident, and nobody should be debating which it is at 03:40.
• Stand up and tune the tooling. SIEM for detection and correlation, EDR for endpoint visibility and isolation, SOAR for automating repetitive steps, and a case-management system for the timeline and evidence.
• Assemble the jump kit. Contact lists, break-glass credentials, forensic tools, and clean systems staged and ready, so the response does not start with a scavenger hunt.
• Rehearse with tabletop exercises. Run the plan against realistic scenarios so the first execution is not during a real breach.

Preparation is the only step that happens when the clock is not running, which is exactly why teams under-invest in it and pay for it during every incident after.

Step 2: Identification

Identification, sometimes called detection and analysis, is where you decide an event is actually an incident, then scope and classify it. Most of what a SOC sees is noise: a login, a connection, a single alert. An incident is an event, or a chain of them, that genuinely threatens the confidentiality, integrity, or availability of systems or data.

The work of this step:

• Triage the alert. Confirm it is real and not a false positive, the failure mode that buries real incidents under noise.
• Corroborate from multiple sources. Pull logs, endpoint telemetry, and network data to confirm what actually happened. Log analysis across the SIEM is usually where the picture comes together.
• Scope it. Which hosts, accounts, and data are involved? The first compromised host is rarely the only one.
• Classify severity and declare. Assign a severity from the matrix, declare the incident, and assign an owner. The output of this step is a declared incident with a severity and an incident commander.

Documentation starts here, at the first minute. A clean timeline begun during identification saves hours during eradication and the post-incident review. The most common failure of this step is not missing the alert; it is seeing it and failing to recognize its scope, so the response is sized to one host while the attacker is already on five.

Step 3: Containment

Containment is stopping the spread without destroying the evidence you will need later. It is the step where speed and forensic discipline pull against each other, and getting the balance right is what separates a controlled response from a clumsy one.

Containment runs in two stages:

• Short-term containment stops the bleeding immediately: isolate the affected host through the EDR console, disable the compromised account, block the malicious IP or domain at the firewall. The goal is to halt the attacker's progress in minutes, not to fix the root cause yet.
• Long-term containment applies more durable holds while the investigation continues: rebuild a clean system to take over the workload, apply a temporary patch, or tighten segmentation so the contained threat cannot reach further even if short-term controls slip.

The rule that governs this step: preserve forensic evidence before you change anything that destroys it. Capture a memory image before you reboot or reimage, snapshot disks before you wipe, and export the relevant logs before retention or the attacker rolls them off. Eradication and recovery both destroy state. If you have not preserved it by the end of containment, it is gone. This is also where the legal and regulatory clock matters: pulling a host the wrong way can compromise evidence a later investigation or notification depends on.

Step 4: Eradication

Eradication removes the threat from the environment completely. Containment stopped the attacker from spreading; eradication makes sure there is nothing left to spread.

The work of this step:

• Remove the malware and attacker tooling from every affected system, not just the one that alerted.
• Close the initial access vector. Patch the exploited vulnerability, fix the misconfiguration, or disable the abused service that let the attacker in.
• Remove persistence. Attackers plant durable footholds, new accounts, scheduled tasks, registry run keys, web shells, modified services, so they survive a reboot or a credential reset. Eradication that misses persistence leaves a door open.
• Reset compromised credentials for every account the attacker touched or could have touched, including service accounts and any credentials cached on compromised hosts.

The trap in eradication is treating the symptom and missing the root cause. If the attacker got in through an unpatched external service and you remove only the malware, they walk back in through the same door within days. Eradication is judged not by what you deleted but by whether the attacker can return through the same path. Scope discipline matters as much as it did in identification: eradicating one host while a second compromised box sits quietly is how incidents reopen.

Step 5: Recovery

Recovery brings systems back to normal operations, safely and on evidence rather than impatience. The decision at the center of this step is a confidence call: you reconnect a system when you can prove it is clean, not when leadership wants it back.

The work of this step:

• Restore from known-clean backups, validated against the timeline so you are not restoring a backup taken after the initial compromise.
• Validate before reconnecting. Confirm the system is fully cleaned and the access vector is closed before it rejoins production.
• Reconnect in a controlled sequence, prioritizing the most critical systems, rather than bringing everything back at once.
• Monitor closely for re-infection. Attackers frequently return to test whether they were fully evicted. Heightened monitoring on recovered systems, watching for the same indicators and any sign of lateral movement, is part of recovery, not a separate task.

Recovery is not finished when systems are back online. It is finished when you have confirmed, with monitoring, that the threat did not come back with them. Bringing systems back too early, before eradication is verified, is one of the most common ways an incident reopens days after it was declared closed.

Step 6: Lessons learned

Lessons learned, or post-incident activity, is the step teams skip and the one that compounds. It is where a single incident becomes a permanent improvement to detection, the plan, and the team's readiness for the next one.

Run a structured post-incident review within a week or two of closing the incident, while memory is fresh:

• Reconstruct the full timeline: what happened, when it was detected, and how the response unfolded.
• Find what slowed the response. A missing log source, an unclear escalation path, a playbook gap, a tool nobody had drilled with.
• Assign owned, dated action items. A review that produces no concrete changes is theater.
• Feed the findings back into detection rules, the incident response plan, and the next tabletop.

Keep the review blameless. The goal is a better process, not a culprit, and a blame-driven review just teaches people to hide what went wrong. An incident you do not learn from is one you have agreed to suffer again, at full cost.

The incident response plan that drives the steps

The steps are the verbs; the incident response plan (IRP) is the document that tells the team how to run them under pressure. A good plan removes decisions from the worst possible moment to make them. It is built during preparation and executed across the other five steps. The components that matter:

• Roles and authority. Who declares an incident, who leads it, who can take systems offline, and who speaks for the organization. Decided in advance, in writing.
• Severity classification. An agreed scale so the response matches the threat and the right people are pulled in at the right level.

• Playbooks. Step-by-step runbooks for the incident types you actually face: ransomware, business email compromise, data exfiltration, account takeover. Generic plans stall; specific playbooks move, because they pre-answer the per-scenario questions the six steps raise.
• Communication plan. Internal escalation paths and external notification: when and how to inform regulators, customers, law enforcement, and the public. Breach-notification clocks start whether or not the team is ready.
• Contact list and tooling. Who to call at 03:40, and where the tools, credentials, and clean systems live.

Most vendor write-ups gloss over two of these: severity classification and external or regulatory communication. Both are where unprepared responses fall apart, and both belong in the plan before the first alert, not in a meeting during the incident.

The incident response steps at a glance

The order is not optional. Each step depends on the one before it: you cannot contain what you have not scoped, cannot eradicate what you have not contained, cannot recover what you have not eradicated, and cannot improve what you do not review. Preparation wraps around all of it, and lessons learned feeds back into the next preparation. The steps are a loop, not a line.

Frequently Asked Questions

What are the 6 steps of incident response?

The six incident response steps, from the SANS PICERL model, are preparation, identification, containment, eradication, recovery, and lessons learned. They run in order: prepare before an incident, identify and scope it when it occurs, contain the spread, eradicate the threat, recover systems to normal, and review the incident to improve. NIST SP 800-61 groups the same work into fewer phases but covers the identical lifecycle.

What is the difference between the NIST and SANS incident response steps?

SANS PICERL splits the response into six discrete steps, while NIST SP 800-61 (Rev 2) grouped them into four phases, combining containment, eradication, and recovery into one. NIST's 2025 Revision 3 reframes incident response around the Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). All describe the same lifecycle; SANS is more granular for operational runbooks, NIST is the common reference for compliance.

Which incident response step is the most important?

Preparation. It is the only step that happens before the clock is running, and the speed and quality of the other five steps depend on it. A team that wrote the plan, defined severity, tuned the tooling, staged a jump kit, and rehearsed with tabletops runs a controlled response; a team that skipped preparation improvises every decision under pressure and loses the most valuable hours of the incident.

Why must you preserve evidence before eradication?

Because eradication and recovery destroy the state an investigation needs. Reimaging a host, wiping malware, or restoring from backup overwrites the memory, disk artifacts, and logs that show how the attacker got in and what they did. Capturing memory images, disk snapshots, and logs during containment, before you change anything, preserves the evidence for root-cause analysis, legal action, and regulatory reporting. Once it is gone, it cannot be recovered.

How long does the incident response process take?

It varies widely by incident, from hours for a contained single-host malware case to weeks or months for a major breach. Containment can happen in minutes with good tooling and a clear plan, while eradication, recovery, and the post-incident review extend over days or longer. Industry data consistently shows that faster detection and containment directly reduce the cost of a breach, which is why preparation, the step that buys that speed, matters most.

What is an incident response plan?

An incident response plan is the document a team executes during a security incident. It defines roles and authority, a severity classification scale, step-by-step playbooks for common incident types, and a communication plan covering internal escalation and external notification to regulators and customers. Built during the preparation step, it drives the other five steps by making the key decisions in advance instead of under pressure.

The bottom line

The incident response steps are a six-phase loop: prepare, identify, contain, eradicate, recover, and learn. The order is load-bearing, because each step depends on the one before it and feeds the one after. Containment that destroys evidence sabotages eradication; eradication that misses the root cause sabotages recovery; recovery without monitoring invites the attacker back; and skipping lessons learned guarantees you run the whole loop again at full cost.

The steps are only as good as the plan and the preparation behind them. A team that wrote the plan, defined severity, staged the tooling, and rehearsed the scenario runs these six steps as a controlled process. A team that did not runs them as a panic. The difference is decided long before the alert fires at 03:40.