MTTD vs MTTR: Clock Rules, Variants and Benchmarks

MTTD and MTTR are the two numbers most often used to judge a security operations team, and the two most often calculated in ways that cannot be compared or trusted. Mean time to detect measures how long an attacker or failure goes unnoticed; mean time to respond, recover, repair or resolve measures what happens after that, depending on who is counting. This guide compares the two metrics directly: where each clock starts and stops, the four meanings of MTTR, why the median beats the mean, how both numbers get gamed, and how identity incidents distort them. It is written for SOC managers, incident response leads and the security leaders who report these figures upward. For the wider set of SOC metrics, see the Security Operations Metrics Guide.

Key takeaways

MTTD measures visibility, MTTR measures capability. A slow MTTD points at telemetry and detection content; a slow MTTR points at people, process, access and automation.
MTTR has at least four meanings. Respond, recover, repair and resolve stop the clock at very different points, so a figure without its definition is meaningless.
Report the median and the 90th percentile. Incident durations are skewed, and one long intrusion can make a quarterly mean look like a collapse.
The clock start for MTTD is a forensic judgement. It moves as investigations find earlier evidence, so MTTD for recent incidents is provisional and must be restated.
Identity incidents break both clocks. Valid credentials look like normal activity, which lengthens detection, and containment is not complete until every exposed token and key is revoked or rotated.

The short answer: what each metric tells you

MTTD (mean time to detect) is the average interval between the start of malicious activity, or a failure, and the moment the organisation knows about it. It answers "how long were we blind?" and is the closest operational proxy for attacker dwell time in confirmed incidents.

MTTR is the average interval between detection, or incident declaration, and a defined end point. It answers "once we knew, how long did it take to act?" The problem is the end point. Atlassian's incident management guidance notes that the R in MTTR can stand for repair, recovery, respond or resolve, and that teams should state which one they track.

The two are complementary, not alternatives. Improving MTTR does nothing for an attacker you have not seen, and a fast MTTD is wasted if the response takes days. Track both, against one incident timeline, with published definitions.

Clock start and stop rules

Every disagreement about these metrics comes down to which timestamp starts and which stops the clock. Choose one rule per metric, write it in the metrics dictionary, and store each timestamp as a separate field in the case record so the metric can be recomputed if the rule changes.

Metric	Clock start options	Recommended start	Clock stop options	Recommended stop
MTTD	First malicious event (forensic); first telemetry of it ingested; first alert raised	First malicious event found by the investigation, restated when earlier evidence appears	Alert raised; analyst confirms; incident declared	The alert or report that led to the incident being opened
MTTR (respond)	Alert raised; incident declared	Incident declared	First containment action; ticket assigned	First meaningful containment action, not acknowledgement
MTTR (recover)	Incident declared; service outage began	Service impact began	Service restored; users back to normal operation	Business service restored and validated
MTTR (repair or remediate)	Root cause known	Root cause established	Fix deployed; vulnerability closed; credentials rotated	Root cause removed and verified
MTTR (resolve)	Incident declared	Incident declared	Case closed; lessons learned complete	Post-incident actions to prevent recurrence complete

Three rules make the timestamps trustworthy. Synchronise every log source to one time reference and store times in UTC. Record event time and ingestion time separately, because a slow log pipeline adds to MTTD without any analyst being slow. And never let the clock stop on a status change alone: "contained" must reference an action record, such as an endpoint isolation, an account disable or a token revocation.

The four meanings of MTTR

The four variants come from different disciplines, and security teams borrow all of them.

Mean time to respond: Atlassian describes this as time from the first alert until the system is fully working again, excluding alerting lag, and notes it is often used in cybersecurity. Many SOCs use a narrower version that stops at the first containment action. State which.
Mean time to recover (or restore): total downtime divided by the number of incidents. This is the reliability engineering view. DORA, the DevOps research programme, now calls its version "failed deployment recovery time", defined as "the time it takes to recover from a deployment that fails and requires immediate intervention", and notes it was formerly MTTR.
Mean time to repair: time to fix a system, including testing. In security this is closer to remediation: patching the exploited flaw, rebuilding hosts, rotating credentials.
Mean time to resolve: the full cycle including detection, diagnosis, repair and measures to prevent recurrence. Atlassian notes it is usually measured in business hours, which matters when comparing with a 24x7 SOC that counts calendar hours.

Variant	Owner	Typical range for a serious intrusion	Good for	Misleading when
Respond	SOC	Minutes to hours	Measuring SOC readiness and automation	The first action is trivial, such as a ticket comment
Recover	IT operations with SOC	Hours to weeks	Business impact and resilience reporting	No service was down, so recovery is near zero
Repair or remediate	Platform and engineering teams	Days to months	Tracking root cause removal	Fixes are deferred under risk acceptance and drop out of the sample
Resolve	Incident manager	Weeks	End to end process health	Closure waits on paperwork rather than security work

