What Are the Stages of Incident Response?

Key Takeaways

• The classic six-stage incident response lifecycle gives security teams a repeatable framework for detecting and recovering from cyberattacks.
• Incident response and incident management are not the same thing: incident response targets security threats specifically, while incident management covers any IT service disruption.
• The four-phase NIST model and seven-step variants aren’t wrong, they just group or expand the same core activities differently, which is why your team should understand the reasoning behind each model.
• NIST SP 800-61 Rev 3 and CSF 2.0 reflect a meaningful shift toward continuous improvement and supply chain risk.
• The most damaging mistakes organizations make after a breach are procedural, not technical: skipping lessons learned, failing to document evidence and neglecting to update the plan.
• Matching your incident response technology stack to the right stages, from SIEM at detection to SOAR at containment, dramatically reduces dwell time and recovery costs.

Why Incident Response Stages Still Confuse Security Leaders

Search for ‘stages of incident response’ and you’ll find conflicting answers immediately. Some sources say four stages, others say six and a few say seven. For CIOs and CTOs trying to build or audit a response program, the disagreement creates real confusion about where your organization’s gaps might be.

The good news is that the frameworks aren’t really in conflict. They’re covering the same ground with different levels of granularity. This article walks you through the classic six-stage model, explains what changed in 2024 and 2025 with the latest NIST guidance and gives you the context to evaluate what framework fits your organization’s maturity and compliance obligations.

Before diving into the stages themselves, it’s worth grounding a few terms that often get conflated in vendor materials and even internal conversations.

Incident Response vs. Incident Management: What’s the Difference?

These terms are used interchangeably far too often, and that sloppiness can produce real gaps in organizational responsibility.

A ransomware attack is a security incident. A server crash caused by a failed software update is an IT incident, not a security incident, unless there’s evidence of exploitation. The distinction matters because your response team and documentation requirements differ depending on which category you’re in.

Data breaches deserve special attention because they trigger regulatory timelines. Under the General Data Protection Regulation (GDPR), for example, certain breaches must be reported within 72 hours. Under the Health Insurance Portability and Accountability Act (HIPAA), the window is 60 days. Your incident response plan needs to explicitly identify when an incident escalates to a breach and what that escalation triggers.

Why the Stages of Incident Response Matter Now More Than Ever

Cyberattacks are not getting easier to weather. IBM’s Cost of a Data Breach Report 2025 found that the global average cost of a data breach reached $4.44 million, the highest figure on record. The mean time to identify and contain a breach was 241 days. Organizations with incident response teams and tested plans saved an average of $2.66 million compared to those without, according to the same report.

For defense contractors and critical infrastructure operators, the stakes are even higher. A compromised environment can do more than produce financial losses. It can also disrupt mission-critical operations or expose controlled unclassified information (CUI) triggering Cybersecurity Maturity Model Certification (CMMC) or Defense Federal Acquisition Regulation Supplement (DFARS) reporting obligations.

Having a documented, practiced incident response framework isn’t optional at this level. It’s a contractual and regulatory requirement.

The Six Stages of Incident Response: The Core Lifecycle

The stages of incident response exist precisely because improvised responses fail. When a threat actor is inside your network, every minute of uncoordinated activity extends dwell time that increases the damage. A structured framework ensures your team knows exactly who does what and in what order from the moment an alert fires to the moment you’re documenting the lessons you learned.

The SANS Institute formalized the six-stage model that remains the most widely adopted in enterprise security programs. Here’s how each stage works in practice.

Stage 1: Preparation

Preparation is everything you do before a cybersecurity incident happens. It’s the stage most organizations underinvest in and the one most responsible for how badly a breach plays out.

Preparation includes:

• Developing and testing your incident response plan
• Defining team roles and escalation paths
• Deploying the right tooling
• Establishing communication protocols with legal and executive leadership
• Running tabletop exercises that simulate real attack scenarios.

You can’t contain what you can’t map and most organizations neglect their asset inventory until it’s too late. Before an attack hits, your team needs a clear picture of what it’s defending. Red River’s work in identity and access management directly supports this preparation layer by ensuring that access to critical assets is documented and governed before a threat actor finds the gaps.

