MTTD Measurement in the SOC: A Forced-Choice Framework for the Metric That Means Different Things to Everyone
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Mean Time to Detect is the metric every SOC director tracks and every board slide includes. It is also the metric with the least consensus definition in the industry. Prophet Security's 2025 analysis identified four distinct definitions actively in use across SOC programs: MTTD measured from first telemetry signal, from alert generation, from analyst acknowledgment, or from confirmed true positive. These are not minor variations. On the same incident, these definitions can produce detection times that differ by orders of magnitude. A breach where an EDR agent generated a telemetry event at 2:00 AM, a SIEM alert fired at 2:45 AM, an analyst opened the alert at 9:00 AM, and the SOC confirmed a true positive at 10:30 AM produces four different MTTD values: 8.5 hours, 7.75 hours, 1.5 hours, or 0 hours depending on which definition you use. The measurement choice is not neutral. It drives investment decisions, vendor evaluations, and board-level reporting. This guide gives practitioners a forced choice: pick one definition, understand what it measures, and know what it cannot tell you.
The Four Definitions Side by Side
The four MTTD definitions in active use differ on a single variable: what counts as the start of the detection clock. Each definition measures something real and meaningful. The problem is using them interchangeably or comparing your MTTD number to an industry benchmark without verifying that the same definition was used.
Definition 1: From First Telemetry Signal
The clock starts when the first data source records an event associated with the attack. This is the broadest definition and produces the longest MTTD numbers. It measures the total time from when the attack became detectable to when a human confirmed it. This definition captures coverage gaps (if the telemetry event was never surfaced to an analyst) and detection logic gaps (if the event was collected but no rule fired). Weakness: this requires retroactive analysis to identify the first relevant telemetry event, which is only possible after the incident is confirmed.
Definition 2: From Alert Generation
The clock starts when the SIEM or detection platform generates an alert. This is the most commonly used definition and measures the time from automated detection to human response. It captures alert backlog problems and shift-handoff delays. Weakness: it does not capture the gap between when an attack became detectable in telemetry and when your detection rules actually fired. An attack can be in your environment for days before the rule that fires was created.
Definition 3: From Analyst Acknowledgment
The clock starts when an analyst opens or acknowledges the alert in the SIEM or SOAR platform. This measures analyst response time to generated alerts. It is the definition most sensitive to queue depth and staffing levels. A well-staffed SOC with fast alert triage can show excellent numbers on this definition even with poor detection coverage. Weakness: it measures analyst velocity, not detection quality.
Definition 4: From Confirmed True Positive
The clock starts when the incident is confirmed as a real threat, and measures time from that confirmation to containment. This is not a detection metric at all; it is a response metric mislabeled as detection. Using this definition inflates MTTD favorably by excluding the time spent determining whether an alert is real. Weakness: it eliminates the most operationally significant part of the detection timeline.
A Real Incident with Four Different MTTD Numbers
Consider a lateral movement incident. An attacker compromises a service account at 11:00 PM Tuesday. The EDR agent records an unusual process execution at 11:04 PM (first telemetry). The SIEM fires a lateral movement alert at 11:47 PM (alert generation). An analyst opens the alert at 8:15 AM Wednesday (analyst acknowledgment). The SOC confirms a true positive and escalates at 9:30 AM Wednesday. The four MTTD values for this single incident are: 10 hours 26 minutes (Definition 1), 9 hours 43 minutes (Definition 2), 1 hour 15 minutes (Definition 3), and 0 minutes (Definition 4 does not apply here because MTTD would be measured from confirmation to containment). The ratio between the longest and shortest meaningful definitions is approximately 8:1. At scale across hundreds of incidents, programs using Definition 2 will consistently report numbers 6-10x longer than programs using Definition 3 on otherwise identical operations. Vendor MTTD benchmarks are meaningless without knowing which definition was used.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Which Definition to Use: A Forced Choice
The right definition depends on what problem you are trying to solve. There is no universally correct choice, but there is a decision framework.
Use Definition 1 if you want to find coverage gaps
Measuring from first telemetry signal tells you how much attack activity was occurring in your environment before any alert fired. The gap between Definition 1 and Definition 2 is your detection logic gap: attacks that were generating data but not generating alerts. This definition requires retroactive incident analysis and cannot be measured in real time. It is best used as a periodic audit metric on confirmed incidents.
Use Definition 2 if you want to measure detection-to-response latency
Measuring from alert generation tells you how long generated alerts sit in the queue before an analyst engages. This is the most operationally actionable definition for SOC management because it can be improved through staffing, automation, and queue management. It is also the most comparable definition when evaluating detection tools, because it measures what the tool produces against what your team processes.
Use Definition 3 sparingly and only for analyst efficiency measurement
Measuring from analyst acknowledgment is appropriate only when the specific question is: how quickly do analysts respond once they open an alert? This is a sub-metric of response efficiency, not a detection metric. If your board slide uses Definition 3 as your MTTD, you are underreporting detection latency. Definition 3 should never be used as the organization-level MTTD figure.
What MTTD Can Tell You
Regardless of which definition you select, MTTD is a useful operational metric with specific diagnostic capabilities.
Detection velocity trends
Month-over-month MTTD trends reveal whether your detection program is improving or degrading. A consistent definition applied over time produces a reliable trend signal. MTTD is most valuable as a trending metric, not as an absolute number to compare against industry benchmarks.
Alert quality signals
MTTD broken down by alert source (EDR vs. SIEM vs. NDR) reveals which tools generate alerts that get investigated quickly versus alerts that sit in queues. Alerts from tools with high false-positive rates accumulate analyst fatigue and produce longer MTTD numbers even when the underlying threat was detected promptly.
Coverage gap identification
Comparing Definition 1 MTTD to Definition 2 MTTD on confirmed incidents reveals the detection logic gap. If the average incident produced telemetry 4 hours before an alert fired, you have a 4-hour detection logic gap that new rules or better coverage could close.
What MTTD Cannot Tell You
MTTD has structural limitations that no measurement refinement can address. Security teams and boards that treat MTTD as a comprehensive security effectiveness metric will make investment errors based on what it cannot measure.
Whether you caught the incidents that mattered
MTTD measures detection time on incidents that were eventually detected. It says nothing about the incidents that were never detected. A SOC with excellent MTTD on detected incidents can have massive blind spots in attack techniques that fall outside existing detection coverage. IBM's finding that the median breach takes 158 days to identify reflects incidents that were eventually detected; it excludes breaches that have not yet been found.
Whether attackers are still present
A confirmed and closed incident with a favorable MTTD does not indicate the threat actor has been fully evicted. Attackers routinely establish multiple persistence mechanisms. MTTD measures the time to detect a specific indicator; it does not measure comprehensive threat actor eviction. Post-incident forensics, not MTTD, addresses persistence.
Detection program completeness
A low MTTD number can reflect excellent detection or a narrow attack surface. An organization that has only deployed workstation EDR and has no coverage on servers, cloud workloads, or network traffic can report fast MTTD on the alerts it generates while being completely blind to attacks in uncovered environments.
The Benchmark Problem: Why Vendor MTTD Numbers Are Not Comparable
Every security vendor publishes MTTD benchmarks. These numbers are used in sales cycles, board presentations, and analyst reports. They are almost universally incomparable because the definition used is rarely disclosed. A vendor claiming median MTTD of 4 minutes is using Definition 3 (analyst acknowledgment in their managed service) applied to a customer base where they pre-filter alerts before presenting to analysts. An enterprise SOC using Definition 2 across all telemetry sources will report a number that looks 50x worse but may represent more complete and honest measurement. Before accepting any MTTD benchmark, require disclosure of: the definition used, whether managed service analyst time is included or excluded, and whether the sample includes only confirmed true positives or all alerts.
How to Report MTTD Honestly to a Board
Board MTTD reporting should include three elements: the definition used, the trend over time, and the known limitations. A complete board-level MTTD statement reads approximately as follows: 'Our MTTD, measured from alert generation to analyst acknowledgment, improved from a 4-hour median to a 47-minute median over the past two quarters, driven by SOAR automation that routes high-confidence alerts directly to on-call analysts. This metric measures response speed on alerts our tools generate. It does not measure the time between an attack becoming detectable in telemetry and our detection rules firing, which we track separately as detection logic gap.' This framing is more complex than a single number on a slide, but it is accurate and it demonstrates SOC maturity rather than obscuring it.
The bottom line
MTTD is worth measuring. It is not worth trusting without knowing exactly what was measured. The 67% of SOC programs with inconsistent MTTD definitions are not making better decisions because they track the metric; they are making decisions based on a number that changes meaning across quarters, across analysts, and across vendors. Choose one definition, document it, apply it consistently, and track the trend. The absolute number is almost meaningless; the direction over time is diagnostic.
Frequently asked questions
What is the industry standard definition of MTTD?
There is no single industry-standard definition. Prophet Security's 2025 analysis documented four definitions in active use simultaneously. The most commonly cited definition in vendor benchmarks measures from alert generation to analyst acknowledgment (Definition 3 in this guide), which is the most favorable to report. For operational SOC improvement, measuring from alert generation to confirmed true positive (Definition 2) provides more actionable data about detection latency.
How does IBM's 158-day median breach identification time relate to SOC MTTD?
IBM's figure measures from initial compromise to organizational identification across all breaches in their dataset, including those involving no security tooling at all. This is closest to Definition 1 (from first detectable indicator) and includes many incidents where no SOC was operating or where initial access occurred through channels outside deployed detection coverage. SOC MTTD benchmarks, which measure response to generated alerts, are not directly comparable to IBM's figure. The IBM number is best used to frame the scope of undetected attack exposure in the industry broadly.
Can MTTD be gamed, and does that matter?
Yes, MTTD can be improved by selecting a favorable definition (Definition 3), auto-acknowledging alerts, or narrowing the detection scope to high-confidence alerts that get fast responses. Whether this matters depends on why you are measuring it. If MTTD is used for internal operational improvement, gaming it defeats the purpose. If it is a vendor SLA metric, the contractual definition controls and gaming is bounded by the contract. If it is a board reporting metric, gaming it erodes the board's ability to make informed security investment decisions.
What is a realistic MTTD target for an enterprise SOC?
SANS data shows top-quartile SOCs detect threats in under 60 minutes using Definition 2 (alert generation to analyst response). Median enterprise SOCs operate in the 4-8 hour range on the same definition. Targets should be set against your own baseline trend rather than industry benchmarks, because the benchmark variation from definition inconsistency makes external comparison unreliable. A realistic 12-month improvement goal for a mature SOC is reducing median MTTD (Definition 2) by 40-60% through SOAR automation and alert quality improvement.
How does MTTD relate to MTTA and MTTR?
MTTD (Mean Time to Detect), MTTA (Mean Time to Acknowledge), and MTTR (Mean Time to Respond or Recover) are sequential metrics covering the incident lifecycle. MTTD ends when the threat is detected. MTTA measures from detection to analyst action. MTTR measures from detection or acknowledgment to resolution. The confusion between MTTD and MTTA is responsible for much of the definition inconsistency: Definition 3 (from alert generation to analyst acknowledgment) is technically measuring MTTA, not MTTD, but is frequently labeled as MTTD in vendor reporting.
How should MTTD be broken down for operational improvement?
The highest-value breakdown is by alert source and attack technique. MTTD by alert source identifies which tools are generating actionable alerts quickly and which are generating noise that sits in queues. MTTD by attack technique (using MITRE ATT&CK phase) reveals whether your detection program has systematic gaps in specific phases, such as slow detection of persistence or lateral movement compared to initial access. These breakdowns are more operationally useful than the aggregate MTTD number.
What should we tell a board when MTTD gets worse?
A worsening MTTD trend is most commonly caused by one of three things: increased alert volume from new detection coverage (more coverage creates more alerts that take longer to process on average), staffing changes, or a shift in attack technique mix toward techniques that take longer to confirm. A board presentation showing worsening MTTD should include the causal analysis. Increased MTTD caused by expanded detection coverage is a sign of program maturity, not degradation, and boards can understand this with appropriate context.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.