MTTR Explained: Five Clocks Behind One Acronym

Mean time to repair (MTTR) covers five different measurements, and the gap between them is not a rounding error. The same incident can produce a nine-minute MTTR or a nine-hour one depending on where the clock stops, and both figures can be defensible.

MTTR is the average time a team takes to move between defined start and end points in incident response, recovery, repair, remediation, or resolution. Which pair of points applies changes the answer by orders of magnitude. Current NIST incident response guidance prescribes no MTTR clock at all, so before you accept anyone's figure, including your own, you need to know which expansion is in play and exactly where the clock starts and stops.

TL;DR:

• MTTR has no canonical definition. The five expansions in common use measure categorically different intervals, and no standards body settles which one wins. A quoted figure means little without explicit start and stop timestamps.
• The arithmetic mean alone is the wrong summary for incident data. Incident durations skew heavily, so a single long incident can dominate the average. Report the median and P90 alongside any mean.
• MTTR distorts behavior once it becomes a target. Teams can lower the reported number through shallow triage, severity changes, ticket splitting, or rapid re-imaging, without reducing incident risk.
• Acknowledgment-based MTTR lags fast-moving attacks. An intrusion can move well past initial access before a human-led acknowledgment and investigation cycle completes.

An MTTR number is useful when its clock and denominator match the outcome you care about.

MTTR Has Five Definitions and No Referee

Five expansions are in common use across security and IT operations, covering repair, respond, remediate, recover, and resolve. Restore is usually treated as a variation of recover. Each clocks a different interval, so without stating the expansion explicitly, two teams can use the same acronym for entirely different measurements. The boundary pairs below are a reading of common practice, not a published classification.

‍

The spread across those rows is where the nine-minute versus nine-hour gap comes from. One team stops the clock at the first containment action; another keeps it running until every affected host is verified clean.

NIST offers no tiebreaker. The withdrawn Revision 2 of SP 800-61 came closest. Even that only listed ways "time per incident" could be measured: from the beginning of the incident to discovery, to the initial impact assessment, and to each stage of the handling process. Revision 3, which superseded it in April 2025, drops performance measurement entirely and contains no mean-time metric of any kind. Definitional authority therefore sits with whoever establishes the metric, which means a quoted MTTR figure without the expansion and exact clock boundaries cannot be compared to anything, including your own history.

Where MTTR Sits in the Metric Chain

Time to detection, by the convention used here, is the interval from the start of malicious activity to the alert firing, and it inherits the same definitional looseness MTTR has. The detection clock has boundary problems of its own, because the start of malicious activity is rarely known in real time. Time to acknowledgment runs from the alert to someone beginning work, and acknowledgment time says more about staffing than about response capability. Time to investigation runs from acknowledgment to a verdict. The adopted definition determines whether MTTR spans detection to the first containment action or all the way to verified remediation.

Dwell time is a different animal. It is the total time a threat remains in the environment from initial compromise until complete removal, and it includes both time to detection and MTTR. Two days to notice plus one day to contain equals three days of dwell.

Segmenting MTTR beats relying on one global figure, because critical incidents require a different response window from routine events. When writing MDR contracts, organizations can also set different commitments depending on whether the provider has pre-authorized response authority or must call the customer before acting.

Both clocks count only confirmed threats. Detection stops its clock at the alert, and MTTR excludes false positives entirely, so neither figure shows how long alerts wait in queue or how much of the week goes to clearing noise. Alert coverage is the metric that answers that question.

Four Ways MTTR Misleads

Each failure mode below breaks MTTR in a different place, and they are ordered the way they are worth auditing: start inside your own data, and work outward to whether anyone else's number can be read against yours at all.

1. The Mean Hides the Long Tail

Take five illustrative incidents at one hour, four hours, 30 minutes, 48 hours, and three hours. They produce an MTTR of 11.3 hours, a figure dominated entirely by the single 48-hour outlier and describing none of the other four.

