Mean Time to Detect vs Mean Time to Respond
First developed as part of our TRACE Score whitepaper, May 2026. Expanded and updated for this site.
On February 12, 2024, an unauthorized actor accessed Change Healthcare's systems using compromised credentials that lacked multi-factor authentication. The breach went undetected for nine days before UnitedHealth Group discovered it on February 21 --- and containment took weeks longer as the ransomware operator had already moved laterally through critical systems handling one-third of all U.S. health claims. The MTTD and MTTR together --- nine days undetected, followed by weeks of containment --- determined that UnitedHealth's total exposure would cost $2.4 billion across remediation, business disruption, and regulatory consequences. A shorter MTTD would not have prevented the initial compromise. But it would have limited the blast radius to a single system rather than an enterprise-wide catastrophe.
Why Now
The SEC's cybersecurity disclosure rules (effective December 2023) require public companies to disclose material incidents within four business days of determining materiality. This creates a direct regulatory linkage between MTTD and disclosure obligations: if your MTTD is 197 days (the industry average), you are disclosing breaches that have been active for over six months --- and investors, regulators, and plaintiffs' attorneys will ask why. The four-day clock starts at discovery, but the court of public opinion judges the total dwell time. For defense contractors, DFARS 7012 mandates reporting to the DoD within 72 hours of discovery. For healthcare, HIPAA's breach notification rule gives 60 days from discovery. In every case, MTTD directly determines regulatory exposure window.
The Two Metrics That Define SOC Performance
Mean Time to Detect (MTTD) is the average time between when an attack begins and when the security team becomes aware of it. It measures the gap between compromise and visibility.
Mean Time to Respond (MTTR) is the average time between detection and containment/remediation. It measures how quickly your team neutralizes a known threat.
The sum of MTTD and MTTR equals the total exposure window --- the period during which an attacker has access to your environment. Every day inside that window, the attacker moves laterally, escalates privileges, stages data for exfiltration, and deepens their foothold. The cost of a breach correlates almost linearly with this total window.
Why These Metrics Matter
The Cost of Dwell Time
Industry research consistently shows that breach cost correlates directly with dwell time. IBM's Cost of a Data Breach Report documents that breaches identified in under 200 days cost an average of $3.93M, while those identified after 200 days cost $4.95M --- a $1M penalty for slow detection that repeats across every industry vertical. But that average obscures the tail risk: Change Healthcare ($2.4B), Colonial Pipeline ($4.4M ransom plus $1B+ in economic disruption), and Maersk ($300M from NotPetya) all involved extended dwell times or containment delays.
Compliance Requirements
Multiple frameworks reference detection and response timeliness:
- FedRAMP continuous monitoring expects timely detection and documented response procedures
- DFARS 7012 requires incident reporting within 72 hours of discovery
- cATO requires demonstrated detection and response capabilities as prerequisites for continuous authorization
- SOC 2 CC7.3 evaluates response timeliness relative to the organization's defined objectives
- HIPAA requires breach notification within 60 days of discovery (not 60 days of occurrence)
Board-Level Communication
MTTD and MTTR are concrete, comparable security metrics that translate security operations performance into terms that executives understand. "We detect threats in an average of 4 hours and contain them within 2 hours" is actionable. "We have good security monitoring" is not. These metrics enable quarter-over-quarter trend reporting, peer benchmarking, and investment justification tied to measurable outcomes.
The Contrarian Take: Report the P95, Not the Mean
Here is the opinion that will make your metrics program honest: MTTD measured as an average is a lie --- one 200-day breach hides behind twenty 4-hour detections, and the mean looks beautiful while the organization suffers catastrophic damage from the outlier.
Consider a SOC that detects 20 incidents in a quarter. Nineteen were detected within 4 hours (automated alerts for known-bad indicators). One was detected at 200 days (an adversary using living-off-the-land techniques that blended with normal administrative behavior). The mean MTTD: 13.7 hours. The reality: a critical breach persisted for over six months.
Report the P95 (95th percentile) alongside the mean. The P95 tells leadership: "In 95% of cases, we detect within X hours. In the worst 5%, detection takes Y days." That Y is the number that correlates with catastrophic loss, and it is the number that should drive investment in threat hunting, detection rule development, and advanced analytics. The mean tells you your automation works. The P95 tells you whether your organization is exposed to tail-risk breaches.
How to Calculate
MTTD Calculation
MTTD = Sum of (detection_time - attack_start_time) / number_of_incidents
The challenge is determining "attack start time." This is reconstructed during post-incident forensics by identifying the earliest evidence of adversary activity. For incidents where the start time cannot be precisely determined, use the earliest observed indicator of compromise as an approximation. Be honest about uncertainty --- a range ("compromise began between March 3 and March 7") is more useful than false precision.
MTTR Calculation
MTTR = Sum of (containment_time - detection_time) / number_of_incidents
"Containment" means the attacker can no longer accomplish their objective --- compromised accounts are disabled, affected systems are isolated from the network, malicious code is removed, and persistence mechanisms are eliminated. Containment is not the same as remediation (full recovery to normal operations), which typically takes longer.
Decomposing MTTR
Some organizations further decompose MTTR into sub-metrics that identify specific bottlenecks:
| Sub-metric | Measures | Bottleneck It Reveals |
|---|---|---|
| MTTA (Mean Time to Acknowledge) | Alert generation to analyst triage | Alert volume overload, staffing gaps |
| MTTI (Mean Time to Investigate) | Triage to scope understanding | Tool gaps, analyst skill gaps, poor log coverage |
| MTTC (Mean Time to Contain) | Understanding to containment action | Approval bottlenecks, pre-authorization gaps, tool limitations |
If your MTTR is 6 hours but MTTA is 4 of those hours, the problem is not response capability --- it is alert fatigue or staffing coverage. If MTTI dominates, the problem is investigative tooling or log source gaps. Decomposition tells you where to invest.
Industry Benchmarks
| Metric | Industry Average | Top Performers | Elite (24/7 SOC + automation) |
|---|---|---|---|
| MTTD | 197-207 days | Under 24 hours | Under 1 hour |
| MTTR | 60-73 days | Under 4 hours | Under 30 minutes |
| MTTA | 8-24 hours | Under 15 minutes | Under 2 minutes |
| Total Exposure | 260-280 days | Under 28 hours | Under 90 minutes |
The gap between average and top performers is not incremental --- it is orders of magnitude. Organizations with mature SIEM, EDR, and SOAR deployments that are properly tuned and actively monitored routinely achieve detection in hours and response in minutes. The Colonial Pipeline attack (May 2021) demonstrated the consequences at the other end: the ransomware had been active in the environment before detection, and the response (shutting down the pipeline) caused cascading economic disruption because containment options had not been pre-planned.
Strategies to Improve MTTD
Expand Detection Coverage
You cannot detect what you cannot see. Expanding log sources, deploying detection rules aligned to your ATT&CK coverage map, and closing visibility gaps directly reduces MTTD. The most impactful improvement is usually not a better SIEM --- it is adding the log sources (DNS, process creation, cloud control plane) that make existing rules effective.
Automate Detection
Manual log review cannot scale. A single analyst reviewing logs can process perhaps 50-100 events per hour with meaningful analysis. A production environment generates millions. Automated correlation rules detect threats in seconds that manual review would take hours or days to find --- but only for attack patterns that match rule logic.
Invest in Threat Hunting
Proactive threat hunting finds threats that automated rules miss --- the living-off-the-land techniques, the slow-and-low lateral movement, the insider threats that do not trigger behavioral baselines. Threat hunting is the primary lever for reducing P95 MTTD (the long-dwell outliers that drive catastrophic loss).
Integrate Threat Intelligence
Threat intelligence feeds enable detection of known-bad indicators (IPs, domains, file hashes) that might otherwise go unnoticed. More importantly, tactical intelligence about adversary TTPs enables hypothesis-driven hunts for techniques your automated rules do not cover.
Reduce Alert Noise
Counterintuitively, having too many alerts increases MTTD. When analysts process 500 alerts per shift and 490 are false positives, the 10 real threats get the same 30-second triage as everything else. Reducing false positives through alert tuning directly improves detection time for real threats.
Strategies to Improve MTTR
SOAR Automation
SOAR playbooks automate the first 80% of investigation and response for common incident types: enrich the alert with context, query related systems, correlate with recent activity, assemble the investigation timeline, and present the analyst with a pre-built picture and recommended actions. This reduces MTTR from hours to minutes for high-frequency, well-understood incident types.
Pre-Authorized Containment Actions
Pre-authorize containment actions (isolate host, disable account, block IP, revoke session) so analysts can act immediately without waiting for management approval during critical incidents. The approval that takes 2 hours at 3 AM on Saturday is often the difference between containing a breach to one system and watching it spread to fifty.
Documented Runbooks
Documented incident response procedures for common incident types eliminate decision-making time during active incidents. Analysts should not be designing a response strategy during an active breach --- they should be executing a pre-validated playbook. The Log4Shell response (CVE-2021-44228) demonstrated this: organizations with pre-built "critical vulnerability, active exploitation" runbooks had containment actions in progress within hours. Organizations without runbooks spent days debating scope.
Practice Under Pressure
Regular tabletop exercises and incident simulations build muscle memory so the team executes response procedures under pressure without hesitation. The time to discover that your runbook has a gap is during a drill, not during an active compromise.
Tracking and Reporting
Track MTTD and MTTR monthly and report trends alongside the P95:
| Period | MTTD (Mean) | MTTD (P95) | MTTR (Mean) | MTTR (P95) | Key Action |
|---|---|---|---|---|---|
| Q1 2026 | 12 hours | 14 days | 4 hours | 36 hours | Baseline established |
| Q2 2026 | 8 hours | 6 days | 2 hours | 12 hours | Deployed SOAR playbooks |
| Q3 2026 | 3 hours | 2 days | 45 min | 4 hours | Added EDR correlation + threat hunting |
Downward trends demonstrate security operations investment value. Upward trends signal staffing erosion, detection rule decay, or environmental changes that have outpaced rule updates. A stable mean with a rising P95 indicates that your automation handles known patterns but novel threats are dwelling longer --- a signal to invest in threat hunting.
The Metrics Program Anti-Patterns
Excluding "Hard" Incidents
Some organizations exclude APT-class incidents from their metrics because "those are not representative." This is exactly backward --- those are the incidents that matter most. Include every incident and let the P95 reflect reality.
Starting the Clock at Alert
MTTD starts at compromise, not at the first alert. An alert that fires 3 hours after compromise, is ignored for 2 days, and then re-fires and is triaged has an MTTD of 2 days and 3 hours --- not 3 hours.
Conflating Containment with Remediation
MTTR ends at containment (attacker can no longer advance), not at full remediation (environment restored to known-good state). Mixing the two makes the metric meaningless for operational comparison.
Key Takeaways
- MTTD and MTTR together define your total exposure window --- every day inside that window increases breach cost almost linearly
- Report P95 alongside the mean; the mean hides catastrophic outliers that drive the largest losses
- MTTD improvement comes from detection coverage (log sources + rules) and threat hunting (catches what rules miss)
- MTTR improvement comes from automation (SOAR), pre-authorization (no approval delays), and practiced runbooks
- Decompose MTTR into MTTA/MTTI/MTTC to identify the specific bottleneck before investing
- SEC disclosure rules, DFARS 72-hour reporting, and HIPAA breach notification all create direct regulatory consequences tied to MTTD
Frequently Asked Questions
What is a good MTTD target for a mid-sized organization?
For organizations with a functioning SOC (even if not 24/7): target under 24 hours for mean MTTD and under 7 days for P95. This requires automated detection rules covering your primary threat scenarios, log coverage across authentication/network/endpoint sources, and a triage process that reviews alerts within 4 hours during business hours. Moving from the industry average (197 days) to under 24 hours is achievable with proper SIEM deployment and detection rule tuning --- it does not require a 50-person SOC.
How do I calculate MTTD when I do not know when the attack started?
Use the earliest evidence of adversary activity identified during forensic investigation. This might be the first malicious login, the initial exploitation timestamp in application logs, or the earliest file system artifact. If the true start time cannot be determined within a reasonable range, document the uncertainty and use the conservative (earliest possible) estimate. Precision to the hour is sufficient --- do not agonize over minutes when the measurement error is typically days.
Should I measure MTTD and MTTR per incident severity?
Yes. Reporting a single aggregate number across all severity levels masks important distinctions. Your MTTD for a critical ransomware event (detected by automated behavioral rules in minutes) is meaningless if blended with your MTTD for a low-severity phishing compromise (detected by threat hunt 14 days later). Report by severity tier and by detection method (automated vs. human-discovered) to identify where each investment pays off.
What is the relationship between MTTD and the SEC four-day disclosure rule?
The SEC rule requires disclosure within four business days of determining that an incident is material --- not four days from the incident start. MTTD determines how long before you even know you have an incident to assess for materiality. An organization with a 200-day MTTD is disclosing breaches that have been active for 200+ days, which creates significant legal exposure: plaintiffs can argue the company should have detected sooner, and the stock impact of a "just discovered a breach from 6 months ago" disclosure is worse than a "detected and contained within hours" disclosure.
Can automation alone solve MTTD, or do I need threat hunters?
Automation (detection rules, behavioral analytics) solves MTTD for known attack patterns and obvious deviations from baseline. It does not solve MTTD for novel techniques, living-off-the-land attacks that blend with legitimate admin activity, or insider threats that operate within their authorized access. Threat hunting specifically targets the long-dwell incidents that automation misses --- the P95 outliers. For most organizations, the optimal approach is automation for volume (catches the 95% of incidents that match known patterns) plus periodic threat hunting for tail risk (finds the 5% that drive catastrophic loss).
How Advisedly Helps
Advisedly tracks MTTD and MTTR automatically for every security incident, measuring every stage from initial alert through acknowledgment, investigation, and containment --- then reports mean, median, and P95 broken out by severity, detection method, and incident type. The platform's SOAR playbooks and detection rule library are built to drive both metrics down: automated detection reduces MTTD to minutes for known patterns, and automated response workflows reduce MTTR by eliminating manual triage steps and pre-building investigation context. These metrics feed directly into the TRACE Score, providing continuous visibility into how your operational performance maps to compliance control effectiveness across 500+ frameworks. Contact begin@advisedly.ai to measure, benchmark, and systematically improve your detection and response performance.
<!-- LI hook: Your mean MTTD looks great until you report the P95 where breaches actually cost millions -->