Simple definition
Mean Time to Detect; the average time it takes to identify that a security incident or threat is occurring.
MTTD is only meaningful when teams use consistent definitions for incident start and detection. In many incidents, the true beginning is discovered later during investigation, so measurement should preserve the evidence and assumptions used for each timestamp.
What influences MTTD?
Telemetry coverage
Missing endpoint, identity, network, or cloud data can delay or prevent detection.
Detection logic
High-fidelity analytics identify relevant behavior sooner than broad or noisy rules.
Data latency
Collection, parsing, indexing, and pipeline lag can delay when events are searchable.
Alert triage
A signal may exist quickly but still wait in a queue before analysts recognize its importance.
Enrichment
Asset, identity, and threat context can accelerate recognition of a meaningful threat.
Operating model
Staffing, escalation, automation, and on-call coverage affect when detections become actionable.
Why MTTD matters
- Long detection delays give attackers more time to expand access, move laterally, or affect critical systems.
- MTTD can expose gaps where telemetry arrives late, rules are missing, or alerts wait too long for triage.
- Comparing similar incident classes can help teams decide where engineering effort will reduce detection time most.
- A single organization-wide average can hide important differences between ransomware, identity abuse, cloud threats, and lower-severity events.
- Detection-time metrics should be paired with quality measures so faster alerts do not simply create more false positives.
- Post-incident analysis can use MTTD to connect lessons learned directly to telemetry, detection, and workflow improvements.
How MTTD measurement works
Define measurement boundaries
Document what counts as incident start and what counts as detection for the metric.
Capture timestamps
Preserve event time, alert time, analyst confirmation time, and other relevant milestones.
Calculate elapsed time
Subtract the defined start timestamp from the defined detection timestamp.
Segment the results
Compare MTTD by threat type, severity, detection source, business unit, or telemetry domain.
Find the delay
Determine whether the largest lag came from collection, detection logic, alerting, or triage.
Improve and remeasure
Add telemetry, tune rules, automate enrichment, or change workflows and track the effect over time.
MTTD measurement principles
Start timestamp
Use the earliest defensible evidence of the incident or threat activity.
Detection timestamp
Define whether detection means alert creation, analyst recognition, or another consistent milestone.
Distribution
Review median and percentiles as well as averages because a few long incidents can distort the mean.
Segmentation
Compare like-for-like incident types rather than relying only on one blended number.
Evidence quality
Record how timestamps were established, especially when the start was reconstructed after the fact.
Detection quality
Track false positives and missed detections so lower MTTD does not come from indiscriminate alerting.
Common MTTD use cases
SOC performance
Measure how quickly important threats become visible to analysts.
Detection engineering
Identify use cases where new telemetry or analytics could shorten time to detection.
Incident review
Compare incident start, detection, containment, and recovery milestones.
SIEM optimization
Find ingestion or scheduled-query latency that delays alert creation.
XDR operations
Measure detection speed across endpoint, identity, email, and cloud signals.
Coverage analysis
Use long or missing detection times to identify high-value detection gaps.
MTTD vs MTTR vs Detection Rule
| Concept | Primary purpose | Example |
|---|---|---|
| MTTD | Measure how long it takes to identify a threat or incident. | Malicious activity begins at 10:00 and is detected at 10:20, producing a 20-minute detection time. |
| MTTR | Measure how long response or remediation takes according to the organization’s chosen definition. | The incident is detected at 10:20 and resolved at 12:00. |
| Detection Rule | Define the logic that identifies suspicious activity. | A query alerts on a suspicious credential-use pattern. |
Key technical considerations
Normalize timestamps
Event, ingestion, alert, and analyst timestamps can use different clocks and time zones.
Automate milestones
Capture detection and workflow timestamps automatically where possible instead of relying on manual notes.
Include missed cases
An incident discovered by an external party or later review should not disappear from metric analysis.
Define scope
Specify which incident severities, teams, and threat types are included in each report.
Use trends
Track movement over time instead of treating one monthly average as the whole story.
Find root causes
Use the metric to identify specific detection or workflow delays rather than rewarding faster numbers alone.
Benefits and common problems
Benefits
- Quantifies detection delay.
- Highlights telemetry and rule gaps.
- Supports post-incident improvement.
- Provides a common SOC trend metric.
- Helps prioritize detection-engineering investment.
Common problems
- Start time is guessed inconsistently.
- Alert creation is confused with analyst recognition.
- One mean hides very different incident types.
- Faster but noisier detections appear better.
- Externally discovered incidents are excluded.
How ForshTec helps improve MTTD
ForshTec helps security teams connect telemetry, log pipelines, detection logic, enrichment, alert triage, and SecOps workflow so detection delays can be measured and reduced at their real source.
- Telemetry and data-source gap analysis
- Detection engineering and tuning
- SIEM pipeline latency analysis
- Alert enrichment and triage automation
- ATT&CK coverage and detection-gap analysis
- Incident metric instrumentation and reporting
Need to know why important threats are detected late?
ForshTec can trace detection delay from source telemetry through SIEM analytics and analyst workflow, then target the controls that reduce it.
Talk to ForshTecFAQs
What does MTTD stand for?
MTTD stands for Mean Time to Detect.
How is MTTD calculated?
For each incident, subtract the defined incident-start timestamp from the defined detection timestamp, then aggregate comparable incidents using the organization’s chosen statistic.
What counts as the detection time?
Organizations should define this explicitly. It may be alert creation, analyst recognition, case creation, or another milestone, but the definition should stay consistent.
Is lower MTTD always better?
Generally yes, but the metric should be considered alongside false positives, missed detections, and incident severity so speed does not replace detection quality.
How can MTTD be improved?
Improve telemetry coverage, reduce pipeline latency, build higher-fidelity detections, automate enrichment, and shorten alert-triage delays.
Why can MTTD be difficult to measure?
The true incident start is often discovered after the fact, and different systems may record different timestamps.