MTTD vs MTTR — Differences, formulas, benchmarks

TL;DR — Are MTTD and MTTR the same?

No, they are two distinct metrics inside the same Incident Response pipeline. MTTD (Mean Time To Detect) measures how long it takes to detect an incident from the moment it actually occurred in the environment. MTTR (Mean Time To Respond or Recover) starts exactly where MTTD ends — at the confirmed detection — and measures the time of the full response up to closure. Together they define dwell time — the total time an attacker spends inside the network. In a mature 24/7 SOC model both metrics are typically reported together, because fast detection without an effective response yields negligible defensive value, and an effective response without early detection means the attacker has already achieved the objective (data exfiltration, ransomware deployment, persistence).

MTTD vs MTTR — comparative table

Aspect	MTTD (Mean Time To Detect)	MTTR (Mean Time To Respond / Recover)
What it measures	Time from event occurrence to detection	Time from detection to full incident closure
Unit	Minutes / hours / days	Hours / days
Start point	Event timestamp in source logs (endpoint, firewall, IdP)	Confirmation of an alert as an incident
End point	Alert confirmed in SIEM/EDR/XDR	Containment (Respond) or service restoration (Recover)
Formula	Σ(t_detection − t_occurrence) / N	Σ(t_closure − t_detection) / N
Typical 2026 benchmark	Finance ~24h, Healthcare ~72h, OT ~5 days	Finance ~48h, Healthcare ~5 days, OT ~2 weeks
Main improvement tools	EDR/XDR, SIEM, threat hunting, NDR, honeypots	SOAR, EDR isolation, runbooks, DFIR retainer, 24/7 SOC

Definition of MTTD (Mean Time To Detect)

MTTD is the average time between a security event occurring in the environment and being detected by a detection system or a SOC analyst. The value is the clearest proxy for the maturity of the detection layer — the quality of SIEM rules, correlations, EDR policies, the threat hunting programme and log coverage. The full definition, historical sources of the metric and advanced variants (per attack type, per priority) live in the dedicated entry MTTD.

A critical nuance: MTTD should not be measured from the first alert in the SIEM console but from the event timestamp in the source logs (e.g. the endpoint log entry, firewall syslog message, Entra ID sign-in log). It often turns out that signals pointing to the incident were available many hours or days earlier, but the detection rule either did not exist or required too long an aggregation window.

Definition of MTTR (Mean Time To Respond / Recover)

MTTR is one of the most frequently reported SOC metrics today, but historically the acronym has two meanings used interchangeably:

• MTTR as Mean Time To Respond — the time from detection to containment, i.e. stopping the spread of the threat (host isolation, account block, network segmentation, blocking the C2 domain at DNS).
• MTTR as Mean Time To Recover — the time from detection to full restoration of business services to a production-ready state (endpoint re-imaging, restore from backup, credential rotation, SLA recovery).

Modern practice (NIST IR 2025, ENISA Good Practices for IR 2024) increasingly splits these two values into MTTR-Respond and MTTR-Recover, because the gap between them can be many hours or days — a host can be isolated in 5 minutes but may only be restored to production after a day of forensics. The full definition, the formula breakdown and implementation guidance are covered in the dedicated entry MTTR.

Full IR metrics pipeline — where MTTD and MTTR fit

A mature Incident Response programme tracks not two but seven related metrics in time-ordered sequence:

1. Event — the event occurred in the environment (source-log timestamp).
2. MTTD (Mean Time To Detect) — time to detect and confirm that it is an incident, not noise.
3. MTTA (Mean Time To Acknowledge) — time from the alert appearing in the queue to an analyst picking it up. A typical bottleneck for 8/5 teams or under-staffed SOCs.
4. MTTI (Mean Time To Investigate) — time for triage, scoping and initial attribution. Depends on log retention quality and access to EDR telemetry.
5. MTTC (Mean Time To Contain) — time to isolate the threat. Automation is the biggest lever here: if the EDR can auto-isolate a host above risk score X, MTTC can be measured in minutes.
6. MTTR-Respond — time to eradication: removing malware, rotating credentials, closing the entry vector (e.g. disabling a service account, patching the vulnerability).
7. MTTR-Recover — time to full restoration of services, re-imaging, restoring from backup, integrity verification.
8. MTTI-Improve (optional) — time from incident closure to rolling out lessons learned: new detection rules, runbook updates, additional team training.

