What are MTTR and MTTD? SOC KPI Design and Practical Improvement

When management asks "Are our cybersecurity measures sufficient?", responding with a list of installed products or alert counts rarely satisfies them. To gauge the strength of a monitoring system, many organizations use time-based metrics such as MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond). However, these terms often have unstable definitions; chasing numbers without defining the start and end points of measurement can actually distort operations. This article clarifies the definitions and measurement methods for MTTD, MTTA, MTTR, and MTTC. After examining the importance of time metrics using public data, we explain the KPI framework for a SOC (Security Operations Center), common anti-patterns to avoid, operational improvements, and effective reporting strategies for executive management.

What are MTTD, MTTA, MTTR, and MTTC? Definitions and Measurement Methods

SOC time metrics change names depending on which phase of the incident lifecycle they measure. Within the flow of attacker intrusion (occurrence of malicious activity) → detection (alert generation) → acknowledgment (received by an analyst) → investigation/triage → containment → eradication/recovery → closure, these metrics represent the average or median elapsed time between two specific points.

MTTD (Mean Time to Detect)

The average time from the occurrence of a compromise or malicious activity until the organization detects it. While the strict starting point is the exact moment the attacker entered, this is often only discovered during post-incident forensics. Therefore, daily operations typically use the log timestamp or the moment a detection rule triggers in the SIEM (Security Information and Event Management) as the starting point. The "dwell time" published by Mandiant in M-Trends—the period between attacker entry and detection—is a similar concept to MTTD from the attacker's perspective.

MTTA (Mean Time to Acknowledge)

The average time from alert generation until an analyst acknowledges it and begins the investigation, measuring the waiting time before human (or automated) action starts. This metric spikes when no monitoring staff are present on nights/weekends, or when alert volume is too high, causing a backlog. Microsoft Sentinel's "Security operations efficiency" workbook calculates the difference between incident creation time and first update time as "Mean time to triage" (Microsoft Learn), which corresponds to MTTA.

MTTR (Mean Time to Respond/Resolve/Recover) — The Most Frequently Confused Metric

While MTTR is the most widely used acronym, it is also the most inconsistently defined. The "R" can stand for at least four different terms:

• Respond: From detection to the completion of initial response, such as containment

• Resolve: From detection to incident closure

• Recover: From detection to the return of operations and systems to a normal state

• Repair: Derived from IT operations and reliability engineering, from failure occurrence to repair completion

Even with the same "MTTR of 4 hours," the meaning differs completely depending on whether it refers to Respond (initial action completed) or Recover (business restored). It is common to find that an MSSP's SLA-defined MTTR measures a completely different phase than the internal MTTR. Just as Sentinel's workbook refers to the time from incident creation to closure as "Mean time to closure" (Microsoft Learn), the first step is to formally document what "R" refers to and which events signal the start and end points.

MTTC (Mean Time to Contain) and the Breach Lifecycle

The average time from detection to the completion of containment measures, such as network isolation of a host or account disablement. IBM's Cost of a Data Breach Report combines the days required to identify and contain a breach into the "breach lifecycle" to analyze its relationship with cost. Treating the sum of MTTD and MTTC as roughly equivalent to this lifecycle allows you to map internal metrics to industry benchmarks. For all metrics, if you do not document the four key variables—starting point, ending point, target population (all alerts vs. confirmed incidents), and aggregation method (mean vs. median)—it becomes impossible to distinguish true operational improvement from a mere change in measurement methodology.

Why Time Matters: The Relationship Between Breach Lifecycle and Costs

The reason time metrics are heavily emphasized is clear: the longer an attacker remains in an environment, the wider the scope of damage and the higher the recovery costs. Public data confirms this relationship.

According to the IBM Cost of a Data Breach Report 2025, the average time to identify and contain a breach was 241 days, a decrease of 17 days from the previous year. Organizations that extensively used AI and automation in security operations reported an average breach cost approximately USD 1.9 million lower and a breach lifecycle 80 days shorter than those that did not. Additionally, organizations that detected breaches themselves spent approximately USD 900,000 less than those alerted by the attacker (IBM, 2025). In the 2026 report, the global average cost of a breach reached approximately USD 4.99 million, a 12% increase from the previous year, and the cost gap between organizations using extensive AI and automation versus those using none was approximately USD 1.93 million (IBM, 2026).