A practical approach is to report all four from the same case records under distinct names (MTTRespond, MTTRecover, MTTRemediate, MTTResolve) and never publish a bare "MTTR". The NIST CSF 2.0 Respond and Recover outcomes give neutral anchors for the stops: incidents are contained (RS.MI-01), incidents are eradicated (RS.MI-02) and the recovery portion of the plan is executed (RC.RP-01).

Median, mean and percentiles: a worked example

Take ten confirmed incidents in a quarter with detection times, in hours, of 1, 2, 2, 3, 4, 4, 6, 8, 12 and 900 (the last is an intrusion found by forensic review after five weeks). The mean is 94.2 hours, almost four days. The median is 4 hours. Neither is wrong, but only the median describes a typical incident, and only a tail measure shows the outlier.

Report the median: it is stable when a single case is extreme.
Report the 90th percentile: it shows whether the slow tail is getting better or worse.
List outliers individually: the 900 hour case deserves its own line in the report, with why it was missed.
Segment first: calculate by severity and incident type (phishing, malware, identity compromise, insider, cloud misconfiguration). A quarter of fast phishing cases will flatter a combined figure.
Small samples: below about ten incidents per segment, show each incident on a timeline instead of a statistic and trend over four quarters.

Keep the arithmetic consistent with the dictionary. NIST SP 800-55 Volume 1 frames security measures as evidence of whether controls are working; a measure whose formula changes every quarter cannot do that.

How MTTD and MTTR get gamed

Both metrics are easy to improve on paper without any change in security. Each pattern below has a check that exposes it.

Gaming pattern	Metric it flatters	Check that exposes it
Starting the MTTD clock at the first alert instead of the first malicious event	MTTD	Compare with forensic first event for confirmed incidents; publish both
Excluding incidents reported by third parties, customers or the attacker	MTTD	Report the share of incidents detected internally next to MTTD
Not restating MTTD when forensics finds earlier activity	MTTD	Recalculate prior quarters when a case's first event changes
Stopping the respond clock on acknowledgement or a ticket comment	MTTR (respond)	Require a linked containment action record
Downgrading severity so slow cases leave the critical segment	MTTR by severity	Audit severity changes after declaration
Closing and reopening cases to reset the clock	MTTR (resolve)	Track reopen rate and measure from first open
Leaving open incidents out of the quarter's calculation	All MTTR variants	Report the count and age of open incidents alongside
Declaring trivial incidents to add fast cases	Both	Segment by severity and type; watch incident counts

The surest defence is pairing. Every speed metric needs a quality partner, such as the internal detection rate for MTTD and a sampled review of containment completeness for MTTR, and targets should be set on the pair, not on speed alone.

Benchmarks: what external data can and cannot tell you

Published figures come from incident response firms and describe the incidents they were called to investigate, which skews them towards serious intrusions. Use them for context, not as targets.

Dwell time: Mandiant's M-Trends 2026, based on its 2025 investigations, reports that global median dwell time rose to 14 days from 11 days, with a median of 122 days for cyber espionage and North Korean IT worker cases. Organisations first detected malicious activity internally 52% of the time, up from 43% in 2024.
Attacker speed: the same report states that the median time between initial access and hand-off to a secondary threat group fell from more than eight hours in 2022 to 22 seconds in 2025.
Time to exfiltration: the 2026 Unit 42 Global Incident Response Report, covering more than 750 engagements between 1 October 2024 and 30 September 2025, gives a median time to exfiltration of two days, with the fastest quarter of cases reaching exfiltration in 72 minutes and 22% of cases in under one hour, up from 19% in 2024.

The lesson for MTTD is direct. If the median attacker can exfiltrate in two days and a quarter do it in about an hour, a median MTTD measured in days means detection often arrives after the data has gone. Compare your MTTD with time to exfiltration, not with last year's MTTD alone. See Incident Response Statistics for more sourced figures.

Identity incidents and dwell time

Identity compromise is where both clocks behave worst. The Unit 42 report states that identity weaknesses played a material role in almost 90% of its investigations and that 65% of initial access was driven by identity-based techniques. Activity under valid accounts (ATT&CK T1078, including T1078.004 Cloud Accounts) produces logins and API calls that look like normal work, so detection relies on behaviour and context rather than signatures.

MTTD start is hard to pin: the first malicious use of a credential may be weeks after it was stolen. Record both the credential exposure time (when known) and the first malicious use, and say which one MTTD uses.
Non-human identities extend dwell: service accounts, API keys and OAuth tokens rarely trigger user-focused analytics such as impossible travel, and many have no owner to notice odd use.
Containment means revocation: disabling a user does not end sessions already issued or invalidate keys copied elsewhere. For identity incidents the respond clock should stop only when sessions are revoked and every exposed secret is rotated, and the remediate clock when the path that exposed them is closed.

