What is MTTR (Mean Time to Respond)?

MTTR starts the clock at detection, which is where MTTD stops (the MTTD entry covers the time before the alert). The clock stops when the analyst takes a response action that measurably changes the course of the incident:

• isolating an endpoint,
• blocking an IP or domain at the firewall,
• disabling a compromised account,
• killing a malicious process,
• or handing the case to incident response with containment already applied.

A false-positive closure also stops the clock, since ruling out a threat is itself a completed response.

The R is where teams disagree

Vendor glossaries define MTTR as mean time to respond, remediate, repair, or recover, and each one stops the clock at a different point.

• Respond stops at the first action that changes the incident's course.
• Remediate and resolve usually stop when the root cause is fixed and the ticket is closed, which can be days later.
• NIST defines mean time to recovery as the average time it takes to recover from a product or system failure, which is the IT operations meaning, and repair is the maintenance version of the same idea.

Before comparing your MTTR with another team's or a vendor report, find out which R they measure: a 20-minute respond MTTR and a 3-day remediate MTTR can describe the same incidents.

Consider a concrete case

A SIEM correlation rule fires at 14:02 on a host beaconing to a newly registered domain. The analyst opens the alert at 14:05, pulls the EDR process tree and confirms a PowerShell child process spawned from a Word document, checks the destination IP against threat intel and finds it flagged as C2 infrastructure, and isolates the host via EDR at 14:14. MTTR for this alert is 12 minutes, the window during which the attacker kept an active foothold after the SOC knew something was wrong.

Averaging works like any mean. Three incidents with response times of 12 minutes, 45 minutes, and 6 hours give an MTTR of about 2.3 hours, while the median is 45 minutes, so report the median and the 90th percentile alongside the mean.

MTTR breaks into phases an analyst can work on one at a time:

• assignment latency (how long an alert sits before someone picks it up),
• investigation (pulling logs and pivoting across SIEM, XDR, and firewall data),
• decision (is this a true positive, and what response is proportionate),
• and execution (issuing the isolation or block, which change control or clunky tooling can slow down).

Some teams track the first phase separately as mean time to acknowledge.

Microsoft Sentinel does not record the moment of the first response action, but its SecurityIncident table does record when each incident was closed. Microsoft's incident metrics guidance names two related measures, mean time to triage (FirstModifiedTime minus CreatedTime) and mean time to closure (ClosedTime minus CreatedTime), and its Security operations efficiency workbook charts both. Closure time is a proxy for MTTR in the remediate or resolve sense, not for the first response action: an incident can be contained in ten minutes and stay open two days for the write-up.

The table writes a new row on every update, so keep the latest row per incident with arg_max. ClosedTime holds the last closure, so a reopened incident shows its final close. Automation rules can close incidents on their own, so split the results by Classification, or auto-closed benign incidents will pull the median toward zero. For the last 90 days:

SecurityIncident
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status == 'Closed' and isnotempty(ClosedTime) and ClosedTime > ago(90d)
| extend CloseHours = (ClosedTime - CreatedTime) / 1h
| summarize Incidents = count(), MeanH = round(avg(CloseHours), 1), MedianH = round(percentile(CloseHours, 50), 1), P90H = round(percentile(CloseHours, 90), 1) by Severity, Classification
| order by Severity asc, MedianH desc

In the output, a High row whose P90 is several times its median usually means a handful of incidents waited on someone: an approver, another team, a change window. Those are the incidents to pull one by one. Benign positives that take longer to close than true positives point to a tuning problem more than a response problem, since an analyst is spending hours proving that a noisy rule fired on normal activity.

What brings MTTR down

Playbooks that say exactly which containment action fits which alert type, containment actions pre-authorized for the analyst on shift, and SOAR. In Sentinel, automation rules can tag, assign, or close incidents without a playbook, and playbooks built on Azure Logic Apps run response and remediation actions automatically or on demand, so the analyst validates evidence instead of assembling it.

What pushes it up

A second approver who is asleep, isolation that needs a change ticket, investigation steps that are still manual copy-and-paste between consoles, and alerts that arrive with no context.

Read MTTR by severity and alert type, never as a single blended number

A blended average across critical ransomware alerts and routine port-scan alerts hides the fact that critical incidents may already meet a tight target while a category of ambiguous alerts drags the average up. Segmenting by alert type shows where playbooks are missing or where investigation steps are still manual and repetitive, and those are the first candidates for automation.