Incident response (IR) is the structured process an organization follows to detect, contain, eradicate, and recover from a cybersecurity incident, then document what it learned. A defined lifecycle is what separates a coordinated response from an improvised one.
Key takeaways
- Incident response is a repeatable lifecycle, not a one-time reaction. Most teams run a six-step model: preparation, identification, containment, eradication, recovery, and lessons learned.
- The six-step model is the SANS framework. NIST’s guidance is structured differently, and its 2025 revision reframes IR as an ongoing risk management function rather than a short, bounded event.
- Incident response, managed detection and response (MDR), and threat hunting are sequential, not competing. Hunting finds what detection missed, MDR detects and triggers response, and IR is the framework that executes it.
- Ownership sits with a named incident response team led by an incident commander, with legal, communications, and IT pulled in by role.
- A plan you haven’t tested isn’t a plan. Tabletop exercises are how teams find the gaps before an attacker does.
- Speed of containment, not depth of investigation, is what limits damage in the first hour.
Incident response is how a security team turns a confirmed threat into a resolved one without improvising under pressure. It covers everything from the playbooks written months in advance to the after-action report filed once systems are back online. Most organizations map their process to a published lifecycle so response actions stay consistent and defensible, whether the incident is a single phished credential or active ransomware across three subnets. For teams without round-the-clock staffing, much of that lifecycle gets executed by a managed detection and response (MDR) provider, which detects the threat and triggers response in real time rather than waiting for a ticket.
How is NIST’s incident response guidance different?
This is where a lot of published content gets it wrong. The six-step lifecycle above is SANS. NIST’s SP 800-61 Revision 2 used a four-phase model that grouped containment, eradication, and recovery into a single phase.
In April 2025, NIST published SP 800-61 Revision 3, which restructured the guidance entirely. Rather than a standalone lifecycle, it maps incident response onto the six functions of the Cybersecurity Framework (CSF) 2.0—govern, identify, protect, detect, respond, and recover—and splits them across two broad phases: preparation and incident response. The shift reflects a real change in how breaches behave. Incidents now unfold over weeks, not days, so NIST treats IR as a continuous part of cybersecurity risk management instead of a discrete set of tasks bolted onto a crisis.
Practically, this means you can build a defensible program on either model. What matters is that your plan names phases, assigns owners, and defines the deliverable at each step.
What’s the difference between incident response, MDR, and threat hunting?
These three get used interchangeably, and they shouldn’t be.
| What it is | When it happens | Who runs it | |
|---|---|---|---|
|
Threat hunting |
Proactive, hypothesis-driven search for threats that evaded detection | Continuously, on a hunt schedule | Threat hunters or SOC analysts |
|
Incident response |
Reactive framework for handling a confirmed incident | After a threat is confirmed | IR team |
|
MDR |
Always-on service that detects threats and triggers response | 24×7 | External MDR provider’s SOC |
The relationship is sequential. Threat hunting surfaces the compromises automated detection missed. MDR catches what does alert and starts response in minutes. Incident response is the framework both feed into. A mature program runs all three, and most organizations get the 24×7 layer from a provider rather than building it in-house.
For how these phases run operationally on a day-to-day basis—the triage queue, the automation, the escalation path—see how SOC teams handle incident response.
Who owns incident response in an organization?
Ownership is a named set of roles, not a department. A typical incident response team includes an incident commander who makes final calls, security analysts who investigate and contain, an infrastructure owner who executes technical changes, legal counsel who assesses regulatory exposure, and a communications lead who handles internal and customer messaging.
The incident commander role exists specifically so decisions don’t stall in committee while an attacker moves laterally. Smaller organizations often assign these responsibilities to existing staff using a responsible, accountable, consulted, informed (RACI) matrix, then outsource 24×7 monitoring and rapid containment to an MDR provider. What can’t be outsourced is the internal owner accountable for business decisions—whether to take a revenue system offline, when to notify regulators, what to tell customers.
How do you build an incident response plan?
An incident response plan is the documented, pre-approved version of everything above: phase-by-phase actions, named roles, a severity scale, escalation paths, communication templates, and breach notification steps. It’s the artifact your team reads at 2am, so it needs to be short enough to actually use.
The plan is only as good as its last test. A tabletop exercise walks the response team through a simulated scenario without executing anything live, which is the cheapest way to find out that your on-call rotation has a gap or that nobody knows who signs off on isolating a production database.
Incident response best practices
- Write playbooks for your three most likely scenarios first—phishing, ransomware, and business email compromise cover most real incidents.
- Define severity levels with concrete triggers, not adjectives. “Critical” should mean something measurable.
- Pre-authorize containment actions. If an analyst needs a VP’s approval to isolate a host at 3am, your MTTR is measured in hours.
- Keep an out-of-band communication channel. If your identity provider is compromised, so is your chat tool.
- Test the plan at least twice a year, and always after a tool migration or org change.
- Track remediation work separately from containment. A contained incident isn’t a closed one.
- Log the decisions, not just the actions. Post-incident reviews and regulators both need to know why you did what you did.
Expel’s take
Most published IR content describes the lifecycle and stops there. The harder question is who’s executing it at 2pm on a Sunday.
Inside Expel, the response phases aren’t a document—they’re the operating model of our 24×7 SOC. Detections fire into Expel Workbench™, where automated triage and enrichment handle the correlation work that would otherwise eat the front end of every investigation. Ruxie™, our AI teammate, drafts the investigative context so the analyst starts from a working hypothesis instead of a blank alert. That’s AI in the human loop: human-led, AI-powered, with a named analyst making every containment call.
That combination is what gets us to a 14-minute mean time to remediate (MTTR) on fully automated high- and critical-severity incidents. And because our detections and playbooks are refined across every environment we cover, an attacker technique we see at one organization sharpens response for all of them. That’s the part a template can’t give you.
Frequently asked questions
What is incident response in cybersecurity?
Incident response is the organized process security teams use to prepare for, detect, contain, eradicate, and recover from cybersecurity incidents, then document lessons learned. It follows a defined lifecycle so response actions are consistent, fast, and defensible rather than improvised during a crisis.
What are the six phases of incident response?
The six phases in the widely used SANS model are preparation, identification, containment, eradication, recovery, and lessons learned. NIST’s guidance is structured differently—SP 800-61r2 used four phases, and the 2025 revision maps IR onto the six CSF 2.0 functions instead. Each phase has specific deliverables, from IR playbooks in preparation to a formal after-action report at the end.
What is the difference between incident response and MDR?
Incident response is the reactive framework for handling a confirmed security event. MDR is the always-on service—people, tools, and process—that detects threats and triggers that framework in real time. Expel’s SOC executes IR’s detection, containment, and recovery steps as part of continuous 24×7 coverage.
Who is responsible for incident response in an organization?
Responsibility sits with an incident response team led by an incident commander, supported by security analysts, IT, legal, communications, and often an external MDR provider. Smaller organizations frequently outsource execution while keeping an internal owner accountable for business decisions and stakeholder communication.
What is a security incident?
A security incident is any event that violates an organization’s security policy or threatens the confidentiality, integrity, or availability of its systems or data, ranging from a phishing click to active ransomware. Not every alert is an incident. Incident response begins once an event is confirmed as a real threat requiring action.