The Cloudflare breach shows why the clock definitions matter. The attacker reached Cloudflare's Okta instance on 18 October 2023 through the Okta support system breach, then used one service token and three service account credentials that had not been rotated to enter Atlassian systems from 14 November; Cloudflare detected the activity on 23 November and cut access on 24 November. Starting the clock at first use of the unrotated credentials gives roughly ten days; starting at the original exposure gives more than five weeks. Both are honest if stated. See the Identity Incident Response Playbook and the ITDR Guide.

Decision guidance: which number to lead with

Board and executive reporting: lead with median MTTD and the internal detection rate, and MTTRecover for incidents with business impact. Executives care about blind time and outage time.
SOC operational reviews: lead with MTTRespond by severity and the 90th percentile, plus open incident age. These are what shift leads can change week to week.
Engineering and platform teams: lead with MTTRemediate, because root cause fixes live in their backlogs.
Small teams with few incidents: skip statistics; publish an incident timeline for each case and measure MTTD in purple team exercises, where the start time is known and the sample can be made large enough.
Outsourced SOC or MDR: write the clock rules into the contract. Provider "MTTR" often means time to notify the customer, which is a different metric from containment.

Dashboard design

One timeline panel: a strip per incident showing first malicious event, detection, declaration, containment, recovery and closure, so readers see where time goes.
Headline tiles: median MTTD, median MTTRespond, median MTTRecover, each with the 90th percentile underneath and the definition on hover or in a footnote.
Quality partners beside each tile: internal detection rate next to MTTD; containment completeness sample next to MTTRespond.
Segment selector: severity, incident type and detection source, with identity compromise as its own type.
Open incident panel: count and age of incidents not yet contained, so stalled cases are visible.
Restatement log: a short list of past quarters revised because forensics moved a first event earlier.

Keep the dashboard definitions in a single metrics dictionary; the Security Metrics Dictionary Template gives a format.

Implementing in phases

Define: write clock rules for MTTD and each MTTR variant, agree them with IT operations and the incident manager, and publish them.
Instrument: add timestamp fields to the case system (first malicious event, credential exposure, detection, declaration, containment action reference, recovery, remediation, closure) and synchronise log time sources.
Backfill and baseline: recompute the last four quarters from case records using the new rules, and accept that the numbers will look worse.
Pilot reporting: run the new dashboard alongside the old one for a quarter, explaining differences, before retiring the old figures.
Validate: run purple team or breach and attack simulation exercises to measure MTTD where the start is known. See the Purple Teaming Guide.
Review: audit a sample of cases each quarter for clock accuracy, severity changes and containment completeness, and restate when needed.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.AE-02, RS.MA-02, RS.MI-01, RS.MI-02, RC.RP-01	Analysis of adverse events, triage, containment, eradication and recovery: natural stop points for each clock
NIST CSF 2.0	GV.OV-03, ID.IM-01	Reviewing risk management performance and identifying improvements from evaluations
NIST SP 800-53 Rev. 5	IR-4, IR-5, IR-8, AU-6, SI-4	Incident handling, incident monitoring, the response plan, audit review and system monitoring
NIST SP 800-61 Rev. 3	CSF 2.0 Community Profile	Incident response recommendations organised around CSF 2.0 outcomes
ISO/IEC 27001:2022	Annex A 5.26, 5.27	Response to incidents and learning from incidents
CIS Controls v8.1	Control 17	Incident response management
MITRE ATT&CK	T1078, T1078.004	Valid accounts, the technique family behind long identity dwell times

Common failure patterns

A bare "MTTR" on the board slide: nobody knows whether it is respond, recover, remediate or resolve, and the number gets compared with a peer who uses a different one.
Means on skewed data: one long intrusion swings the quarter, and leadership reacts to noise.
MTTD that never gets restated: forensic findings move the first event earlier, but the reported figure stays as first calculated.
Containment declared before credentials are rotated: the incident closes, and the attacker returns with a token nobody revoked, as with the unrotated service credentials in the Cloudflare case.
Speed targets without quality partners: analysts learn to close fast, and the reopen rate climbs.
Provider and internal clocks mixed: MDR notification time is added to internal response time as though it were the same metric.

Practitioner checklist

Publish one clock rule per metric, with start and stop timestamps named.
Report MTTRespond, MTTRecover, MTTRemediate and MTTResolve separately, never a bare MTTR.
Store every timestamp as its own field and require an action record for containment.
Report median and 90th percentile by severity and incident type, and list outliers.
Show the internal detection rate beside MTTD and open incident age beside MTTR.
Restate past MTTD when forensics finds earlier activity.
Treat identity compromise as its own segment and stop its containment clock only after revocation and rotation.
Compare MTTD with external time to exfiltration figures, not only with your own history.
Measure MTTD in purple team exercises where the start time is known.
Write the clock rules into MDR and IR retainer contracts.

MTTD vs MTTR: Clock Rules, Variants and Honest Benchmarks