Each metric exposes a different bottleneck. High MTTA = not enough shift analysts or an overloaded queue. High MTTC = no isolation automation. High MTTR-Recover = missing backup procedures or no documented re-imaging workflow.

Formula and calculation example

Both metrics are classic arithmetic means computed in a consistent time unit (minutes, hours or days, depending on the typical incident scale):

MTTD = Σ (t_detection_i - t_occurrence_i) / N
MTTR = Σ (t_closure_i - t_detection_i) / N
dwell_time = MTTD + MTTR

where N is the number of incidents in the analysed period (typically a month or a quarter).

Numerical example — 5 incidents in a month:

#	t_occurrence	t_detection	t_closure	MTTD_i	MTTR_i
1	02:00	04:00	09:00	2h	5h
2	14:10	14:25	16:25	15min	2h
3	22:00 (D-1)	06:00	11:00	8h	5h
4	10:00	10:20	12:20	20min	2h
5	08:00	11:00	19:00	3h	8h

Means:

• MTTD ≈ 2h 51min
• MTTR ≈ 4h 24min
• dwell time ≈ 7h 15min

The most common measurement trap: teams measure MTTD from the first SIEM alert instead of from the event timestamp in the source logs. These two values can typically differ by hours or days, especially when a detection rule requires the aggregation of many events (e.g. brute force after 50 failed logins in 1h). Only measuring from the source reveals the true effectiveness of the detection layer.

An additional methodological decision: do you include false positives or incidents closed without escalation in MTTD/MTTR? Most organisations report only confirmed incidents (True Positives after triage). That narrows the sample but gives month-over-month comparability.

MTTD/MTTR benchmarks in 2026 — by sector

Sector	MTTD median	MTTR median	Source
Finance / FinTech	~24h	~48h	IBM Cost of Data Breach 2024, Verizon DBIR 2025
Tech / SaaS	12-48h	24-72h	SANS SOC Survey 2024
Healthcare	~72h	~5 days	IBM Cost of Data Breach 2024
Retail / E-commerce	~48h	~3 days	Verizon DBIR 2025
Manufacturing / OT-ICS	5-10 days	2 weeks+	Mandiant M-Trends 2024, SANS ICS Survey 2024
Energy / Utilities	7-14 days	2-4 weeks	Dragos Year in Review 2024
Public Sector	5-7 days	1-2 weeks	Verizon DBIR 2025

Global median dwell time reported by Mandiant M-Trends fell from 16 days (2022) to roughly 10 days (2023) — a positive trend driven by wider EDR/XDR adoption and MDR programmes. In OT/ICS and Healthcare, however, the values remain many times higher, mainly because of fragmented infrastructure, limited visibility at the OT layer (Purdue Model levels 0-2) and the inability to patch during production windows.

A pragmatic target for a mature 24/7 SOC in 2026: MTTD < 1h and MTTR < 4h for typical incidents (commodity malware, phishing with credential theft, brute-force attempts). For APT, ransomware-with-lateral-movement or insider-threat cases, expect proportionally longer values — but with a clearly documented time decomposition across the phases (MTTA → MTTI → MTTC → MTTR).

How to improve MTTD

Improving MTTD generally requires parallel work in six areas:

1. EDR / XDR with behavioural analytics — Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity, Sophos Intercept X, Trend Vision One. Signature-only AV will not catch fileless malware, living-off-the-land techniques or modern MITRE ATT&CK tradecraft. EDR/XDR with UEBA usually will.
2. SIEM with multi-source correlation — Splunk Enterprise Security, Elastic SIEM, Microsoft Sentinel, IBM QRadar, Wazuh (open-source). The key is log coverage: if the SIEM lacks logs from your IdP (Entra ID, Okta), endpoints, firewalls and critical applications, correlation will be blind.
3. Proactive threat hunting — 2-week cycles anchored in the MITRE ATT&CK framework with hypotheses such as “is T1078 Valid Accounts active in our environment?”. It catches what existing rules do not yet cover.
4. NDR (Network Detection and Response) — Darktrace, ExtraHop Reveal(x), Vectra AI, open-source Zeek + Suricata paired with the SIEM. Detects lateral movement and C2 traffic that EDR may miss (especially on unmanaged devices: IoT, OT, BYOD).
5. Deception technology / honeypots — Thinkst Canary, CounterCraft. Low-noise, high-fidelity alert source: any honeypot touch is by definition malicious activity.
6. 24/7 SOC instead of 8/5 — most attacks start outside business hours, on weekends or holidays. Without round-the-clock coverage, the MTTD for overnight incidents typically rises to 8-12h.