According to Mandiant's M-Trends 2026, the global median attacker dwell time was 14 days in the 2025 survey, up from 11 days the previous year. However, the percentage of organizations that first detected malicious activity internally improved to 52%, up from 43% (Mandiant, 2026). The previous year's M-Trends 2025 illustrated that the median dwell time was 26 days when discovered via external notification, 10 days when detected internally, and 5 days when disclosed by the attacker (such as in ransomware extortion) (Mandiant, 2025). Internal detection is the single most critical factor in minimizing dwell time.

The speed of the adversary is particularly notable. M-Trends 2026 reports that the median time for an attacker to hand off initial access to another threat group shrank from over 8 hours in 2022 to just 22 seconds in 2025 (Mandiant, 2026). In an era where intrusion and ransomware deployment are highly specialized and automated, a decisive gap in impact emerges between organizations operating on a scale of "days" versus "minutes" for detection and response. The IPA's "10 Major Information Security Threats 2026" also ranks ransomware damage as the top threat for organizations (IPA, 2026). For enterprises, this race against the clock is highly relevant. Time metrics must be treated not merely as measures of SOC operational efficiency, but as risk indicators directly tied to business impact.

The SOC KPI Framework: Five Core Pillars

Focusing solely on time metrics makes it easy to fall into operational anti-patterns. A SOC's KPIs must combine multiple perspectives to reflect reality. We organize these into five pillars.

Quantity Metrics

These include received alert volume, incident volume, the percentage of investigated alerts (investigation rate), and unprocessed backlogs. These are essential for understanding workload but should not be targets in themselves. The investigation rate is often overlooked; if only a fraction of alerts are investigated, any reported MTTD is merely the "MTTD for investigated alerts."

Quality Metrics

These include false positive rates (alerts found to be benign after investigation), true positive rates, escalation accuracy (the percentage of escalated cases that actually required action), reopen rates after closure, and recurrence rates of similar incidents. Quality metrics serve as a check on time metrics; if MTTR drops but the reopen rate rises, the depth of investigations may be insufficient.

Time Metrics

The aforementioned MTTD, MTTA, MTTR, and MTTC. In practice, it is critical to report medians and percentiles (such as the 90th percentile, where 90% of cases are completed within that time) alongside means. A few long-running incidents can skew the average, while medians alone can mask the outliers. Sentinel's operational efficiency workbook provides triage and closure percentiles by default (Microsoft Learn). It is standard practice to segment these metrics by severity (Critical, High, Medium, Low) and set tighter targets for higher severities.

Coverage Metrics

These include the percentage of monitored assets with EDR (Endpoint Detection and Response) deployed, the proportion of expected log sources ingested into the SIEM, log retention periods, and detection rule coverage against the MITRE ATT&CK framework. These metrics visualize blind spots and serve as prerequisites for MTTD. M-Trends 2026 notes that standard 90-day log retention policies are insufficient to trace initial access paths or the scope of compromise for threats with dwell times reaching nearly 400 days (Mandiant, 2026). Including log retention periods in coverage KPIs is highly valuable.

Maturity Metrics

These include the percentage of incident types covered by documented playbooks, the automation rate of primary investigations, the execution rate of post-mortems, the completion rate of corrective actions, and the frequency of tabletop exercises. NIST SP 800-61 Rev. 3 (published April 2025) requires integrating incident response into overall cybersecurity risk management and recommends regular evaluations of incident response program performance to identify issues and deficiencies (NIST, 2025). Maturity metrics operationalize these periodic evaluations.

You do not need to measure all five pillars perfectly from day one. Refer to cross-industry reports like the SANS SOC Survey to identify common indicators, narrow your focus to 5–10 metrics aligned with your risk profile and operational stage, and establish a baseline. The core roles and structures of a SOC are covered in "SOCとは？役割・Tier体制・24時間365日運用の基本と限界" (Japanese).

KPI Anti-Patterns: Volume Chasing and Closure Obsession

When designed incorrectly, KPIs can distort analyst behavior rather than improve operations. Below are common patterns observed in SOCs.

Evaluating throughput as productivity. When ticket volume is a primary performance metric, analysts prioritize easy-to-close alerts over complex, high-risk investigations. Volume may increase, but if critical alerts are deferred, organizational risk remains unmitigated.

Chasing MTTR reduction at the expense of quality. If MTTR (Resolve) is managed with rigid targets, pressure builds to close tickets quickly as "false positives" without sufficient investigation. This leads to rising false positive and reopen rates, often culminating in the discovery that a previously closed alert was actually the initial indicator of a compromise. Time metrics must always be paired with quality metrics.

