ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
MTTD vs MTTR is the comparison every security dashboard makes and almost none defines. Mean time to detect measures how long an intrusion runs before anyone knows; mean time to respond — or resolve, or recover, depending on who built the dashboard — measures how long it takes to do something about it once they do. They are the two indicators boards ask for by name, the two that regulators’ incident-reporting clocks depend on, and the two most often reported with definitions that quietly changed between quarters. This guide defines the four response-speed indicators precisely — MTTD, MTTA, MTTC and MTTR — shows how each is calculated and where the clock starts and stops, gives the external benchmarks that exist, and explains what each indicator can and cannot tell you.
Every incident has a timeline with the same five points on it: the moment of compromise, the moment of detection, the moment a responder takes ownership, the moment the attacker’s ability to act is removed, and the moment normal operation is restored. The four indicators are the mean intervals between consecutive points, measured across the incidents in a period.
| Indicator | Measures | Clock starts | Clock stops | What it tells you |
|---|---|---|---|---|
| MTTD — mean time to detect | Dwell time: how long the adversary had before you knew | First malicious activity (established by forensics) | First alert or report that identifies the activity | Visibility: coverage and quality of detection |
| MTTA — mean time to acknowledge | Queue time: how long an alert waited | Alert generated | A responder takes ownership | Staffing and triage: whether alerts are worked |
| MTTC — mean time to contain | Response: how long the adversary kept access after you engaged | Acknowledgement | Adversary access removed or isolated | Response capability: playbooks, tooling, authority to act |
| MTTR — mean time to recover (or resolve) | Restoration: how long the business was affected | Containment (or detection, if measured end-to-end) | Service restored and incident closed | Resilience: backups, rebuild capacity, dependencies |
In the MTTD vs MTTR pairing, the acronym MTTR is the problem. It is used for mean time to respond (detection to containment), mean time to resolve (detection to closure), mean time to recover (containment to restoration) and, in IT operations, mean time to repair. A dashboard that says “MTTR” without a definition is reporting an unknown quantity. Pick one, write it down, and label the others by their own names.
Of the MTTD vs MTTR pair, MTTD is the hardest to measure honestly, because the clock starts at a moment you did not observe. The start time comes from forensic reconstruction after the fact — the first malicious login, the first beacon, the first file written — and for incidents that are never fully investigated it is an estimate. Two consequences follow. MTTD should be reported only for incidents with a forensically established start, with the count of those incidents shown beside it. And MTTD is biased by what you detect: an organization that never detects long-running espionage reports a short MTTD, not a good one.
The external benchmark is Mandiant’s annual M-Trends. The 2026 report puts the global median dwell time for 2025 at 14 days, up from 11 days in 2024, with cyber espionage and North Korean IT-worker intrusions at a median of 122 days; 52% of intrusions were detected internally, against 43% the year before. Two things to take from that: the median is a median across investigated intrusions, not a target, and internal detection — the numerator of your own MTTD — is the thing worth measuring alongside it. Report MTTD as a median as well as a mean; one 300-day espionage case makes a mean meaningless.
MTTA and MTTC are the operational pair. MTTA is almost entirely a function of staffing, alert volume and triage rules; it is measured cleanly from the SIEM or ticketing timestamps and it is the first thing to improve when a SOC is overwhelmed. MTTC is the indicator that shows whether the response function can actually act: whether responders have the authority to isolate a host, the tooling to do it, and the playbook to know when. It is measured from acknowledgement to the containment action, and it should be reported by severity, because a P1 contained in two hours and a P4 contained in two weeks are not the same number averaged.
Regulatory clocks run across these two intervals. NIS2’s 24-hour early warning and DORA’s 4-hour initial notification both start from awareness or classification — after detection, during acknowledgement and containment. An organization whose MTTA is measured in days cannot meet either. Our guide to NIS2 incident reporting sets out the clocks.
Mean time to recover measures the business, not the SOC. It runs from containment to restoration and it depends on backups, rebuild automation, dependency mapping and the decisions made during the incident. It is the indicator that should be compared to the recovery time objectives in the business continuity plan — an MTTR above the RTO for a critical service is a continuity finding, not only a security one — and it is the one an ISO 22301 or DORA testing program exercises directly. Our guide to RTO and RPO covers the recovery metrics it is measured against.
A short MTTD says nothing about the intrusions that were never detected. A short MTTC says nothing about whether containment was complete — re-compromise within 30 days is its own indicator. A short MTTR can reflect a small incident rather than a strong recovery capability. And all four are lagging indicators: they describe incidents that already happened. The leading indicators — control coverage, exposure, detection coverage mapped to attacker techniques — belong beside them, which is why board cybersecurity reporting uses detection and response speed as one of six indicators rather than the only one.
What is the difference between MTTD and MTTR?
MTTD measures the interval from compromise to detection — how long an intrusion ran unseen. MTTR measures how long it took to deal with it once known, but the acronym is used for respond, resolve, recover and repair; define which interval you mean.
What is a good MTTD?
There is no universal target. Mandiant’s M-Trends 2026 reports a global median dwell time of 14 days for 2025. Report your own median and mean by severity, and improve the share of intrusions detected internally rather than by third parties.
How do you measure MTTD if you do not know when the compromise began?
You cannot, precisely. Use the forensically established first malicious activity where it exists, report MTTD only for those incidents, and show the count. Estimates should be labelled as estimates.
Which indicator matters most for regulators?
MTTA and MTTC, because NIS2’s 24-hour early warning and DORA’s 4-hour initial notification run from awareness or classification — after detection. Slow acknowledgement makes both clocks impossible to meet.
Should MTTR be compared with RTO?
Yes. MTTR measured from containment to restoration is the security-incident equivalent of the recovery time objective in the continuity plan. An MTTR above the RTO for a critical service is a continuity finding.
Treat MTTD vs MTTR as four clocks on one timeline — detect, acknowledge, contain, recover — each with a written start and stop, computed from timestamps in the incident record, reported by severity as mean, median and count. Benchmark MTTD against M-Trends, MTTA and MTTC against the regulatory clocks, MTTR against the RTO, and put all four beside the leading indicators they cannot replace.
153 key risk and performance indicators keyed to NIST CSF subcategories — including the detection and response measures under Detect, Respond and Recover — each with a formula, frequency, thresholds and an owner, are in the Excel-based Critical IT and Cybersecurity Indicators templates, or start with the free templates.
September 20, 2026
September 20, 2026
September 19, 2026
September 19, 2026
September 19, 2026