Mean Time to Detect Starts Its Clock After the Interesting Part Is Over

Ask a security team what their mean time to detect is and you will usually get an answer with two decimal places. Ask what event the clock starts on and the answer takes longer, because the platform picked it rather than anyone deciding. In most tooling the clock starts when a matching signal reached the detection pipeline. Everything that happened before that moment, including the whole period where the attacker was active and nothing was watching, sits outside the measurement.

That is not a rounding problem. It is a measurement of the wrong interval. A number that starts after the log arrived tells you how quickly your queue moves. It says nothing about how long someone was inside, which is the question the metric exists to answer and the question every board asking for it believes it is asking.

Four clocks, and reports usually pick the third

There are four candidate start points for any intrusion, and they can be weeks apart.

The first is when the attacker acted: the initial access, the first credential used, the first command run. This is the only start point that measures your exposure, and it is knowable only in hindsight, usually during the investigation.

The second is when an observable artefact was created somewhere in your estate. A process was spawned, an authentication succeeded from an unusual client, an object was read. The event existed on the host or in the service audit trail whether or not anything collected it.

The third is when a signal reached your detection platform. This is where the reported clock nearly always starts, and it is the moment shaped by collection scope, agent coverage, ingest lag, and whatever was excluded to control the bill.

The fourth is when an alert was created and assigned. Some teams measure from here, which reduces MTTD to a queue latency figure and nothing more.

Clock starts at	What it actually measures	What it hides
Attacker action	True dwell time, your real exposure	Nothing, but it is only knowable retrospectively
Artefact created on host or service	Detectable window, given perfect collection	Gaps where nothing generated evidence at all
Signal arrived in the platform	Pipeline and triage performance	Every hour spent outside your collection scope
Alert created and assigned	Queue latency	Detection quality entirely

The distance between the first two rows and the third is the part of an intrusion you had no ability to see. It is also the part that grows when collection is trimmed, and it is invisible in every dashboard that starts at row three.

The metric moves the wrong way when you improve

This is the failure mode that convinces teams the number is trustworthy, because it looks like the metric is behaving.

Enable a new detection with retrospective search, and you may surface activity that began three weeks ago. Handled honestly, that single incident has a dwell time of three weeks, and the mean for the quarter deteriorates sharply. The team just got materially better at detection and the metric punished them for it. Handled the usual way, the clock starts when the new rule first matched, the incident records a dwell time of minutes, and the mean improves. The improvement is an artefact of when the rule was switched on.

Now run it in reverse. Drop a noisy log source to control ingest cost. Every intrusion that would have been caught slowly through that source is no longer caught at all, so it never enters the numerator. The incidents you do detect are the fast, loud ones. The mean improves. You have made yourself less able to see, and the metric issued a commendation.

Any measure that improves when coverage shrinks and worsens when coverage grows is not measuring detection. It is measuring the shape of your collection, and the direction of travel is inverted. There is more on how the definition gets chosen, and what to substitute, in our guide on how mean time to detect gets measured wrong.

The denominator is worse than the numerator

Every MTTD figure is calculated over incidents you detected. Undetected intrusions are absent by construction, and there is no correction available for that, because you cannot average over things you never saw.

This makes the metric structurally optimistic in a way that gets worse as your detection gets worse. A team detecting only the obvious cases will report an excellent MTTD, since obvious cases are found quickly. A team detecting subtle, long-running intrusions reports a poor one, because subtle intrusions are found late by definition. The number rewards the first team.

Two things partly compensate, and neither is a mean.

The first is source of detection. Count how many incidents were found by your own detections against how many arrived from an external party: a customer, a supplier, a payment processor, law enforcement, or a third party notification. That ratio is hard to game and it is the single most informative detection figure most organisations do not track. Every externally-reported incident is a direct statement about your coverage.

The second is per-incident dwell time reconstructed after the fact, reported as a distribution rather than an average. Incident timelines are heavily skewed; a handful of long intrusions carry all the risk and a mean flattens them into the crowd of minor cases. The median and the worst case together are more useful than any average, and the worst case is the number worth arguing about.

Rebuilding the clock so it means something

This is retrospective work and it belongs in the incident review, not in a live dashboard.

1. For each closed incident, establish the earliest confirmed attacker action from the investigation timeline, not from the alert record. This is the true start.
2. Record the earliest artefact you could have observed, and whether it was in scope for collection at the time. The gap between action and observable artefact is a visibility gap, and it is a different problem from a triage gap.
3. Record when a signal actually reached the platform, and why it was not earlier: agent not installed, source excluded, ingest lag, sampling, or the event genuinely did not exist.
4. Record when a human first acted. The distance between signal arrival and human action is the only part of the interval that better triage capacity can fix.
5. Report the four intervals separately. Each has a different owner: architecture, collection, engineering, and operations. Collapsing them into one number tells no owner anything actionable.

Step two usually produces the largest surprise, because the visibility gap is where most real dwell time lives and it is nobody's metric. Deciding what to collect so that the gap is deliberate rather than accidental is the same exercise as deciding what to drop, which we work through in our guide on what to log and what to stop logging.

Step four is where the honest version of the number gets awkward, because human action time is largely set by queue volume rather than by skill. If your analysts are triaging past their capacity, signal arrival to human action stretches for reasons that have nothing to do with detection quality, and our guide on why adding more alerts makes detection worse explains the mechanism.

What to do next

Take your three most recent incidents and rebuild all four timestamps by hand. It is an afternoon of work and it will tell you whether your reported MTTD describes exposure or queue latency. If the two figures differ by more than a factor of two, the reported one should stop appearing in governance packs without the breakdown beside it.

Then change what you report: source of detection as a ratio, dwell time as a distribution with the worst case named, and the four intervals attributed to their owners. If you want the reconstruction done against your own incident history rather than a template, that is where our threat detection and response practice starts.