Relying solely on averages. Averages are easily skewed by a few extreme cases. Conversely, a healthy average can mask a terrible 90th percentile, indicating that some incidents are left unaddressed for long periods. Reporting only averages without showing the distribution leads to a misjudgment of risk.

Calculating MTTD based only on detected incidents. MTTD is a statistic of "detected incidents" and does not account for compromises that went unnoticed. If most breaches are discovered through external notifications, a low MTTD is misleading because the core detection capability is failing. It is healthy to pair MTTD with metrics like the "internal detection rate" and transparently report externally notified cases.

Comparing metrics without standardizing measurement points. Comparing an MSSP's reported MTTR with your internal MTTR, or comparing this year's MTTD with last year's using different start and end definitions, is meaningless. Create a metric definition document and maintain a change history. As Goodhart's Law suggests, "When a measure becomes a target, it ceases to be a good measure." Treat KPIs as diagnostic tools for improvement rather than tools for control, and establish targets based on a balance of multiple metrics.

Operational Steps to Improve KPIs: Log Coverage, Automated Triage, Playbooks, and Post-Mortems

Improving KPIs requires identifying and resolving the specific bottlenecks associated with each phase. Here are practical steps to improve time and quality metrics.

Establish the Measurement Infrastructure

The first step is to automate metric calculation. Manual tracking is unsustainable and leads to inconsistent definitions over time. Configure your SIEM or ticketing system to automatically log creation, acknowledgement, containment, and closure times, along with severity and classification (true positive vs. false positive). For Sentinel, the official documentation demonstrates how to query the SecurityIncident table—which appends records on creation and updates—to calculate time differences (Microsoft Learn). Other SIEMs can implement similar logic.

Improve MTTD Through Log Coverage and Correlation

The most effective lever for reducing MTTD is log availability rather than fine-tuning detection logic. If logs from endpoints, identity providers, cloud environments, network boundaries, and SaaS applications are not consolidated and correlated within the SIEM, critical alerts will be lost in the noise. The methodology for identifying the full scope of an attack is covered in "ログの相関分析はなぜ重要か" (Japanese). Focus first on improving coverage KPIs (log ingestion rates and EDR deployment rates); MTTD improvements will follow naturally.

Improve MTTA and Investigation Rates via Automated Triage

The bottleneck for MTTA and investigation rates is almost always a backlog of manual tasks. Automating initial triage—such as alert deduplication, enrichment with asset and threat intelligence, and correlation with historical alerts—allows analysts to focus immediately on cases requiring human judgment. For details on maintaining accuracy, see "アラートトリアージの自動化：AIエージェントによる一次調査の手順と精度の担保" (Japanese). The success of automation should be measured not only by lower MTTA but also by higher overall investigation rates.

Reduce MTTC with Playbooks and Response Workflows

Delays in containment are rarely technical; they are usually organizational, caused by a lack of clear decision-making authority. Because host isolation or account suspension impacts operations, decision criteria, authority, and communication paths must be documented in playbooks beforehand. Without this, response halts during nights and weekends. This flow is detailed in "インシデント初動対応とSOCの連携：検知から封じ込めまでの実務ランブック" (Japanese). Playbook coverage and the ratio of automated containment actions serve as leading indicators for MTTC improvement.

Translate Metrics into Learning via Post-Mortems

NIST SP 800-61 Rev. 3 emphasizes consolidating lessons learned into continuous improvement, analyzing and prioritizing feedback across all security functions (NIST, 2025). From a KPI perspective, this means decomposing every major or prolonged incident to identify where time was spent (detection, acknowledgment, or decision-making) and feeding those findings back into detection rules, playbooks, or automation. Tracking the completion rate of these action items as a maturity KPI prevents post-mortems from becoming mere administrative exercises.

How AI SOC Transforms KPIs

Traditional SOCs struggle to resolve the structural limits of manual alert triage and human bandwidth. Expecting human analysts to investigate every alert with consistent quality 24/7/365 is unrealistic. An AI SOC, which leverages autonomous AI agents to investigate and respond to alerts, directly addresses this limitation. The architecture and its differences from traditional SOCs are explained in "AI SOCとは？仕組み・従来型SOCとの違い・導入メリットをわかりやすく解説" (Japanese).

