Security teams cannot improve response speed until they agree on when response begins and ends. In its 2026 analysis, Mandiant found that the median interval from initial access to a secondary-actor hand-off fell from more than eight hours in 2022 to 22 seconds in 2025. Although that figure measures attacker hand-off rather than SOC response time, it shows why mean time to respond (MTTR) should track decision latency from a high-confidence detection to verified containment, not simply how quickly a ticket is closed.
What is mean time to respond?
Mean time to respond, commonly called MTTR, measures how long a security team takes to move from a confirmed or high-confidence threat detection to verified containment of the associated risk. It is most useful when it reflects the time an attacker can still act, rather than the time a ticket remains open.
Used well, MTTR reveals decision latency. Used poorly, it rewards rapid ticket closure while the threat remains active.
Define the response clock before you calculate it
There is no universal MTTR formula because teams use different start and stop events. A useful definition is consistent, auditable, and tied to risk reduction.
For most SOC reporting, start the clock when a qualified analyst or detection workflow identifies a high-confidence security event that requires response. Stop it when the team verifies that the immediate attack path has been contained, such as by disabling a compromised identity, isolating a host, blocking a malicious session, or revoking exposed credentials.
| Decision |
Recommended definition |
Why it matters |
| Start event |
High-confidence detection accepted for response |
Avoids penalizing teams for raw, low-quality alerts. |
| Stop event |
Verified containment of the active risk |
Keeps the metric tied to limiting attacker opportunity. |
| Include |
Confirmed incidents and qualified cases that required an action |
Makes the population meaningful. |
| Exclude, but track separately |
Test alerts, duplicates, closed false positives, and cases awaiting unrelated business decisions |
Prevents operational noise from distorting the number. |
| Report alongside |
Median, P90, severity, environment, and action type |
Shows typical performance and the difficult tail. |
Do not use final ticket closure as the stop event unless it reliably represents verified containment. Closure may include documentation, recovery work, lessons learned, or other tasks that should be measured separately.
How to calculate MTTR
For a defined reporting period:
MTTR = total time from the chosen start event to verified containment ÷ number of included incidents
For example, if 20 included incidents took a combined 100 hours from qualified detection to verified containment, MTTR is five hours. The calculation is simple. The rigor comes from using the same event definitions, inclusion rules, and data sources each time.
Do not report the mean alone. A few complex incidents can raise it sharply, while a seemingly healthy average can hide a dangerous group of slow cases. A practical dashboard includes:
- Mean, median, and P90 MTTR.
- MTTR by severity, incident type, environment, and business unit.
- The percentage of cases contained within the organization’s documented service objective.
- Time spent in triage, investigation, approval, execution, and verification.
- A list of outlier cases with the reason for the delay.
This approach converts one headline number into evidence about where the workflow needs attention. Teams should place MTTR within a broader set of cybersecurity metrics so response speed is evaluated alongside detection, investigation, remediation, and recovery.
MTTR and related security metrics
MTTR is often used inconsistently. Give each metric a distinct event boundary so leaders do not mistake faster detection for faster containment.
| Metric |
What it measures |
Recommended use |
| Mean time to detect (MTTD) |
Compromise or suspicious activity to detection |
Assess visibility and detection effectiveness. |
| Mean time to investigate (MTTI) |
Detection to an evidence-based determination |
Identify investigation bottlenecks. |
| Mean time to respond (MTTR) |
Qualified detection to verified containment |
Measure how quickly active risk is controlled. |
| Mean time to contain (MTTC) |
A closely related containment-specific measure |
Use when the stop event is explicitly containment. |
| Mean time to remediate |
Containment to removal of root cause and durable corrective action |
Track longer-term risk reduction. |
| Mean time to recover |
Incident impact to restored normal operations |
Track business and service restoration. |
This separation reflects the lifecycle in NIST’s incident-response guidance and the Detect, Respond, and Recover functions in the NIST Cybersecurity Framework 2.0. It also makes it possible to find the real problem. A long response time may originate in slow investigation, unclear approval authority, or an unreliable containment process.
For the broader workflow, see incident response. For a closer look at the evidence-gathering phase, see incident investigation.
Why a good MTTR is not a universal number
A two-hour MTTR is not automatically better than an eight-hour MTTR. A team dealing with a verified, high-severity identity compromise may need more validation and coordination than a team blocking a known malicious domain. Severity mix, telemetry coverage, change-control requirements, business-critical systems, and incident definitions all affect the result.
Compare MTTR over time within the same measurement design. Segment it before comparing teams or environments. Then look at the tail: P90 is often where missing permissions, unclear escalation paths, or manual handoffs become visible.
Detection must also be measured separately. Mandiant reported that global median dwell time increased from 11 to 14 days in 2025, while organizations first detected evidence internally in 52% of its investigations, up from 43% in 2024. Those figures are not response benchmarks, but they show why a fast containment workflow cannot compensate for a detection gap.
How to improve MTTR without creating unsafe automation
The goal is to shorten the time an attacker can act while preserving sound judgment. Start by finding which stage consumes time.
- Instrument the workflow. Capture timestamps for qualification, ownership, investigation, approval, action, and verification. Do not infer delay from ticket status alone. Clear SOC operations processes make these handoffs and ownership gaps easier to identify.
- Prioritize high-confidence attack signals. Better context helps analysts identify which cases deserve immediate action and reduces time spent validating duplicate or low-value alerts.
- Pre-authorize proportionate containment actions. Define which actions can be taken immediately, who can approve higher-impact actions, and how to reach them outside business hours.
- Automate bounded, reversible steps. Enrich cases, collect context, create tickets, or temporarily restrict a session when confidence and safeguards are sufficient. Keep irreversible or business-disrupting actions behind appropriate review.
- Review outliers. Every unusually slow case should identify a controllable cause, such as missing telemetry, ownership ambiguity, an approval queue, or a tool handoff.
For implementation guidance after the measurement model is in place, see incident response automation. Teams that need to improve cross-domain prioritization and response workflow can also explore Vectra AI’s threat detection and response use case.
The Vectra AI perspective
MTTR improves when responders can quickly understand which signals represent an active attack, where it is spreading, and what action is appropriate. Vectra AI helps security teams connect threat detection, investigation, and response across network, identity, and cloud environments, supporting a more informed response workflow. The metric remains the team’s governance tool: define its boundaries, inspect its outliers, and use it to improve decisions rather than merely accelerate closure.
