Incident response is the structured process organizations use to detect, contain, and recover from cybersecurity incidents, typically organized into either four phases under the NIST framework or six steps under the SANS framework. A tested incident response plan saves an average of $2.66 million per breach, according to research compiled from 2026 breach data. The global average cost of a data breach hit $4.99 million in 2026, per the IBM 2026 Cost of a Data Breach report. That gap between “tested plan” and “no plan” is not theoretical. It shows up on your balance sheet.

I’ve spent over 20 years watching businesses handle security incidents badly. Not because they lacked technology. Because they had no plan. When an attack hits at 11pm on a Friday, you don’t have time to Google the response process. You need a documented, practiced framework your team can execute under pressure. That’s what this guide gives you.

What Is Incident Response?

Incident response is the organized approach to managing the aftermath of a security breach or cyberattack, with the goal of limiting damage, reducing recovery time, and preventing recurrence. It covers the full lifecycle: from building defenses before an attack, through detecting and stopping it, to restoring operations and learning from what went wrong.

The scope is broader than most people assume. An incident response plan covers ransomware, phishing, data breaches, denial-of-service attacks, insider threats, and malware infections. Any event that threatens the confidentiality, integrity, or availability of your systems qualifies.

An incident response plan is the documented version of that process. It defines who does what, when, and how. Without one, you’re making decisions under fire, with incomplete information and no clear chain of command. That’s when expensive mistakes happen.

Why a Tested Incident Response Plan Is Non-Negotiable

The financial case for incident response planning is concrete: organizations with tested plans save an average of $2.66 million per breach compared to those without, based on 2026 breach cost analysis. For US-based businesses, the stakes are even higher. The United States averaged $11.5 million per breach in 2026, nearly double the global average.

Those numbers should reframe how you think about incident response investment. It’s not a cost center. It’s loss prevention.

Speed is the other factor. The IBM 2025 report found that breaches took an average of 181 days to identify and 60 days to contain. That’s roughly eight months of undetected damage before containment even begins. Every day an attacker stays inside your network, they’re exfiltrating data, escalating privileges, and entrenching themselves further.

Regulatory pressure adds another layer. GDPR, HIPAA, and PCI DSS all carry mandatory breach notification requirements with hard deadlines. If your incident response process isn’t organized, you’re at risk of missing those windows and compounding financial penalties on top of breach costs.

NIST vs. SANS: Two Frameworks, One Goal

The NIST and SANS incident response frameworks are the two most widely adopted standards, and they cover the same ground with slightly different structures. NIST uses four phases; SANS uses six steps. Both are sound. The choice depends on your organization’s size, resources, and how granular you want your process to be.

NIST finalized SP 800-61 Revision 3 on April 3, 2025, updating its incident response guidance for the first time in over a decade. That revision reflects how much the threat environment has changed, including the growing role of AI-enabled attacks.

The table below maps both frameworks side by side so you can see where they align:

NIST’s four-phase model is better suited to organizations that want a high-level policy framework, particularly those aligning with federal or government standards. SANS’s six-step model is more operationally specific, making it a practical fit for security teams who need clear, sequenced actions during an active incident.

Neither framework is wrong. Most mature security programs borrow from both.

The 6 Incident Response Steps: SANS Framework in Detail

The six SANS incident response steps are Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned, forming a repeating cycle that improves with each iteration. These incident response steps are not a one-time project. They are an ongoing operational discipline.

Walk through each one. The detail here is intentional. A checklist that lives in a folder no one reads is not a plan. A process your team has rehearsed and owns is.

Step 1: Preparation

The preparation phase of incident response is everything you do before an attack arrives, and it determines how well every other step goes. Most businesses underinvest here. They buy a firewall, maybe a SIEM, and assume they’re covered. They’re not.

Preparation means your Computer Security Incident Response Team (CSIRT) exists, is trained, and has clear roles. It means your incident response plan is documented and not sitting in someone’s email drafts. It means you’ve run tabletop exercises so your team has muscle memory before a real crisis.

Concrete actions for the preparation phase:

• Document and distribute your incident response plan to all relevant stakeholders
• Define your CSIRT structure with named roles: incident commander, SOC analyst, forensics lead, legal and compliance contact, and executive liaison
• Implement logging and monitoring tools, including a SIEM platform, endpoint detection and response (EDR), and threat intelligence feeds
• Establish communication protocols, including out-of-band channels that don’t rely on potentially compromised systems
• Run tabletop exercises at least quarterly to test your incident response plan under realistic scenarios
• Verify that backups are current, tested, and stored offline or in an isolated environment

One thing most people skip: security awareness training for non-technical staff. The 2026 Verizon DBIR found that vulnerability exploitation became the leading initial access vector at 31% of breaches. Train your people. Patch your systems. Both.

Step 2: Identification

The identification step in incident response is the process of detecting a potential security incident, validating that it is real, and determining its scope before taking action. This is where indicators of compromise (IOCs) become your primary signals.

IOCs are the technical evidence that something has gone wrong. They include unusual outbound network traffic, failed login attempts at odd hours, unexpected changes to system files, new admin accounts no one created, and alerts from your endpoint detection tools. An IOC is not proof of a breach on its own. Multiple IOCs pointing in the same direction usually are.