From a KPI perspective, an AI SOC impacts three primary metrics. First are MTTA and investigation rates: it eliminates waiting times and unprocessed backlogs through automated primary triage. Second is MTTR: because automation of triage alone does not dictate complete resolution times, you must track the approval, containment, and recovery phases separately. Third are quality metrics: the Yagura AI SOC uses context memory to leverage environment-specific knowledge, supporting analyst decisions. Evaluation should include false positive classification accuracy, escalation precision, and any time required for human review. Measuring how much manual effort is saved to allow for threat hunting and post-mortems requires evaluation within your specific environment.

Note that an AI SOC cannot improve MTTD if log coverage is deficient, nor can it fully optimize MTTC if containment criteria are not defined in playbooks. An AI SOC is a highly effective tool for improving time, quantity, and quality metrics, but coverage and maturity remain responsibilities of the organization. When evaluating adoption, we recommend running a PoC to compare performance against your own KPI definitions rather than relying on generic benchmarks.

Executive Reporting: Presenting KPIs to Management

Once KPIs are established, the final challenge is presenting them to management. Executive teams cannot make decisions based on raw technical metrics. Structure your reporting into three distinct layers: Risk, Operations, and Improvement.

• Risk Layer (for Board and Executive Meetings): Critical incident volume, MTTD/MTTC median and 90th percentile trends, externally notified incidents, and monitoring coverage (EDR/log ingestion rates). This demonstrates how quickly the organization can detect and stop threats.

• Operational Layer (for the CISO and IT Directors): Alert volume and investigation rates, backlogs, false positive rates, MTTA/MTTR by severity, and escalation accuracy. This shows whether the security operations program is running effectively.

• Improvement Layer (for Security Teams): Automation rates, playbook coverage, post-mortem action completion rates, and MITRE ATT&CK rule coverage. This defines concrete areas for operational improvement.

When reporting, focus on trends over time rather than isolated data points, document definitions in footnotes, and translate time metrics into business impact. Aligning internal metrics with industry baselines—such as a global median dwell time of 14 days (Mandiant, 2026) or an average 80-day reduction in the breach lifecycle via AI and automation (IBM, 2025)—helps contextualize your performance. In regulated industries like finance or defense supply chains, having precise timestamps for detection and containment is critical for compliance and accountability. Finally, never hide poor metrics. Honest reporting of externally detected incidents or prolonged response times, paired with a root-cause analysis and an improvement plan, builds credibility and secures budget. KPIs are not a scorecard; they are a shared language for managing organizational risk.

Summary

MTTD, MTTA, MTTR, and MTTC measure distinct phases of the incident lifecycle; without clear definitions of starts, ends, populations, and calculation methods, they cannot be used for comparison or improvement. Industry data shows that the time required to identify and contain a breach directly impacts cost, that internal detection limits dwell time, and that attacker speed is down to seconds. Design your KPI program across five pillars—quantity, quality, time, coverage, and maturity—while avoiding anti-patterns like volume chasing or rushing closures. Improve these metrics systematically through log coverage, automated triage, playbooks, and post-mortems. While an AI SOC significantly optimizes time, quantity, and quality, coverage and maturity remain organizational priorities. Begin by defining your metrics and establishing a baseline for measurement.

Related Service: To learn more about Yagura AI SOC, which uses autonomous AI agents to investigate and respond to EDR and SIEM alerts 24/7/365 to improve MTTR and investigation rates, click here.

References and Sources

• IBM, "Cost of a Data Breach Report 2026" (2026): https://www.ibm.com/reports/data-breach

• IBM Newsroom, "IBM Report: 13% of Organizations Reported Breaches of AI Models or Applications, 97% of Which Reported Lacking Proper AI Access Controls" Cost of a Data Breach Report 2025 Press Release (July 30, 2025): https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls

• Mandiant / Google Cloud, "M-Trends 2026" (March 23, 2026): https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

• Mandiant / Google Cloud, "M-Trends 2025" (April 23, 2025): https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025

• NIST, "SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile" (April 2025): https://csrc.nist.gov/pubs/sp/800/61/r3/final (PDF: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf)

• Microsoft Learn, "Manage your SOC better with incident metrics" Microsoft Sentinel Documentation (Accessed September 2026): https://learn.microsoft.com/en-us/azure/sentinel/manage-soc-with-incident-metrics

• IPA, "10 Major Information Security Threats 2026" (Published January 29, 2026): https://www.ipa.go.jp/security/10threats/10threats2026.html

• MITRE, "MITRE ATT&CK" (Accessed September 2026): https://attack.mitre.org/

• SANS, "SANS 2025 SOC Survey" (2025): https://www.sans.org/white-papers/sans-2025-soc-survey/