Technology
Most teams take 24–72 hours to resolve incidents. The fastest take 2–8.
The difference isn't faster people—it's faster decisions. Teams that resolve incidents in hours rather than days have clarity on who decides what during an active threat, and documented procedures for every scenario they're likely to face. Here's what separates them.
Incident resolution time depends on three things: how quickly threats are detected, how clearly teams know what to do when an alert fires, and who has authority to make containment decisions without delay. Organizations that achieve 2–8 hour resolution times invest in playbook automation, clear escalation frameworks, and runbook testing. Those stuck at 24–72 hours typically lack documented procedures or decision authority, forcing incident response to restart from first principles each time.
The performance range
| Metric | Minimum | Strong | World-class |
|---|---|---|---|
| Mean Time to DetectAverage elapsed time from when a security incident begins to when it is first identified by detection systems or personnel. | 8-24 | 2-8 | 0.5-2 |
| Mean Time to ResolveAverage elapsed time from initial detection of a security incident to full containment, remediation, and return to normal operations. | 24-72 | 8-24 | 2-8 |
| Security Incident Recurrence RatePercentage of resolved security incidents where the same threat, vulnerability, or attack vector reoccurs within a defined period. | 15-25 | 5-15 | 0-5 |
| Alert Fatigue RatioRatio of total security alerts generated by monitoring systems to the number of alerts that represent genuine threats requiring investigation. | 10:1 to 25:1 | 3:1 to 10:1 | 1:1 to 3:1 |
The gaps are dramatic. Detection speed ranges from 8–24 hours at the median to 0.5–2 hours at world-class, driven by monitoring maturity and alert quality. Resolution time spans 24–72 hours down to 2–8 hours—a 12-fold difference—shaped primarily by playbook clarity and decision authority, not team size or budget alone. Alert fatigue ratios worsen from 10:1 to 25:1 at median performance to 1:1 to 3:1 at the top, directly affecting investigation speed because teams spend time filtering noise instead of investigating real threats. Recurrence rates of 15–25 percent at median versus 0–5 percent world-class show that faster initial response means nothing if root causes aren't fixed; this gap reflects whether organizations embed learnings after incidents rather than just containing them.
Industry-Specific Benchmarks
These ranges are cross-industry. The figures differ materially by sector and company size.
Find benchmarks for your industry →What it takes to reach world-class
The difference between 8-hour and 72-hour resolution is not heroics or staffing. It is structure. Organizations resolving incidents in hours have already written the procedures—what to check, what to isolate, who to notify, in what order. They've assigned decision authority before the incident starts, so when a threat escalates, no one waits for a meeting to figure out who decides whether to take systems offline. Teams that resolve in days are rebuilding the response plan during the incident, under pressure, with incomplete information about who has authority to act.
Detection speed follows the same pattern. World-class teams detect threats in 30 minutes to 2 hours because their monitoring infrastructure and alert rules are already tuned to signal real threats, not noise. Median performers take 8–24 hours partly because their detection rules generate false alerts at 10:1 or worse, so analysts burn time filtering. Once detection is fast, investigation matters more. A playbook tells a team exactly which logs to pull, which systems to check for lateral movement, and what evidence to preserve. Without it, investigation becomes a conversation: "What should we look at next?" Every question adds an hour.
The third separation is post-incident. Organizations with 0–5 percent recurrence rates analyze each incident for root cause and update defenses or processes before the threat returns. Those with 15–25 percent recurrence rates are fighting the same battles repeatedly because they patched the symptom, not the cause. This feeds back into detection and resolution time: teams responding to the same incident type a second time waste less time and resolve faster, but the cost is paid in repeated breaches.
How leaders approach it
Build and maintain incident response playbooks for your threat landscape
An incident response playbook is a documented procedure for a specific threat scenario—ransomware, insider threat, supply chain compromise, data exfiltration. It includes what to check, in what order; which systems to isolate; what evidence to preserve; who to notify and when; and decision points where the response branches based on what you find. The playbook is written before an incident occurs, tested against past incidents or tabletop scenarios, and refined after each real incident that matches it.
The mechanism is simple: when an alert fires, your team doesn't start from "what do we do?" They start from "which playbook matches this alert?" and execute it. This eliminates the delay that comes from rebuilding response logic under pressure. A team following a playbook investigates the same way every time, which means they find evidence faster, make fewer errors, and hand off to remediation with complete information. The playbook also embeds communication and escalation workflows, so stakeholders learn about the incident through planned channels rather than discovering it afterward.
Playbooks also create a feedback loop. Each incident that matches a playbook tells you whether the procedures worked. If they did, you document what worked and make it standard. If they didn't, you update the playbook before the next matching incident occurs. Organizations that maintain playbooks for their five to ten most likely threats see 35–50 percent reduction in containment time for those incidents, and 20–30 percent improvement in investigation quality through consistent, documented procedures. The roadmap for building a playbook program runs in three phases: identify your top threats, write playbooks for each, and integrate them into alert response so that playbook execution is automatic rather than optional.
Leading Practice Report
Full detail: Incident Response Playbook Development and Maintenance
The full report covers:
- Expected benefits
- Core principles
- Key success factors
- Key metrics
- Risks and mitigations
- Implementation roadmap
Define incident decision authority before you need it
During an active incident, critical decisions happen quickly: whether to isolate a system, notify regulators, engage outside help, or go public. If those decisions require a meeting, a chain of approval, or debate about who has authority, you lose time—sometimes hours. An incident escalation and decision authority framework front-loads those decisions by defining, for each severity level, who decides what and within what time window.
A clear framework separates operational decisions (which systems to isolate, what logs to preserve) from executive decisions (whether to notify regulators, whether to engage outside counsel). It assigns decision authority by role and incident severity, so a level-two incident might give the incident commander authority to isolate systems without approval, while a level-three incident requires executive sign-off. It also defines escalation triggers—thresholds that automatically escalate an incident to senior leadership—so that no one is waiting to ask permission to escalate.
The payoff is two-fold. First, decision cycle time drops by 30–40 percent because teams know in advance who decides, not during the crisis. Second, decisions are better because they're made by someone with authority to implement them, not by committee consensus. Organizations in regulated industries see additional benefit: regulators require documented decision authority for breach response, and having it in writing beforehand protects the organization if decisions are later scrutinized. A framework typically includes severity definitions tied to business impact, pre-authorized decision rights for each severity tier, and clear escalation criteria so incidents automatically escalate when they meet a threshold.
Leading Practice Report
Full detail: Incident Response Escalation and Decision Authority Framework
Benefits, core principles, success factors, metrics, risks and the implementation roadmap.
Get the full report →Where to start
- Identify your three to five most likely threat scenarios based on your industry, recent threat intelligence, and past incidents if you have them
- For each scenario, document what detection would look like, what investigation steps come first, which systems need isolation, and who needs to be notified—this becomes your playbook skeleton
- Define severity levels and assign decision authority by role and severity level, so incident commanders, security leaders, and executives know in advance who decides what
Ask Kepler how to map your incident response procedures into playbooks, or how to audit your escalation framework for gaps.
Start free with Ask Kepler →Advanced and emerging approaches
Advanced & Emerging Practices
Emerging practices are included with Ask Kepler Pro and Max.
Unlock these practices →Curious how Ask Kepler Research is produced? Read our research methodology.
Performance Playbook
Incident Detection & Response: The gap between fast and unshakeable incident response
Learn what separates organizations that detect and contain incidents quickly from those achieving near-zero recurrence and predictable recovery. These six metrics show you where speed gains stall—and what foundational pr
Open the playbook →