The identification step also involves precursors, which are signs that an attack may be imminent rather than already underway. A precursor might be a threat intelligence alert about a vulnerability in software you use, or a spike in scanning activity against your network perimeter.

Key actions during identification:

• Centralize your log data so analysts can correlate events across systems
• Assign an incident severity level immediately using a predefined classification scale
• Document every finding, including timestamps, affected systems, and the identity of who discovered the incident
• Validate the incident to rule out false positives before escalating
• Notify your CSIRT and initiate your incident response plan formally once confirmed

Speed matters here, but accuracy matters more. Acting on a false positive wastes resources. Missing a real incident because the alert was dismissed is far more costly. The IBM 2025 report’s 181-day average identification time shows how long attackers typically go undetected. Better detection tools and trained analysts close that gap significantly.

Step 3: Containment

The containment phase of incident response stops the spread of an attack without destroying the forensic evidence needed to understand what happened. This is the step where decisions made in seconds have consequences that last months.

There are two types of containment. Short-term containment is immediate: isolate the affected system from the network, disable the compromised account, block the malicious IP. You’re stopping the bleeding. Long-term containment follows: patch the vulnerability temporarily, rebuild systems from clean images, implement additional monitoring on adjacent systems you suspect may be affected.

What not to do: don’t power off affected systems immediately unless absolutely necessary. Live memory often contains volatile forensic evidence including encryption keys, running malware processes, and attacker command-and-control connections. Your forensics team needs that data.

Actions during the containment phase:

• Isolate affected systems using network segmentation rather than full shutdown where possible
• Preserve forensic images of affected systems before any remediation begins
• Block identified malicious indicators of compromise at the firewall, DNS, and email gateway levels
• Disable or reset credentials for any compromised accounts
• Brief your legal and compliance team if personal data may have been accessed, as breach notification timelines may have already started

Step 4: Eradication

The eradication phase of incident response removes the root cause of the security incident from all affected systems once containment is confirmed. Containment stops the spread. Eradication eliminates the threat entirely.

Root cause analysis is the foundation of eradication. You need to know not just what malware ran, but how it got in, what accounts it touched, and whether it left any persistence mechanisms behind. Skipping root cause analysis is the most common reason organizations suffer repeat incidents from the same attacker.

The 2026 DBIR reported a 34% increase in median vulnerability patch time, now averaging 43 days. That’s a 43-day window attackers are actively exploiting. Eradication means closing those windows permanently, not temporarily.

Eradication actions:

• Remove all identified malware, backdoors, and attacker-installed tools from affected systems
• Conduct root cause analysis to identify the initial entry point and every system the attacker touched
• Apply patches to all exploited vulnerabilities across the entire environment, not just the affected system
• Reset credentials for all potentially compromised accounts, including service accounts
• Scan adjacent systems for indicators of compromise before declaring eradication complete

Don’t declare eradication complete until you’ve validated it. One missed backdoor means the attacker is still in your network while you’re busy recovering.

Step 5: Recovery

The recovery phase of incident response restores affected systems to normal operation, with additional monitoring in place to confirm the threat has been fully removed. This is not “turn it back on and hope for the best.” Recovery requires a structured return to service with clear validation checkpoints.

Recovery timing matters. Bring systems back too quickly and you risk reinfection. Take too long and the business impact compounds. Your incident response plan should define recovery criteria in advance, specific conditions that must be met before a system returns to production.

Recovery actions:

• Restore systems from clean, verified backups rather than the potentially compromised production environment
• Validate restored systems against a known-good baseline before reconnecting them to the network
• Implement enhanced monitoring on recovered systems for at least 30 days post-incident
• Test all critical business functions before declaring full recovery
• Brief relevant stakeholders, including customers or regulators if required by GDPR, HIPAA, or PCI DSS breach notification obligations

If you don’t have verified backups, recovery becomes an expensive rebuild from scratch. Backups matter more than policies. Test them quarterly, not annually.

Step 6: Lessons Learned

The lessons learned phase of incident response is a structured post-incident review that documents what happened, what worked, what failed, and what changes the organization will make to prevent recurrence. It’s the most consistently skipped step in the process. That’s a mistake.

Lessons learned is where incident response improves. Without it, you’re running the same process against an attacker who is constantly refining their approach. A formal post-incident review, typically conducted within two weeks of containment, should produce concrete changes to your incident response plan, security controls, or team training.

Post-incident review agenda:

• Timeline reconstruction: document exactly what happened, when, and in what sequence
• Gap analysis: identify where detection failed, where response was slow, and where communication broke down
• Root cause confirmation: validate that the root cause identified during eradication was complete and accurate
• Control updates: determine which technical controls, policies, or procedures need to change
• Training needs: identify skills gaps in the CSIRT that the incident exposed

The lessons learned report should be shared with executive leadership. Not because it’s a compliance exercise, but because the people who fund security programs need to understand what those programs faced and what improvements are needed. Clients won’t care about your policy. They’ll care that you prevented the next breach.

