The Cyber Academy take
MTTD is the average time from incident start to detection. MTTR is the average time from detection to recovery. Together they are the headline operational metrics for a SOC and an incident response programme. Industry benchmarks float in the days/weeks; mature programmes target hours.
Two metrics, one timeline
MTTD and MTTR describe two consecutive segments of the same incident timeline. MTTD covers the silent period between the moment an attacker first acts and the moment your team realises something is wrong. MTTR covers everything after that point, from triage through containment and recovery to a confirmed return to normal. Reading them together is the whole point: a low MTTD with a high MTTR means you see threats quickly but struggle to act on them, while a high MTTD with a low MTTR means you respond fast but only once the damage is already done. Neither number is useful in isolation, and improving one at the expense of the other rarely helps.
In practice these are the headline numbers a SOC reports to management, because they translate technical activity into a language the business understands: how long were we exposed, and how long did it take us to close the door. They are also the metrics regulators and frameworks circle around, even when they use different words. A breach notification deadline is essentially a legal cap on part of your MTTR, and a requirement to detect incidents in a timely manner is a requirement to keep MTTD low.
What actually moves these numbers
MTTD is driven by visibility and tuning. You cannot detect what you do not collect, so log coverage across endpoints, network, identity, and cloud is the foundation. On top of that, detection content has to be tuned: too loose and analysts drown in false positives and miss the real signal, too tight and genuine intrusions slip through. This is why a SIEM, good detection engineering, and threat intelligence feed directly into MTTD. MTTR is driven by process and authority: documented playbooks, the power to isolate a host or disable an account without waiting for a committee, tested backups, and rehearsed communication. The classic improvement here is automation through SOAR, which removes the minutes lost to manual handoffs.
| Aspect | MTTD (Detect) | MTTR (Recover) |
|---|---|---|
| Clock window | Incident start to detection | Detection to full recovery |
| Primary question | How long were we blind? | How long to contain and restore? |
| Main levers | Log coverage, detection tuning, threat intel | Playbooks, automation, authority to act, backups |
| Tooling | SIEM, EDR, threat detection | SOAR, IR runbooks, recovery tooling |
| Owner focus | Detection engineering and monitoring | Incident response and operations |
How the metrics show up in standards and benchmarks
Frameworks do not usually mandate a specific MTTD or MTTR target, because the right number depends on the organisation and the threat. What they require is the capability and the measurement. ISO/IEC 27035 sets out the incident management lifecycle that these metrics quantify. The NIST incident handling guidance frames detection, analysis, containment, eradication, and recovery as distinct phases, which is exactly the structure MTTD and MTTR sit on top of.
ENISA and national agencies such as ANSSI push the same operational message: detect early, respond fast, and be able to prove you can. Regulatory regimes add hard external deadlines, for example the breach notification windows under the GDPR and the incident reporting obligations under NIS2 and DORA, which turn part of your response time into a compliance requirement rather than a performance goal.
Benchmarks for both metrics tend to sit uncomfortably high across the industry, often in the realm of days or weeks for detection, while mature programmes target hours. Chasing a published benchmark is the wrong instinct, though. The value of MTTD and MTTR is as trend lines you own: measure them consistently, watch the direction over quarters, and tie the movement to specific investments in visibility, tuning, and automation. A number that is honestly defined and steadily falling is worth far more than a flattering one-off figure.
Frequently asked questions
01What is the difference between MTTD and MTTR?
MTTD (mean time to detect) is the average time from when an incident begins to when it is detected. MTTR (mean time to recover) is the average time from detection to full recovery. MTTD measures how long you were blind; MTTR measures how long it took to contain and restore.
02What does MTTR stand for?
In a security context MTTR most often means mean time to recover or mean time to respond, the span from detection to a verified return to normal operations. The same acronym is also used for mean time to repair in reliability engineering, so it is worth confirming the definition before comparing figures.
03What is a good MTTD and MTTR?
There is no universal target. Industry benchmarks often sit in days or weeks for detection, while mature programmes aim for hours. The more useful question is whether your own consistently measured numbers are trending downward over time.
04How do you reduce MTTD and MTTR?
Lower MTTD with broader log coverage, better detection tuning, and threat intelligence feeding a well-run SIEM. Lower MTTR with documented playbooks, tested backups, clear authority to act, and automation through SOAR to remove manual delays.
05Do regulations require specific MTTD or MTTR values?
Most frameworks require the capability to detect and respond rather than a fixed number. However, breach notification deadlines under the GDPR and incident reporting obligations under NIS2 and DORA effectively put legal caps on parts of your response time.