Stage 2: Identification

Identification is the detection and confirmation of a security incident. It sounds simple, but it’s often the stage where valuable time is lost. Alert fatigue is real. Security operations centers (SOCs) can receive thousands of alerts daily and distinguishing a true positive from a false positive requires both good tooling and experienced analysts.

The goal of this stage is to validate that the incident occurred, determine its scope, identify the affected assets and document the initial indicators of compromise (IoCs). Documentation becomes critical in every subsequent stage.

A key output of identification is a confirmed incident declaration, not just a ticket in the queue. That declaration kicks off the formal response process, assigns ownership and triggers any required notification timelines.

Stage 3: Containment

Containment stops the bleeding. The immediate goal is to prevent the threat from spreading further while preserving forensic evidence for later analysis.

Containment typically happens in two phases. Short-term containment might involve isolating an affected system from the network or disabling a compromised account. Long-term containment sets up a more stable defensive posture, often including patched or hardened systems that allow business functions to continue while eradication work proceeds.

The tension in containment is between speed and evidence preservation. Moving too fast, for example wiping a system before capturing a forensic image, destroys what you’ll need for root cause analysis and any legal proceedings. Your playbooks should explicitly address this tension.

Stage 4: Eradication

Eradication removes the root cause. Once you’ve contained the threat, the team works to close the vulnerability by removing the attacker’s persistence mechanisms and confirming that no additional footholds remain.

This stage requires a clean understanding of what happened. If your identification and containment stages were sloppy, you risk missing a secondary backdoor or an additional compromised credential. IBM found that 83% of organizations experienced more than one breach in a 12-month period. Eradication without thorough forensic analysis is the reason many organizations experience repeat incidents from the same threat actor.

Eradication also includes reviewing related systems for lateral movement. If a phishing email compromised one account, the question isn’t just how to remove that access. It’s whether that account was used to escalate privileges or exfiltrate data before the detection occurred.

Stage 5: Recovery

Recovery restores safe operations. However, it’s not enough to rebuild systems and flip them back online. Before anything returns to production, the team needs to verify that systems are clean and monitoring is in place to catch any recurrence.

Recovery timelines vary significantly by incident type. It can take weeks or months to recover from a ransomware attack on core infrastructure. A contained phishing incident affecting a single endpoint might resolve in hours. Either way, the recovery stage should include formal verification steps, not just a verbal confirmation that things look fine.

It’s also the stage where communication becomes especially important. Customers and regulators have legitimate need to know requirements and those updates should flow through pre-established channels, not improvised Slack messages or hallway conversations.

Stage 6: Lessons Learned

Lessons learned is the stage most organizations skip or rush and it’s the one that determines whether the same incident happens again. A structured post-incident review, sometimes called a post-mortem or after-action report, documents what happened, what worked, what didn’t and what changes you need.

This stage should be very concrete and explicit. Instead of, ‘we should improve detection,’ it should read, ‘by Q3, the SOC team will tune the SIEM ruleset to reduce false positives in the category identified during this incident, owned by the security operations manager.’

Accountability turns lessons into improvements.

For organizations subject to CMMC, NIST 800-171 or similar frameworks, documenting the lessons learned also serves as evidence of a functioning incident response program.

Why Do Some Sources Mention 4, 6 or 7 Stages?

The variation Incident Response best practices come from how the steps are grouped. The older NIST SP 800-61 Rev 2 framework, which was the standard from 2012 through 2024, used four phases by folding containment, eradication and recovery into a single phase. That made the model more compact but less operationally specific.

Seven-step variants typically add an ongoing improvement cycle as a separate stage, pulling what would otherwise be embedded in lessons learned into its own standing function. That approach is best for a more mature, continuous security program.

None of these models is wrong. The choice of which to adopt should be driven by your organization’s size, maturity and the level of operational specificity your team needs during a live incident. For most enterprise environments, the six-stage model provides the right balance of clarity and completeness.

What Changed in 2025? NIST SP 800-61 Rev 3 and CSF 2.0

NIST released the final version of SP 800-61 Rev 3 in April 2025, retiring the four-phase model that had been in place since 2012. The updated guidance reflects how incident response has evolved in an era of cloud-first infrastructure, supply chain attacks and AI-assisted threats.