NIST SP 800-61 Revision 3: What Changed in 2025

NIST SP 800-61 Revision 3, finalized in April 2025, updated the federal incident response guidance framework to address cloud environments, AI-enabled threats, and supply chain risks that didn’t exist in the same form when the previous version was published. Organizations aligning their incident response plan to NIST standards should review Revision 3 directly.

The core four phases remain: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. What Revision 3 adds is more explicit guidance on threat sharing, coordination with third-party providers, and the role of automation in incident detection and response.

The timing matters. One in four malicious breaches in 2026 were AI-enabled, costing companies $6 million on average. The threat environment that Revision 3 addresses is already here. And only 36% of organizations have extensively adopted AI and automation in their cybersecurity operations. That gap is where attackers are operating.

For SMEs, the practical takeaway from Revision 3 is straightforward: your incident response plan needs to account for cloud-hosted systems and third-party dependencies. If a breach originates in a vendor’s environment, your detection and containment steps need to cover that scenario explicitly.

CSIRT Roles and Responsibilities

A Computer Security Incident Response Team (CSIRT) is the group of people responsible for executing your incident response plan when a security incident occurs, and their roles must be defined before an attack, not during one. Roles assigned under pressure produce confusion. Roles rehearsed in advance produce action.

The CSIRT doesn’t have to be a dedicated security department. For most SMEs, it’s a cross-functional team with defined incident response responsibilities on top of their primary roles.

Core CSIRT roles and their functions:

• Incident Commander: owns the incident response process, makes prioritization decisions, and is the single escalation point during an active incident
• SOC Analyst / Detection Lead: monitors alerts, validates indicators of compromise, and manages the identification and initial analysis steps
• Forensics Lead: preserves evidence, conducts root cause analysis, and documents the attack timeline
• IT/Systems Lead: executes containment, eradication, and recovery actions on affected infrastructure
• Legal and Compliance Officer: advises on breach notification obligations under GDPR, HIPAA, or PCI DSS and manages regulatory communication
• Executive Liaison: keeps senior leadership informed and makes resourcing decisions during extended incidents

Every person in this list should have a backup. Incidents don’t schedule themselves for business hours.

Common Security Incident Types Your Plan Must Cover

A security incident is any event that compromises the confidentiality, integrity, or availability of information systems, and your incident response plan needs specific playbooks for the most common types rather than a single generic process. Generic responses produce generic outcomes.

The threat data is clear about what to prioritize. The 2025 Verizon DBIR found that 44% of all confirmed breaches involved ransomware. That’s the category demanding the most specific and well-rehearsed response playbook.

Beyond ransomware, your incident response plan should include playbooks for:

• Phishing and business email compromise: the most common initial access method, requiring fast account containment and credential reset procedures
• Data breach: exfiltration of personal or sensitive data, triggering regulatory notification timelines and legal obligations
• Denial-of-service attack: availability impact requiring traffic filtering and ISP coordination
• Malware infection: broad category requiring forensic analysis to distinguish opportunistic malware from targeted intrusion
• Insider threat: requires a different evidence handling and HR coordination process than external attacks

Each playbook should map directly to the six incident response steps, specifying the exact actions, escalation paths, and decision points for that incident type. A playbook your team can follow at 2am under pressure is worth more than a perfect policy document no one has read.

Building Your Incident Response Plan: Where to Start

An incident response plan is a documented, tested process for managing security incidents, and building one begins with a current-state assessment of what you have, what you’re missing, and who owns what. Don’t start by writing the plan. Start by auditing your existing capabilities.

Most SMEs have more security infrastructure than they realize, and significantly larger gaps than they expect. The audit surfaces both.

Your starting point should be a cybersecurity risk assessment that maps your assets, identifies your most likely attack vectors, and prioritizes your response capabilities accordingly. That assessment should feed directly into your incident response plan structure.

From there, the build sequence is straightforward:

1. Define your incident classification criteria: what counts as a low, medium, high, and critical incident
2. Assign CSIRT roles and document backup contacts for each
3. Write playbooks for your top five most likely incident types, starting with ransomware and phishing
4. Document your communication procedures, including how you notify staff, customers, regulators, and the press if required
5. Test the plan with a tabletop exercise before declaring it complete
6. Schedule quarterly reviews to update the plan as your environment and the threat landscape change

If you’re also working on your broader security posture, understanding what Cyber Essentials certification covers is a practical parallel track. It addresses the technical controls that support the preparation phase of your incident response program.

One final point on testing. An untested incident response plan is a theory. The tabletop exercise is where you find out whether your plan actually works, whether your CSIRT knows their roles, and whether your communication chains hold. Run one. Then run it again after making the changes the first one exposed.

If you want to learn how incident response connects to your broader cybersecurity framework for SMEs, that’s the next logical step. Incident response doesn’t exist in isolation. It’s one component of a security program that covers prevention, detection, and recovery together.

The painful truth is that most businesses are one well-timed phishing email away from a serious incident. The difference between a contained, recoverable event and a catastrophic breach usually comes down to one thing: whether you had a tested incident response plan before the attack hit. Build it now. Test it before you need it.