In addition: threat intelligence feeds (commercial or MISP), regular purple teaming, and adoption of Sigma rules as the standard for detection-rule exchange between teams.

How to improve MTTR

The control list for MTTR is longer because it covers the entire workflow from incident confirmation to service restoration:

1. SOAR playbooks — Tines, Cortex XSOAR, Splunk SOAR, Microsoft Sentinel automation rules. Every repeatable scenario (phishing report → block sender + search similar emails across other mailboxes + reset passwords for clickers) should have a playbook.
2. Automatic containment — EDR host isolation with one click or automatically once a risk score crosses a threshold. CrowdStrike Falcon, Defender for Endpoint and SentinelOne all support this.
3. Documented runbooks per incident type — ransomware, BEC (Business Email Compromise), insider threat, DDoS, web app compromise, supply chain. Each has a different workflow, escalation team and SLA.
4. Quarterly tabletop exercises — incident simulations with the executive team, legal, PR and the cyber insurer. They reveal communication gaps that during a real incident usually cost days.
5. DFIR retainer agreement — Mandiant, Kroll, CrowdStrike Services, Stroz Friedberg, Secureworks. SLA to start an engagement within 1-4h when the incident outstrips the in-house team. Without a retainer, contract negotiation in the middle of an incident typically costs 2-3 days.
6. Automated forensics tools — Velociraptor, GRR, KAPE for collecting artefacts from hundreds of endpoints in minutes instead of manual acquisition.
7. 24/7 SOC instead of 8/5 — as with MTTD, containment and recovery often require decisions in the middle of the night.
8. EDR ↔ SIEM ↔ SOAR ↔ ticketing integration — an alert should automatically create a ticket, enrich it with SIEM context, suggest a playbook, and after analyst approval trigger the containment action. Without integration, every alert becomes a manual pivot across 5 consoles.

Top mistakes in measuring MTTD/MTTR

1. Measuring MTTD from the first SIEM alert instead of from the event occurrence in the source logs. Produces an artificially low MTTD and hides detection-coverage gaps.
2. Conflating MTTR-Respond and MTTR-Recover into a single value. Very different processes, very different improvement levers. Split them in reporting.
3. Ignoring incidents that did not escalate to P1/P2. Shrinks the sample and creates a false sense of control — most attacks start as P3/P4 and grow over time.
4. No segmentation per attack type. MTTD and MTTR for phishing, ransomware, insider threat and DDoS typically differ by orders of magnitude. A blended average hides where the real problem is.
5. No previous-month / previous-quarter baseline for trend tracking. A single MTTD value says nothing on its own; the trend matters — is MTTD falling month over month, or rising?

A common bonus mistake: treating sector benchmarks as targets rather than as reference points. Your organisation has a different architecture, a different stack and a different threat landscape — compare yourself first to your own data from a year ago, and use sector benchmarks only as context for the board conversation.

Related terms

• MTTD (Mean Time To Detect) — full definition, historical sources and per-attack-type variants
• MTTR (Mean Time To Respond / Recover) — full definition and Respond vs Recover decomposition
• SOC (Security Operations Center) — organisational backdrop for both metrics
• SIEM — foundation of the detection layer, the direct driver of MTTD
• XDR — Extended Detection and Response, a key lever for both MTTD and MTTR
• EDR — Endpoint Detection and Response, alert source and automatic containment point
• Incident response — the end-to-end process that MTTD and MTTR measure
• Threat hunting — proactive lever for lowering MTTD

Explore our services

Want to improve MTTD and MTTR in your organisation? Check out:

• SOC 24/7 — detection and response with measured SLA on MTTD and MTTR
• Incident Response — incident readiness with a DFIR retainer
• Security audit — diagnosis of detection maturity and the IR process

MTTD and MTTR are not goals in themselves — they are health indicators of the Incident Response process. Organisations that treat them as KPIs without context (segmentation, baseline, decomposition) risk optimising the metric at the expense of real security. The best SOCs report these values as a quarterly trend with a breakdown per attack type, alongside qualitative measures (percentage of incidents detected proactively vs reactively, percentage closed with full eradication vs only containment).