Security teams measure a lot of things. Alert volume, escalation rate, analyst utilization, time-to-close. The metric that most commonly appears on security dashboards as a headline performance indicator is mean time to respond, MTTR. How quickly, from the moment a case is opened, does the team close it? It is a reasonable measure of process efficiency. It is the wrong thing to optimize first.
Mean time to detect, MTTD, is the interval between when an attacker first has meaningful access in your environment and when your detection system generates an alert. This is the number that determines how much damage gets done before you know anything is wrong. Responding in two hours to an alert that fires fourteen days after initial compromise is worse than responding in four hours to an alert that fires in forty minutes. The math on attacker dwell time is unforgiving: every hour of dwell is more data accessed, more credentials harvested, more lateral movement completed.
Why MTTD gets less attention than it deserves
The problem is that MTTD is harder to measure and harder to improve than MTTR. MTTR improvement is largely a process problem: better ticketing workflows, better escalation paths, clearer runbooks, faster analyst onboarding. Meaningful gains are achievable in weeks through process changes alone. MTTD improvement is a detection engineering problem, and it requires understanding why alerts are arriving late, which often requires knowing what attacks you missed entirely until a retrospective showed you the evidence was there.
There's also a measurement problem. MTTR starts when a case opens. But MTTD starts when an attacker gains access, and you often only know that timestamp if you reconstruct the incident from evidence afterward. This makes MTTD hard to track in real time. Most teams approximate it from retrospective analysis of confirmed incidents, which is a reasonable approach but means the metric lags the current state of your detection by months.
The three drivers of detection latency
MTTD has three components, and they need to be addressed separately because the causes and fixes are different for each.
The first is log collection latency. If your CloudTrail logs take 15 minutes to arrive in your SIEM after the event occurs, then any detection built on those logs has a minimum 15-minute floor on MTTD. This is often treated as an infrastructure constant, but it isn't. Log delivery latency can be reduced through collection architecture choices: direct Kinesis streaming versus S3 polling, event-driven ingestion versus scheduled batch imports. In multi-account environments with hub-and-spoke logging architectures, the added hop for log aggregation can add 10 to 20 minutes that most teams accept as given when it's actually addressable.
The second is rule coverage gap. If you don't have a detection rule for a technique, the MTTD for that technique is infinite: you never detect it in real time. Coverage gaps are the largest contributor to MTTD in most environments. The MITRE ATT&CK framework is useful here not just as a labeling system but as a coverage audit tool. A systematic pass through the cloud matrix (IaaS and SaaS) comparing each technique to your existing rule set reveals where you have gaps. Those gaps are places where an attacker can operate for as long as they want with no detection clock running.
The third is alert suppression and tuning logic. This is the component that most teams manage aggressively and most consistently manage incorrectly. When a detection rule generates too many false positives, the common response is to tune it by adding suppression logic: exclude this account, exclude this time window, exclude this source IP. Each suppression reduces noise. Each suppression also creates a bypass path. An attacker who knows your environment can operate within your suppression boundaries indefinitely. The better approach is to fix the signal, not add noise suppression: understanding why the rule fires on benign activity and adjusting the detection logic so it targets the behavior you actually care about rather than a proxy that happens to correlate with it.
What a practical MTTD reduction program looks like
Start with coverage, not tuning. Map your rule set to ATT&CK techniques and identify the top-10 techniques by attack campaign frequency in your industry that you have no real-time detection for. Build rules for those first, even imperfect rules that generate some false positives. A rule that fires too often is better than no rule, because at least the dwell clock starts running when an attacker uses that technique.
Then address collection latency. Audit your ingestion pipeline for each critical log source. If your authentication logs take 20 minutes to arrive, you have a 20-minute floor on detecting credential-based attacks. That floor can often be cut to 2 minutes with architecture changes.
Finally, improve your tuning discipline. Stop suppressing by entity (this account, this IP) and start suppressing by context (this account doing this action with this result is benign; the same account doing this action on a different resource class is not). Context-aware suppression reduces false positives without creating the bypass surface that entity-based suppression creates.
MTTD improvement is slower than MTTR improvement. A serious program takes six to twelve months to show significant gains. But the return on investment is much higher, because every minute you remove from detection latency is a minute less that attackers can operate undetected in your environment. Response speed only matters if you detected the incident. Detection latency determines whether you get the chance to respond at all.