After a tabletop exercise, the security team of a manufacturing company gets a question from the board: “how long does it take us to detect a break-in?”. The answer is “a few dozen minutes on average” — taken from the console, where that is indeed the time from event to alert. Three months later, in a real case, the post-incident analysis traces the first login with a stolen account to eleven days before the first alert. Both figures are true. They simply measure two different things.
MTTD (mean time to detect) falls not because of a faster tool but because you remove the places where the clock stands still. This text is not a survey of security operations metrics — the definitions, the formulas and the way to report them are covered separately in the article on SOC metrics: MTTD, MTTR and security KPIs. One thing interests us here: breaking detection time into segments and showing which lever works on which one.
From which moment does the MTTD clock actually run?
From the attacker’s first activity, not from the first alert — and that is the most frequently confused boundary in the whole measurement. The console shows the gap between a recorded event and a generated alert, because those are the only two points that exist inside it. Everything that happened before the first recorded event is invisible to the tool and by definition does not enter the calculation.
A sensible split of the route looks like this: (1) time until a signal appears in the telemetry, (2) time until the signal becomes an alert, (3) time until a human picks the alert up, (4) time until the decision that this is an incident and what is to be done about it. The sum of those four segments is what the board understands as “time to detect”. The console measures the second one.
NIST puts this problem plainly in its incident response recommendations. The document SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025), notes under the DE.AE category that “Signs of an incident may be more obvious later in the attack life cycle, but the incident’s impact and scope may be much larger”, and recommends that organisations strive to find incidents earlier in that life cycle.
The distinction that matters: “time to detect” from the console is processing time. The “time to detect” the board is asking about is exposure time. As long as both figures carry the same name, every conversation about improvement concerns a different quantity for each person in the room.
Why does a faster correlation engine shorten the shortest leg of the route?
Because it works exclusively on the second segment, and in most organisations that one is already the shortest. Turning an event into an alert is counted in seconds and minutes — even on a loaded system we are talking about single-digit minutes. Segments one, three and four are counted in hours, and with a missing data source or a queue without duty cover, in days.
The arithmetic here is merciless and worth doing before you talk to a vendor. If the route looks like this — four hours until the signal appears (the log arrives in batches every few hours), two minutes until the alert, fourteen hours in the queue until Monday morning, three hours until consent to isolate — then halving the correlation changes a total of over twenty hours by one minute. A new licence improves that result by a fraction of a percent.
This is not an argument against tools. It is an argument for measuring the segments separately before a purchasing decision is taken. Only a route broken into parts shows where the time actually sits — and only then does it become visible that in a fair share of organisations the single largest component is waiting for a human, not processing data.
How much does a log source we do not collect add to time to detect?
It adds as long as it takes the attacker to reach a system we happen to be logging — an amount with no upper bound. A missing data source does not slow detection down; it moves it to a different, later moment in the attack cycle. If we do not collect authentication events from the cloud console, the takeover of an administrative account will not generate any delayed alert — it will generate an alert only once the attacker touches something we can see.
The monitoring scope this depends on is listed specifically by NIST under the DE.CM category: networks and network services (DE.CM-01), the physical environment (DE.CM-02), personnel activity and technology usage (DE.CM-03), the activities and services of external service providers (DE.CM-06), and computing hardware, software and runtime environments together with their data (DE.CM-09). Under DE.CM-06 the document explicitly names “remote and on-site administration and maintenance activities that providers perform on organizational systems” — the area most often absent from a log source inventory.
The other side of the same equation is retention. CIS Critical Security Control 8 is titled Audit Log Management and comes down to a single instruction: “Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack” (Center for Internet Security, description of Control 8). The last verb decides whether a detection made two weeks later will have anything to stand on. A log deleted after seven days does not lengthen MTTD — it makes it impossible to calculate backwards.
How do you check what your detections cannot see before an attacker checks it?
By laying your own list of detections against a public catalogue of techniques, rather than asking “do we have good rules”. MITRE ATT&CK is that catalogue today and — importantly for this exercise — it has recently rebuilt precisely the detection layer. The Data Sources page carries a note that data sources were deprecated in the v18 release of October 2025 and will no longer be developed; their role has been taken over by detection strategies and analytics.
The scale is verifiable in a minute. The ATT&CK catalogue lists 918 detection strategies and 2,066 analytics — figures read from attack.mitre.org/detectionstrategies/ and attack.mitre.org/analytics/ on 18 September 2026. An analytic is concrete detection logic for a given platform; a strategy is a container that binds several analytics into one method of detecting a technique.
The exercise for your own team looks like this: take the ten techniques most often used in attacks on your industry, check in the catalogue which events their detection requires, and confront that list with the inventory of sources that actually reach your system. The difference is a map of what you will not detect in any amount of time — because time to detect something invisible is not long. It does not exist.
A practical card: before you ask “how fast do we detect”, ask “what are we able to detect at all”. The first question only makes sense once the second one has an answer in the form of a list rather than a declaration.
Why does tuning false alarms shorten detection even though it reduces the number of alerts?
Because MTTD depends on the time it takes to reach a true alert, not on the number of alerts in the queue. A rule producing dozens of hits a day, almost all of them harmless, adds no detection capability — it adds work that pushes back the moment somebody deals with the hit that matters. In a queue handled by a finite number of people, every false alarm is a delay imposed on all the others.
NIST describes this mechanism from the design side. Under the DE.AE category it recommends that organisations “rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis”, and under DE.CM that monitoring technologies be tuned to bring false positives and false negatives down to acceptable levels. The word “acceptable” is a decision of the organisation here, not a vendor setting.
Tuning does have a price that is discussed less often: every rule switched off moves part of the risk into the category “we do not detect this”. That is why two figures have to be kept together — the share of true hits among a given rule’s alerts, and the technique that rule was supposed to cover. Switching a rule off without recording the second of those improves MTTD and worsens security at the same time, and the report will show only the first.
What happens to an alert that reaches the queue on a Friday after five?
In an organisation with no duty cover it waits until Monday — and that waiting enters MTTD in full. This is usually the single largest component of time to detect in companies that have monitoring deployed and no staffing outside office hours. The alert was produced in a minute and picked up after sixty hours.
The consequence runs deeper than the gap itself. An alert that is generated and delivered to nobody meets half the requirement and fails the other half: under DE.AE-06 NIST demands that information about an event reach authorised tools and staff, and that log analysis findings be accessible to incident responders at all times. A team mailbox read during office hours does not meet that requirement, even though in post-deployment documentation it looks identical to meeting it.
We develop the same thread from another angle in the text on why a SIEM without a SOC does not work — there the question is “what the tool will not do on its own”, here we measure how much each of those missing things costs in time. If you are considering closing that gap without building an in-house team, the comparison of routes is set out in the article on SOC as a service for mid-sized companies; the duty and monitoring service itself we run as nFlo SOC 24/7.
Why does the order of handling alerts change MTTD more than the number of analysts?
Because with finite resources it is the selection rule, not throughput, that decides how long it takes to reach the alert that matters. Adding a person to the team shortens the queue proportionally; changing the order of handling can move a specific alert from the end of the queue to its front, which is the whole of its processing time.
NIST frames this as a recommendation rather than a suggestion: “Because of resource limitations, incidents should not be handled on a first-come, first-served basis”. The same passage calls risk evaluation and applying the appropriate prioritisation “perhaps the most critical decision points in the incident response process”.
The inputs to prioritisation are listed by the document under RS.MA-03: the scope of the event, its likely impact, its time-critical nature and resource availability. Three of those four quantities do not come from the security system — they come from a service register, a map of business dependencies and a duty roster. The absence of any of those registers sends the queue back to the order of arrival, whatever the procedure says.
How much time is eaten by waiting for a decision rather than by the analysis itself?
In organisations with an elaborate approval chain, more than the analysis — and it is the cheapest segment to shorten. Analysis requires competence and data; consent requires only that somebody answers the phone and has the right to say yes. If isolating a workstation requires the system owner’s approval, and there is one owner who works days, then a night-time detection has its closing time fixed in advance.
NIST distinguishes here between two things that blur together in practice. Under RS.MA-04 it describes escalation as increasing resources or time frames, and elevation as involving a higher level of management. The first operation shortens time, the second usually lengthens it — and that is the reason to have it written down which decisions require escalation only.
The practical closure is to write out the reversible actions — isolating a workstation, blocking an account, cutting a session — and grant the first line the authority to perform them without asking. The risk of a false cut-off is real, but measurable and reversible, while the risk of waiting six hours for consent tends to be one-off and irreversible. This is the only change on the list that costs neither a licence nor a headcount.
How do you measure your own MTTD without knowing time zero?
By accepting that the measurement has two stages, and by naming explicitly which stage is being reported. Stage one is the time from the first event in the telemetry to confirmation of the incident — a figure available immediately and systematically understated. Stage two is the time from the actual start of the attacker’s activity, established in the post-incident analysis — the true figure, available weeks later.
Either one without the other misleads in a predictable way. Reporting stage one alone produces a result that improves after every difficult detection you switch off. Reporting stage two alone produces a figure that cannot be used operationally, because it arrives after the case is closed. At nFlo we run both at a client site: the live counter from the system as an operational signal, and a backward recalculation after every closed case, with the difference between them written down — because it is precisely that difference which shows how much of an attack is spent beyond the reach of the telemetry being collected.
Three rules of calculation, without which the metric is not fit for comparison over time: the median rather than the mean (one incident found months later blows up a mean taken from a dozen cases), a split by class of detection (antivirus alerts and behavioural detections are two different populations), and publishing the number of cases alongside the result. A metric with no case count is an opinion written as a figure. A broader set of measures for the incident handling process is covered in the text on incident management.
Which levers for reducing MTTD give the most, and what does each of them cost?
The table below orders the four segments of the route by what shortens them and what you need in place to see the change in figures at all. The “evidence of change” column matters most here: a lever whose effect cannot be shown in a measurement is not fit for justifying a budget.
| Segment of the route | Lever that shortens it | Cost of implementation | Evidence of change in measurement |
|---|---|---|---|
| To the signal appearing | Closing log sources per DE.CM-01…09, shortening the data ingestion interval, extending retention | Volume licensing, integration engineer’s time | Source inventory before and after, set against the technique list from the ATT&CK catalogue |
| To the signal becoming an alert | Rule maintenance, tuning of false alarms, withdrawal of rules with the worst hit ratio | A standing slot in the team calendar, no purchase | Share of true hits per rule, calculated in monthly windows |
| To a human picking the alert up | Duty cover outside office hours, a named owner per alert category, tickets created automatically | In-house staffing or an external service | Distribution of queue waiting time, separately for day and night |
| To the decision | A runbook listing reversible actions, first-line authority, separating escalation from elevation | An organisational decision, zero tooling cost | Time from picking the alert up to the first containing action |
It is worth noting which column holds the zeros. Two of the four segments are shortened without buying anything — by maintaining what already works and by handing out authority. Those are usually also the two that nobody submits as a project, because they have no vendor to propose them.
Where do you start if you want to see a change within a quarter?
With measuring the route, not with buying a lever. Take the three most recent closed cases — they may be false alarms, as long as they went through the whole path — and write out four timestamps for each: the first event in the telemetry, the creation of the alert, a human picking the alert up, and the first containing action. Three cases are enough to see which segment dominates; we are not doing statistics at this stage.
Then run one coverage exercise: ten techniques relevant to your industry, the events their detection requires, confronted with the inventory of sources actually collected. That closes the question “what will we not see in any amount of time”, which measuring the route on its own does not ask.
A practical card to start with: if writing out three cases shows that segment three — waiting for a human — is longer than the sum of the others, then your next tooling purchase will not change your MTTD. What will change it is settling who picks up an alert at three in the morning and what they are allowed to do without asking.
One limitation of this metric is worth writing down at the end, so that it does not become an end in itself. MTTD measures the road travelled by the events we detected. It says nothing about the events we did not — and no value of it, however good, is evidence that nothing is happening in the environment that we cannot see. That is why it is always reported alongside technique coverage, and why the conversation about shortening it starts with the question of what reaches the telemetry in the first place.
Frequently asked questions
From which moment does time to detect an incident run?
Formally from the attacker's first activity in the environment, and in practice from the first event that was recorded in the telemetry you collect. That difference is the whole problem of measuring MTTD: we do not know time zero at the moment of detection, we learn it only in the post-incident analysis. A value of MTTD calculated on the fly is therefore always understated against reality and has to be recalculated backwards once the case is closed.
What lengthens MTTD the most — tools or process?
In a typical arrangement the process, and for a simple arithmetical reason. The segment where the tool works — turning an event into an alert — is counted in seconds and minutes. The process segments, namely an alert waiting in a queue with no duty cover, escalation to a person with authority, and consent to act, are counted in hours and days. Halving a segment measured in minutes does not move a total measured in days.
Can MTTD be reduced without increasing the tooling budget?
Yes, and that is usually where the cheapest gains sit. Three changes require no new licence: assigning a named owner to every alert category, switching off the rules with the worst ratio of true hits to false alarms, and explicitly granting the first line the authority to take reversible actions such as isolating a workstation. Each of them removes waiting from the route rather than work.
How should MTTD be calculated so the number does not lie?
Use the median rather than the mean, calculate it separately for each class of detection, and publish the number of cases it was calculated from. A mean taken from a handful of events shifts by orders of magnitude after one incident found months later, and an MTTD calculated jointly for antivirus alerts and behavioural detections mixes two entirely different populations. A metric with no case count is not fit for comparison over time.
Is MTTD a good metric to report to the board?
It is a good directional metric and a poor accountability metric. It shows whether the organisation is shortening the road from event to decision, but it can be improved in an apparent way — simply switch off detections with a long confirmation time, or stop detecting the hard cases. That is why it is always reported alongside technique coverage and the number of detections, and never as a single figure.
