MTTD and MTTR in Cybersecurity: How to Measure and Improve

What MTTD and MTTR Actually Measure

Mean Time To Detect (MTTD) is the average elapsed time between the start of a security incident (initial compromise, anomaly, malicious activity) and the moment the security team detects it. The clock starts when the adversary first acts inside your environment. The clock stops when an alert reaches an analyst who recognises it as worth investigating.

Mean Time To Respond (MTTR) is the average elapsed time between detection and full response. Mature SOCs split MTTR into more granular metrics: Mean Time To Triage (MTTT, alert received to analyst engaged), Mean Time To Investigate (MTTI, triage start to root cause identified), Mean Time To Contain (MTTC, investigation complete to containment achieved), and Mean Time To Recover (MTTR proper, containment complete to normal operations restored). At simpler SOCs, MTTR covers everything from detection to recovery.

The metrics matter because every minute of undetected adversary access is data accessible, more systems compromised, more lateral movement, more damage. IBM's Cost of a Data Breach annual report consistently shows that breaches contained in under 200 days cost roughly USD 1 million less on average than breaches contained beyond that threshold. The dollar value of MTTD and MTTR reduction is measurable.

Industry Benchmarks and What 'Good' Looks Like

IBM's Cost of a Data Breach 2024 report shows global mean MTTD around 194 days and MTTR around 64 days for breaches that result in disclosed incidents. Indian organisations average similar (slightly worse on detection in regulated sectors, slightly better in tech-forward sectors). These numbers represent the long-tail; the median for organisations with mature SOCs is meaningfully lower.

Codesecure's own benchmark observations across Indian customers with managed SOC services: ransomware (often pre-encryption dwell time of 14 to 60 days for unprepared organisations, 1 to 7 days for organisations with EDR and active hunting), BEC (median 7 to 21 days to detection for organisations relying on user reports, hours to days with email-stream analytics), insider threat (notoriously hard, often months without DLP and behaviour analytics).

World-class targets: MTTD in hours for endpoint-originated attacks (EDR plus active threat hunting), days for cloud or network-originated attacks (SIEM plus cloud detection plus log correlation). MTTR target: hours for containment of well-understood incident classes (ransomware on a known endpoint, brute force on an exposed service), days for full recovery of complex incidents.

What Inflates MTTD

MTTD lengthens for predictable reasons. Address them in priority order.

• Untuned, noisy SIEM: thousands of low-fidelity alerts per day, analysts learn to ignore, real signal buried. The biggest single MTTD driver.
• Telemetry blind spots: missing EDR on a subset of endpoints, missing cloud trail, missing DNS logs, missing east-west traffic visibility. Adversary uses the blind spots.
• Slow triage workflow: alert reaches analyst, analyst has to context-switch from ticket queue, opens five tabs to understand the alert, manually pivots between SIEM, EDR, ticketing.
• No threat hunting: SOC purely reactive. Adversaries who bypass detection rules stay invisible until they cause obvious damage.
• Out-of-hours coverage gaps: 16x5 SOC where adversaries operate 24x7. Most ransomware encryption events fire on Friday night or weekend.
• Detection content rot: rules written in 2021, not updated for current adversary TTPs. MITRE ATT&CK coverage drifts.
• Alert fatigue: high false-positive rate causes analysts to dismiss alerts unconsciously. Real positives get the same dismissal.

How to Reduce MTTD

Reducing MTTD is a programme, not a project. The recurring high-impact moves: deploy EDR on every endpoint (this single change typically halves MTTD for endpoint-originated incidents), close telemetry gaps with a clear logging plan, invest in detection engineering as a discipline (a named team writing and tuning detections continuously), adopt MITRE ATT&CK as the framework for measuring detection coverage, run regular purple team exercises to validate detection in practice, and add active threat hunting as a regular cadence (weekly or monthly hypothesis-driven hunts).

SIEM tuning specifically: review the top 20 noisy alerts every month, suppress or tighten the false-positive sources, archive alerts with zero true-positive in 90 days, escalate alerts with low true-positive count for re-engineering. The goal is an alert-to-incident ratio that makes the analyst engagement meaningful, not a high alert volume that buries the signal.

Out-of-hours coverage: 24x7 in-house SOC for organisations large enough, MDR (managed detection and response) service for organisations that cannot justify in-house 24x7. The MDR market has matured significantly since 2020; Codesecure helps clients evaluate and select.

How to Cut MTTR with SOAR and Automation

MTTR responds well to automation. Routine response steps that humans execute slowly (or inconsistently) are perfect for SOAR. Examples: isolate endpoint from network via EDR API, disable user account in IdP, rotate API key, block IP at firewall, quarantine email across mailboxes, snapshot affected resource, kick off Velociraptor collection. Each of these can be a single playbook step, executed in seconds, with full audit trail.

SOAR platforms (Splunk SOAR, Microsoft Sentinel Logic Apps, Palo Alto XSOAR, Tines, n8n for custom builds) wire detection signals to response playbooks. Most modern SOCs target 60 to 80 percent of routine response actions automated, with the remaining percent reserved for analyst judgement and high-stakes containment. Our companion case study on SOAR transformation walks through a specific Indian fintech where MTTR dropped from 4 hours to 12 minutes for the top five alert classes after a 10-week SOAR engagement.

Beyond SOAR: runbooks per alert class so analysts do not improvise, pre-authorised containment actions (the SOC has standing authority to disable a confirmed-compromised account without paging the IR lead), integrated case management so the analyst does not move between tools, and post-incident review that feeds detection content and playbook updates back into the SOC.

Dashboards, KPIs and Reporting

Reporting MTTD and MTTR honestly is hard. The temptation is to game the numbers by changing the start time of the clock, or by counting only incidents that were detected (the ones that were not detected do not appear in MTTD by definition).

Sensible practice: report MTTD against confirmed incidents only, with a separate metric for 'missed incidents' identified retroactively through threat hunting or after-the-fact disclosure. Report MTTR with the breakdown (triage, investigate, contain, recover) so improvements are attributable. Trend over time, not point-in-time, because monthly noise can mask both improvement and degradation. Compare against industry benchmarks (IBM, Verizon DBIR, Mandiant M-Trends) to give the board external context.

Codesecure helps SOC customers stand up KPI dashboards in their SIEM (Sentinel workbooks, Splunk dashboards, Elastic Kibana, Chronicle dashboards). The dashboard is one input; the discipline of acting on the trend is the actual control.

Improving Metrics Without Inducing Alert Fatigue

The classic failure mode: a security leader wants better MTTD, the SOC enables every rule in the SIEM, alert volume explodes, analyst fatigue sets in, real positives get missed, MTTD gets worse than before. Volume is not the answer; precision is.

Sustainable improvement: detection engineering as a discipline (write a rule, measure true-positive and false-positive rate, iterate), tiered alert handling (low-fidelity to automation, high-fidelity to analyst), suppression of known-benign sources (CI/CD pipeline activity, scheduled scans, predictable admin behaviour), and contextual enrichment so the alert arrives with the analyst already half-investigated. Analysts who have time to think well are the most reliable MTTD and MTTR improvement lever any SOC has.