The most significant shifts in Rev 3 include a stronger emphasis on supply chain risk, clearer guidance on sharing threat intelligence with trusted partners and an integrated view of incident response as a continuous function rather than a linear process that ends at lessons learned.

NIST CSF 2.0, also released in 2024, expanded the original five framework functions by adding ‘Govern’ as a sixth function. The Govern function places executive accountability and organizational risk management at the center of cybersecurity strategy, not as an afterthought. For IT leaders, that shift means incident response planning now needs visible executive sponsorship and board-level reporting structures, not just a document in the security team’s shared drive. You can access the full framework directly from NIST’s official CSF 2.0 page.

Stages vs. Incident Response Plan: What’s the Relationship?

The stages describe what happens during an incident. The incident response plan describes how your specific organization executes each stage. Think of the stages as the framework and the plan as the playbook.

A mature incident response plan includes:

• Defined roles and responsibilities for each stage
• Escalation criteria
• Communication templates
• Legal and regulatory notification checklists
• Asset inventories
• Evidence handling procedures
• Contact lists for external partners including legal counsel, law enforcement liaisons and breach notification vendors

For organizations operating under CMMC Level 2 or 3, DFARS 252.204-7012 requires contractors to report cyber incidents affecting covered defense information (CDI) within 72 hours of discovery. Your incident response plan needs to explicitly address this requirement and assign ownership of the notification process. Red River’s cybersecurity compliance resources can help you evaluate where your current plan stands against those obligations.

What Types of Security Incidents Do These Stages Apply To?

The six-stage lifecycle isn’t specific to one attack type. It applies across the full range of security incidents your organization might face.

The application of each stage varies by the type of breach you experience. A DDoS attack compresses containment and recovery into rapid, often automated responses. An APT investigation can stretch identification and eradication across months of forensic analysis. Your playbooks should account for these differences with incident-specific procedures layered on top of the core framework.

What Are the Biggest Mistakes Organizations Make After an Attack?

The post-incident period is where organizational discipline is tested most severely and where the biggest errors tend to occur.

• Skipping lessons learned entirely because the team is exhausted or leadership considers the incident closed.
• Restoring systems from backups without verifying the backups themselves are clean and uncompromised.
• Failing to preserve forensic evidence before reimaging systems, which eliminates the ability to conduct root cause analysis or support legal proceedings.
• Not updating the incident response plan based on what was discovered during the event.
• Communicating inconsistently across legal, regulatory, executive, public and customer-facing channels, creating conflicting narratives that complicate reporting and tarnish your image further.
• Treating the incident as fully resolved before confirming there are no remaining attacker footholds.

The organizations that recover most quickly from these incidents treat lessons learned as a formal process. They assign action items and deadlines, tracking completion the same way they’d manage any other security project.

What Technology Supports Each Stage of Incident Response?

No tool covers the entire lifecycle on its own. A mature incident response technology stack matches specific capabilities to the stages where they deliver the most value.

Extended detection and response (XDR) platforms consolidate previously fragmented tools across SIEM, endpoint detection and response (EDR) and network detection. For organizations evaluating whether to consolidate or integrate, the key question is whether your current stack gives analysts a unified view during an active incident or forces them to pivot across multiple consoles under pressure.

Security orchestration, automation and response (SOAR) tools are especially valuable at containment and eradication, where speed matters most and you can automate repetitive actions like account disablement and IP blocking. The ROI on SOAR is most visible in organizations that have well-defined playbooks but lack the analyst headcount to quickly execute them manually.

Red River Can Help You Build a Response Program That Holds Up

Building a repeatable, defensible incident response capability isn’t a one-off. Cybersecurity incident response is an ongoing program that requires tested plans, trained people, the right technology and regular review against current threat intelligence and evolving compliance requirements.

Red River works with defense contractors, federal agencies and enterprise organizations to design, test and deploy incident response programs across the full threat lifecycle. From developing your initial IR plan to deploying detection and response technology, we help you close the gaps before an attacker finds them.

Contact Red River to schedule an incident response assessment and find out where your program stands today.

Frequently Asked Questions