That skew is not a quirk of the example. Analysis of the incident reports collected in the Verica Open Incident Database found that MTTR "has too much variance in the underlying data to be a measure of system reliability." That was a 2022 software-incident finding, but it transfers cleanly to security, where duration distributions are at least as skewed.

2. Targets Get Gamed

Metrics tied to team performance tend to shape behavior, and MTTR is unusually easy to improve without touching risk. Reclassifying a hard incident, splitting it into sub-tickets, or closing and later reopening it all move the number without changing what happened. A SOC could also lower its reported MTTR by closing alerts as false positives without validating that the closures were correct.

Prioritizing only speed may create a tradeoff against evidence preservation, favoring re-imaging an alerting endpoint before anyone captures the data needed to understand the intrusion. Borrowing SOC performance metrics from the ticket desk makes all of this worse. The UK's NCSC has put the mechanism plainly: analysts measured on how quickly they close tickets get pushed toward dismissing alerts as false positives rather than investigating them properly.

3. Unsegmented Averages Conflate Incident Classes

Segment response data by incident type and severity. Two hours spent on a commodity phishing report carries nothing like the urgency of two hours spent on active ransomware, even though the duration is identical. Push that further and one phishing report closed in minutes averages against one domain-wide compromise closed in weeks, producing a figure that describes neither. Your averages also carry an alert denominator problem: they cover only the alerts you investigated and silently exclude alerts that never reached a verdict.

4. Vendor Figures Are Not Comparable

Treat published MDR figures as incompatible unless their clocks match. Some cover full remediation; others use narrower clocks that begin at alert receipt or end at containment. When an SLA defines response as acknowledgment or analyst disposition rather than containment, it measures that narrower interval, and a large reported reduction against that clock may be accurate while saying nothing about whether the attacker was still in the network.

Attacker Speed Sets the Floor

For incidents that develop quickly, the acceptable MTTR is correspondingly small. Attacker hand-off times have compressed from hours to seconds over the past few years, which means a conventional queue, acknowledgment, investigation, escalation, and containment workflow may not finish in time.

Where the attack cycle is that compressed, human-speed triage stops being sufficient on its own. Long breach lifecycles and fast hand-off figures are not in tension, because the two measure different intervals. Hand-off measures tactical speed once an attacker is inside, while lifecycle measures can include extended periods of undetected activity, which is why median dwell time rose over the same period that hand-off times collapsed. An SLA that only acknowledges a critical alert does not establish that investigation or containment happened before the attacker moved.

What to Track Alongside MTTR

False positive rate, escalation accuracy, alert-to-incident ratio, alert coverage, and alert backlog all explain your MTTR. MTTR explains little about any of them.

False positive rate drives downstream workload, because every unnecessary alert consumes capacity that could go to genuine threats. The trend is usually more useful than the snapshot: a rate declining quarter over quarter can signal tuning progress, while a static one may signal a stalled detection program.

Escalation rate shows how often alerts cannot be resolved at first contact, which may signal noisy tooling or missing context rather than more threats. Escalation accuracy, the share of escalated alerts confirmed as real, belongs beside it. Low accuracy may mean analysts are escalating as a hedge rather than rendering a verdict. Alert-to-incident ratio does similar work from the other direction, showing how much of your alert volume ever becomes something worth responding to.

Alert coverage exposes the denominator problem directly. Raw closure counts say little on their own; the percentage of generated alerts that actually reach a verdict tells you what your MTTR average silently excludes.

Alert backlog measures the alerts still waiting in queue or lacking a conclusion. It exposes the queue delay and unresolved work that confirmed-threat MTTR leaves out, which is the hidden denominator in most reported figures.

And wherever you keep a mean, add percentiles. The median shows typical performance; P90 shows where the pain lives.

How to Define MTTR for Your Own Program

A defensible MTTR definition depends on how you segment and disclose it. Five conditionals cover most programs:

