Technology
Most breaches hide for 8-24 hours. The best find them in minutes.
Detection speed separates organizations that contain breaches from those that don't. We mapped what world-class threat detection requires, and how to measure whether you're building toward it.
Proactive threat detection requires three elements working together: systematic identification of attack vectors before they're exploited (threat modeling), rigorous management of known vulnerabilities so patches are applied within weeks rather than months, and continuous analysis of incoming threats correlated against your specific environment. Organizations that excel at this detect intruders in 30 minutes to 2 hours rather than days, and prevent most incidents from occurring at all.
What good looks like
| 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 |
| Compliance Violation Remediation CoveragePercentage of identified security control gaps or compliance violations that have been addressed with corrective action within mandated timeframes. | 70-80 | 85-95 | 95-99 |
Detection speed matters because every hour an attacker operates undetected multiplies the damage. The gap between minimum-tier organizations (8-24 hours) and world-class (30 minutes to 2 hours) reflects differences in monitoring infrastructure investment, threat intelligence quality, alert automation, and how ruthlessly organizations tune detection rules to eliminate false positives. The alert fatigue ratio shows the mechanism: minimum-tier teams drown in 10-25 false alerts for every real threat, so they miss genuine signals in the noise. World-class teams operate at 1-3 false alerts per real threat, which means alert triage is fast enough to matter. This ratio doesn't improve through better tools alone—it requires iterative tuning of detection rules, correlation of alerts against threat intelligence specific to your industry and systems, and machine learning models that learn your baseline behavior so anomalies stand out.
Industry-Specific Benchmarks
These ranges are cross-industry. The figures differ materially by sector and company size.
Find benchmarks for your industry →Why the gap exists
The organizations detecting threats in 30 minutes to 2 hours share one critical characteristic: they treat threat detection as a continuous operational problem, not a capability gap to close someday. They invest in monitoring infrastructure that touches every critical system—not just perimeter devices, but application logs, endpoint activity, and cloud infrastructure. They feed their detection systems with threat intelligence tailored to their industry and their specific attack surface, not generic feeds. Most importantly, they've invested in the unglamorous work of tuning their detection rules over time, removing the noise that makes real alerts invisible.
Middle-tier organizations often have the tools but not the discipline. They may have a SIEM deployed, but it's not integrated with current threat intelligence. They collect alerts but haven't automated alert triage, so junior analysts spend their time verifying low-risk signals instead of investigating genuine threats. Their detection rules fire at everything, creating alert fatigue that is functionally equivalent to having no detection at all. The gap is not technology—it's operational maturity: the patience to measure alert quality, the process discipline to tune rules iteratively, and the commitment to keep threat intelligence current as your attack surface changes.
The organizations at the minimum tier often treat detection as a compliance checkbox. They have security monitoring in place because audit requirements or insurance mandates it, but they've never measured mean time to detect, they don't correlate alerts against threat intelligence, and when an alert fires, they don't have a clear process for triage. The result is that attackers move undetected for days because legitimate signals are buried under noise or never reach anyone who can act on them.
What leading organizations do
Threat Modeling: Identifying Attack Vectors Before Attackers Do
Threat modeling is systematic thinking about how an attacker would approach your systems. Rather than assuming your architecture is secure and then scanning for vulnerabilities, you map your systems from an attacker's perspective—tracing data flows, identifying trust boundaries, and pinpointing where an adversary could enter. For a software development organization, this means asking "where would an attacker inject a command?" or "which API endpoints touch sensitive data?" during architecture design, not after code ships. For infrastructure teams managing cloud migrations or complex on-premises environments, it means asking which systems would give an attacker the highest-value foothold, and which data stores are accessible from multiple paths.
The mechanism is simple but disciplined: force teams to think like adversaries during the design phase, when changes are cheap and reversible. Threat modeling surfaces architectural decisions that leak security risk—a database accessible from the web tier, overly broad permission sets, or insufficient network segmentation. These are expensive to fix after deployment. Organizations that embed threat modeling into their development and architecture processes catch 20-35% more exploitable weaknesses during design, meaning they never ship them. The output is also concrete: a prioritized list of which attack vectors matter most to your business, which drives investment decisions. Rather than treating all vulnerabilities equally, you know which ones would actually enable attackers to reach valuable data or systems.
The payoff compounds over time. Teams that practice threat modeling systematically—making it a step in architecture reviews, cloud migrations, and major feature development—build institutional knowledge about their own attack surface. They stop repeating the same architectural mistakes. New team members learn to think about security early rather than bolted-on late. And because threat modeling surfaces issues when they're cheap to remediate, the practice reduces the backlog of security debt that most organizations accumulate.
Leading Practice Report
Full detail: Threat Modeling and Attack Surface Analysis
The full report covers:
- Expected benefits
- Core principles
- Key success factors
- Key metrics
- Risks and mitigations
- Implementation roadmap
Vulnerability Management: From Months to Weeks
The sobering fact is that most breaches exploit vulnerabilities that security patches already existed for when the breach occurred. The attacker didn't discover a zero-day—they found a system running software with a known, fixable vulnerability. The problem isn't that vulnerabilities exist. It's that organizations can't reliably apply patches across their entire environment, and they don't prioritize which vulnerabilities matter most to their business. A formal vulnerability management program fixes both problems.
Vulnerability management operates as a cycle: discover vulnerabilities (through scanning, threat intelligence, and vendor disclosures), assess their risk to your specific business (not their general severity), prioritize which ones matter most, and apply fixes within agreed timeframes. The discipline is risk-based prioritization. A critical vulnerability in a system that faces the internet and touches customer data gets patched within days. The same vulnerability in an internal tool used by six people gets addressed in a slower timeframe. This sounds obvious, but most organizations don't have the governance to execute it—they either patch everything slowly or they patch nothing, because they lack the process to triage and track remediation across teams.
Organizations that implement formal vulnerability management reduce the window during which known vulnerabilities are exploitable from months to 2-4 weeks, cutting vulnerability-based breach risk by half or more. The mechanics require coordination: automated discovery so you know what you're running, clear service-level agreements for patching by criticality tier, change management processes that prevent security patches from destabilizing production, and continuous measurement. The roadmap for this runs in three phases: establishing baseline visibility of what you're running, automating discovery and remediation workflows, and maturing risk-based prioritization. Smaller organizations often skip to phase two and fail because they can't govern the backlog. Larger organizations get stuck in measurement without action. The organizations that win are those that define clear remediation timelines and hold teams accountable for meeting them.
Leading Practice Report
Full detail: Vulnerability Management and Patch Governance
Benefits, core principles, success factors, metrics, risks and the implementation roadmap.
Get the full report →Industry context
Detection speed requirements vary by industry and threat sophistication. Financial services and healthcare face highly motivated attackers with expensive targeting campaigns, meaning a detection latency of 8-24 hours may already be catastrophic—the attacker has moved to valuable systems and stolen data. Manufacturing and critical infrastructure organizations face nation-state threats where detection in minutes rather than hours is the difference between containment and widespread disruption. Technology and SaaS organizations often face volume attacks and automated exploitation, where detection speed determines whether a vulnerability becomes a widespread breach or a single-system incident.
The investment required to reach world-class detection also varies. Organizations with simple, centralized infrastructure—a few applications running on managed cloud—can implement strong detection with modest investment in SIEM licensing and threat intelligence feeds, because they have fewer systems to monitor and less noise to filter. Organizations with distributed infrastructure, legacy systems, and complex dependencies face higher friction: they need more comprehensive monitoring to achieve visibility, they struggle with alert fatigue because of system heterogeneity, and their remediation timelines extend because systems have complex dependencies. These organizations often benefit most from starting with threat modeling and vulnerability management (the foundational practices) because fixing those gaps directly reduces the number of exploitable attack surfaces their detection systems need to monitor.
Smaller organizations often assume proactive threat detection is out of reach because they can't afford a large security team. In practice, they benefit disproportionately from the foundational practices—threat modeling is a design discipline that scales down, and vulnerability management is governance more than head-count. Larger organizations with mature security teams often assume they're already detecting threats proactively, when in fact they're buried in alert noise because they've never systematized rule tuning or threat intelligence correlation.
Where to start
- Measure your current detection latency. Run a vulnerability scan, document what you find, and time how long it takes from discovery to remediation. Compare that to the benchmark: 2-8 hours is strong performance, 8-24 hours is minimum acceptable. Most organizations discover they're in the 24-72 hour range.
- Map your current attack surface. This is threat modeling at the simplest level: draw your critical systems and data flows on a whiteboard. Identify which entry points would give an attacker the highest-value access. List the three systems you'd patch first if you had unlimited resources. This becomes your prioritization framework.
- Audit your vulnerability discovery process. Ask: who owns patching for each system category? What's your current patch application timeframe for critical vulnerabilities? Do you have a formal risk assessment process or do you patch randomly? Document the gaps—you're building the case for process investment.
- Inventory your threat intelligence. If you have feeds, document where they come from and whether anyone is actually using them in detection tuning. If not, identify which industry-specific threat intelligence would be most relevant to your business.
Ask Kepler: What does proactive threat detection require in your specific infrastructure, and where should a mid-market security team focus first?
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 →