Handbook
MTTD and MTTR in Security: Measuring What Matters
What are MTTD and MTTR in cybersecurity? Learn how to measure, benchmark, and improve your mean time to detect and respond to security threats.
Definitions: MTTD and MTTR
MTTD, Mean Time to Detect, measures the average time between when a threat actually enters an environment and when it's first identified by security tooling or personnel. MTTR, Mean Time to Respond (sometimes split into Mean Time to Contain and Mean Time to Resolve), measures the average time from that detection to the point where the threat has been contained or fully remediated. Together, these two numbers describe the entire lifecycle of an incident from the attacker's first foothold to the defender's final resolution, and they're the closest thing security operations has to a single scorecard for effectiveness.
It's worth being precise about what each measures, because they're often conflated. MTTD says nothing about how well you responded once you noticed a problem, an organization could have excellent detection and terrible response, or vice versa. Tracking them separately, rather than as one blended "time to fix" number, is what allows a team to diagnose which half of the pipeline actually needs improvement.
Industry benchmarks
Industry breach reports have consistently found average MTTD in the range of roughly 200 days for organizations that experience a significant data breach, and average MTTR adds weeks to months on top of that, meaning many organizations operate for the better part of a year with an active, undetected compromise before it's fully resolved. These averages are dragged up by organizations with minimal security tooling or staff; they are not a reflection of what's achievable with modern automation.
Top-performing SOCs, generally those with strong cross-source correlation and either significant staffing or meaningful automation, report MTTD under 24 hours and MTTR under an hour for the majority of incidents. Agentic SOC platforms push this further still: because detection and initial investigation happen continuously and automatically rather than in a human-driven cycle, well-tuned agentic environments target MTTD measured in minutes and MTTR in minutes for routine incidents, reserving longer response windows only for the genuinely complex cases that require human judgment.
Why these metrics matter
The relationship between dwell time and damage is close to linear in most attack scenarios: an attacker with a week of undetected access can exfiltrate far more data, move laterally to more systems, and establish more persistence mechanisms than one caught within an hour. Every additional hour a threat goes undetected is an hour it has to escalate privileges, discover more of your environment, and stage a bigger impact, which is why MTTD in particular has such an outsized effect on total incident cost.
These metrics have also become externally visible in ways they weren't a decade ago. Regulators in several jurisdictions now expect documented incident response timelines as part of breach disclosure requirements. Cyber insurance underwriters increasingly ask for MTTD/MTTR data (or proxies for it, like SOC staffing and tooling) as part of underwriting, and premiums reflect the answer. Enterprise customers doing vendor security reviews frequently ask directly about incident response times. What used to be an internal operational metric is now something you may need to produce evidence for.
How to improve MTTD and MTTR
Improving MTTD starts with closing detection blind spots: threats often go undetected not because a tool failed, but because no tool was monitoring the relevant data source at all. Automating detection across every telemetry source, endpoint, network, cloud, identity, email, removes the gaps an attacker would otherwise exploit to stay hidden.
Improving MTTR has two separate levers. The first is automating investigation, eliminating the manual step where an analyst gathers context from multiple tools before deciding how to respond, which is often the single largest time cost in the whole incident lifecycle. The second is automating response itself for routine, high-confidence scenarios, isolating a clearly compromised endpoint doesn't need to wait for a human to manually click through a console once the investigation has already concluded with high confidence. Both levers require continuous measurement to know whether they're actually moving the needle, a one-time tooling purchase without ongoing tracking tends to plateau rather than keep improving.
Agentic AI impact on MTTD/MTTR
Agentic AI changes both metrics by removing the human bottleneck from the two slowest parts of the cycle. Because an agentic platform correlates telemetry continuously rather than waiting for a scheduled review, detection approaches real-time rather than being limited by how often a human checks a dashboard. Because investigation and (within configured limits) response happen automatically the moment sufficient evidence exists, the gap between "detected" and "resolved" collapses from the hours or days typical of manual triage to minutes.
This represents a genuine step change rather than an incremental improvement. A traditional SOC improving MTTD/MTTR usually does so by adding staff or refining processes, which yields gradual, linear gains. Removing the human bottleneck from the investigation step entirely is a different kind of improvement, one that doesn't scale down as alert volume scales up, which is why agentic platforms can sustain minutes-level MTTR even as an organization's telemetry volume grows.
Common measurement mistakes
The most common mistake is measuring MTTD and MTTR only for confirmed incidents, ignoring the near-misses and false negatives that never got flagged as an "incident" in the tracking system at all. This creates a survivorship bias where your metrics look great because you're only counting the threats you successfully caught, not the ones that slipped through undetected for longer than anyone realized.
A second mistake is averaging across wildly different incident types. A phishing email caught by email security and a sophisticated multi-stage intrusion have very different natural response timelines, blending them into one average MTTR obscures whether your team is actually improving on the incidents that matter most. Segmenting metrics by incident severity or type, and tracking trend lines rather than single snapshots, gives a much more actionable picture of where response time is actually improving or stalling.
MTTD and MTTR by incident type
Not every incident type has the same realistic floor for detection and response time, and treating them as if they do leads to either unrealistic targets or metrics that hide real problems. A phishing email with a malicious link can often be detected within minutes by email security tooling, and responding just means blocking the sender and resetting any credentials entered, a process that can be substantially automated end to end.
A slow, low-and-slow intrusion designed specifically to avoid triggering common detection thresholds is a different problem entirely. These often rely on legitimate-looking administrative activity spread over days or weeks, and detecting them typically requires behavioral baselining (recognizing that a specific account or system is acting outside its normal pattern) rather than a simple rule match. Response for this category also tends to require more human judgment, since aggressive automated containment of what turns out to be legitimate but unusual activity carries its own business risk. Segmenting your MTTD/MTTR reporting by incident category, rather than reporting one blended number, is what lets a team see whether automation is working well for the fast, common cases while still allocating human attention appropriately to the slow, complex ones.
Setting realistic targets for your organization
Rather than adopting industry-average or best-in-class benchmarks wholesale, it's more useful to set targets based on your organization's actual risk tolerance and current baseline. A useful first step is simply measuring your current MTTD and MTTR accurately for a full quarter before setting any target at all, many organizations discover their actual numbers are worse than assumed, since incidents that were quietly resolved without formal tracking don't show up in institutional memory the way a major breach would.
Once you have an honest baseline, targets that represent meaningful year-over-year improvement (cutting MTTR by half, for example) tend to drive more useful process change than trying to match a headline statistic from a vendor case study on day one. As automation, whether SOAR-based or agentic, gets layered in, re-measure rather than assuming the tooling delivered the vendor's marketed improvement, actual results depend heavily on how well the automation is integrated with your specific environment.
How MTTD and MTTR interact with compliance frameworks
Several major compliance and regulatory frameworks now reference incident detection and response timelines directly or indirectly. Breach notification laws in many jurisdictions start a countdown clock from the moment a breach is discovered, which puts direct pressure on MTTD, the longer detection takes, the less time remains to investigate, document, and notify within the legal window once discovery finally happens.
Frameworks like SOC 2 and ISO 27001 don't mandate a specific MTTD or MTTR number, but auditors increasingly expect organizations to demonstrate they measure these metrics at all and can show a documented incident response process with realistic timelines attached. Organizations that can produce clean MTTD/MTTR reporting as part of an audit typically move through compliance reviews faster than those relying on anecdotal claims about response speed.
Putting it into practice: a simple starting framework
For a team just starting to formalize MTTD/MTTR tracking, the simplest useful starting point is a shared incident log capturing three timestamps for every confirmed incident: when the underlying activity actually began (reconstructed after the fact from logs), when it was first detected, and when it was fully contained. Even a basic spreadsheet tracking these three timestamps consistently for a quarter produces more actionable insight than an expensive dashboard tool used inconsistently.
Once that baseline habit is established, the natural next step is automating the data collection itself, since manually reconstructing incident timelines doesn't scale past a handful of incidents a month. This is one of the underrated side benefits of agentic SOC platforms: because the system investigates and documents each incident automatically, accurate MTTD/MTTR reporting becomes a byproduct of normal operations rather than a separate administrative task someone has to remember to do.
Key takeaways
MTTD and MTTR together give the clearest available picture of whether a SOC, however it's staffed or automated, is actually protecting the organization, since every other security metric ultimately feeds into how quickly threats are found and resolved. Tracking them consistently, segmented by incident type, and benchmarked against your own honest baseline rather than an industry average, turns an abstract sense of "we're doing okay" into a concrete, defensible measure of performance.
The biggest single lever for improving both metrics is removing the human bottleneck from investigation, which is exactly what separates a traditional SOC (where both numbers are measured in hours to days even when well-run) from an agentic SOC (where routine incidents can be measured in minutes). Whatever model your organization uses today, MTTD and MTTR are the two numbers worth measuring first and improving hardest.
Put this into practice
See how Helxon applies these principles with autonomous investigation and response.