• If you report MTTR to the board, segment by severity and incident class, and report medians with P90 rather than a single global mean. An unsegmented average flattens exactly the cases boards need to see.
• If you are evaluating a managed provider, demand the clock definition in writing: which expansion, whether the start is alert generation or analyst pickup, and whether the stop is acknowledgment, containment, or verified remediation. Keep two things apart, because a contractual SLA tells you what a provider committed to while published operational metrics tell you what it actually delivered.
• If your threat model includes ransomware or hands-on-keyboard intrusion, measure time to verdict and time to containment, not time to acknowledgment. Acknowledgment SLAs measure a step attackers do not wait for.
• If your team is graded on MTTR, pair it with escalation accuracy and false positive rate so that closing tickets fast stops being the winning move.
• If your MTTR runs to months, treat it as a coverage and context question before an effort question. A clock that long is rarely explained by how hard the team is working.

Some of those conditions change what you measure and some change only what you disclose, but none of them can be applied until the clock itself is settled.

Which MTTR Clock Belongs in a Contract

For a buyer, time to verdict and time to containment are the clocks worth negotiating over. Time to acknowledgment is narrower, and providers often favor it in SLAs because acknowledgment is a discrete step they control. Queue and investigation times vary widely by provider and scope, and analyst-dependent workflows can place alerts in a queue before investigation begins and route ambiguous cases back to the customer. An SLA that commits only to acknowledging a critical alert does not establish that anyone reached a verdict or contained anything before the attacker moved. Prioritize the response-time numbers you can actually audit.

Daylight Security is a Managed Agentic Security Services (MASS) company, meaning it runs security operations work as a managed service on an agentic platform rather than selling tooling for a team to operate. It starts with AI-native MDR and extends the same operating model to threat hunting and the Agentic Security Data Lake. Because response outcomes depend on the customer environment, existing tools, authorization scope, and investigation complexity, Daylight does not promise a universal MTTR outcome; teams comparing response models can find related context in Daylight's MDR service.

Frequently Asked Questions About MTTR

How Should You Record Dwell Time When the Compromise Date Is Unknown?

Do not substitute the MTTR start time for an unknown compromise date. Record the pre-detection interval as unknown, report the observed detection-to-removal interval separately, and avoid presenting the result as full dwell time. That keeps an incomplete timestamp from collapsing two different clocks into one.

How Can You Normalize a Published MTTR Benchmark?

Match the expansion, start timestamp, stop timestamp, denominator, incident class, and severity before comparing it with your own data. Figures commonly used as proxies may combine identification and containment, measure attacker movement rather than defender response, or cover vulnerability remediation as a different operational process. If those fields are not disclosed, the figure should not be treated as a comparable benchmark.

Should the Clock Start at Alert Generation or Analyst Acknowledgment?

Start it at alert generation if you want the number to reflect the attacker's experience. Starting at acknowledgment excludes queue time, which is often where the delay actually lives.

How Should MTTR Be Documented for Audits or Contracts?

Document the expansion, exact start and stop events, treatment of false positives and reopened incidents, and required severity segmentation. Do not describe that custom clock as NIST-defined. The withdrawn Revision 2 of SP 800-61 specified only that time per incident could be measured to each stage of the handling process. Revision 3 replaced its four-phase lifecycle with a model mapped to the CSF 2.0 Functions, where Respond and Recover sit as separate framework functions rather than one interval. A contract or audit record therefore needs to define the clock boundaries rather than infer them from the acronym.

Can AI Actually Deliver the MTTR Reductions Vendors Claim?

It depends on which clock the claim uses. AI investigation tooling can reduce context-collection and evidence-correlation work and shorten the path to a verdict. Buyers should treat published performance data as vendor-reported unless it has been independently validated. Queue clearance and auto-resolution are murkier, and headline rates may reflect tuned deployments rather than a steady-state promise. Ask for multi-cycle production data and the clock definition before crediting any percentage.