Security Operations Metrics Guide: MTTD, MTTR and SOC KPIs

Most SOC metrics programmes report numbers nobody has defined, measured from timestamps nobody trusts, and the result rewards closing alerts quickly rather than catching attackers. MTTD and MTTR appear on almost every SOC dashboard, yet two SOCs reporting "MTTR of four hours" can mean acknowledgement, containment or full recovery. This guide goes deeper than the metrics section of the SOC Guide: it defines each time-based metric against a single incident timeline, shows how to calculate them so they survive scrutiny, covers alert quality, detection efficacy and analyst capacity measures, and explains how to build a SOC dashboard and report SOC KPIs to leadership without encouraging gaming. It is written for SOC managers, detection engineers and security leaders who own or consume security operations metrics (often called SecOps metrics or SOC performance metrics).

Key takeaways

• Anchor every metric to one timeline. Define the start and stop timestamps for dwell time, MTTD, MTTA, triage, investigation, containment and recovery once, and compute all of them from the same case records.
• Report medians and the 90th percentile, by severity. Incident durations are heavily skewed; a mean hides both the routine and the disasters.
• Speed metrics need a quality partner. Pair every time metric with a quality check, such as escalation accuracy or a sample of closed alerts, or analysts will learn to close fast rather than right.
• Coverage must be tested, not counted. Detection efficacy is the share of emulated techniques the SOC actually detected, not the number of rules in the SIEM.
• Containment is not complete until credentials are. For identity-led incidents, mean time to contain should stop only when every exposed session, token and key is revoked or rotated.

One incident timeline, eight time metrics

Time metrics disagree because teams start and stop the clock at different points. Fix the timeline first, record each timestamp as a separate field in the case management system, and derive every metric from those fields.

The NIST CSF 2.0 Respond function maps cleanly to these stops: "Incident reports are triaged and validated" (RS.MA-02), "Incidents are categorized and prioritized" (RS.MA-03), "Incidents are contained" (RS.MI-01) and "Incidents are eradicated" (RS.MI-02). Using those outcomes as the case states makes the metrics auditable against a recognised framework.

Calculating time metrics that survive scrutiny

• Use the median and p90, not only the mean: one six-month intrusion can triple a quarterly mean. Show the median for the typical case and the 90th percentile for the tail, by severity.
• Segment before you average: separate severities, incident types (phishing, malware, identity compromise, insider) and detection source. A phishing-heavy quarter will look fast and tell you nothing about intrusions.
• Separate internal from external detection: incidents reported by a third party, a regulator or the attacker (ransom notes) usually have the longest dwell time. Excluding them flatters MTTD; report the share of incidents the SOC found itself.
• Handle open cases: an incident still uncontained at quarter end is excluded from a naive MTTC. Report the count and age of open incidents alongside, or the metric improves when containment stalls.
• Trust the clocks: synchronise log sources to one time source, store timestamps in UTC, and record event time and ingestion time separately so pipeline delay is visible.
• Small samples: a SOC with five confirmed incidents a quarter should report each one, not a mean. Trend over four quarters or more before drawing conclusions.

Benchmarking dwell time

External figures give context, not targets. Mandiant's M-Trends 2026, based on its 2025 investigations, reports that "Global median dwell time rose to 14 days from 11 days", with a median of 122 days for cyber espionage and North Korean IT worker cases, and that organisations first detected malicious activity internally 52% of the time, up from 43% in 2024. It also reports that the median time from initial access to hand-off to a second threat group fell from more than eight hours in 2022 to 22 seconds in 2025. Two lessons follow: report your own internal detection rate next to mean dwell time, and do not treat a dwell time measured in days as success when the attacker's next step takes seconds.

Alert quality and efficiency metrics

SOC efficiency metrics, volume and speed, are only meaningful alongside quality. All of these depend on a consistent disposition taxonomy: true positive, benign true positive (correct detection of authorised activity), false positive, and undetermined.

The NCSC's detection guidance supports pruning: the SOC should be "(cautiously) open to simply removing alerts that have high false positive rates", while remembering that "just because a use-case has not fired, does not mean it is invalid". Tune with tightly scoped exclusions; the NCSC warns that allow-listing must be "strongly object/time bounded" or it becomes an evasion route.

Detection efficacy and coverage

Detection efficacy answers the question leadership actually cares about: if an attacker did this, would we see it? Measure it by testing, not by inventory.

• Tested coverage: the share of prioritised ATT&CK techniques with an analytic that fired in a test within the last 12 months. ATT&CK detection strategies, which "define high-level approaches for detecting specific adversary techniques", give a structure for mapping analytics to techniques.
• Detection rate in exercises: techniques detected / techniques executed in red or purple team exercises and breach and attack simulation runs. The NCSC's bar is that "ideally your SOC would have detected all of the red team activity".
• MTTD in exercises: time from emulated action to alert. Unlike production MTTD, it has a known start time and a large enough sample to trend.
• Data source health: percentage of required log sources reporting within expected latency. A rule against a silent source is zero coverage.
• Detection-as-code test pass rate: analytics with an automated test that passes on each change. See the Detection Engineering Guide.

Capacity: analyst utilisation and workload

Analyst utilisation (analyst utilization in US usage) is the share of paid time spent on queue work. A SOC running analysts near 100% has no slack for surges, hunting, tuning or training, and quality falls first. Many SOC managers plan queue work at well under full utilisation and protect the remainder for improvement work; agree a target locally and track it with time recording or case effort fields rather than estimates.

• Alert volume per analyst: trend it against MTTA and escalation accuracy. Rising volume with stable accuracy means tuning or automation is working; rising volume with falling accuracy means overload.
• Time to independent shift work: months from hire to working a shift unsupervised, a leading indicator for staffing plans.
• Attrition: leavers per year; it predicts falling quality months before the queue metrics show it.
• Automation share: alerts enriched or closed by automation with a sampled error rate. See the SOAR and Security Automation Guide.

Security MTTR and the TPV-MTTR gap

"Security MTTR" is used for two different things: incident response time in the SOC, and vulnerability remediation time in IT. Keep them apart on the dashboard and label each. Where they meet, NHI Mgmt Group's glossary describes the TPV-MTTR gap (TPV MTTR gap) as "the distance between how quickly a patch is deployed and how quickly a live issue is contained". Track it for vulnerabilities under active exploitation: if patch validation and deployment take 20 days while the SOC can contain exploitation in hours, compensating detections and containment playbooks carry the risk for those 20 days, and the SOC should know which assets are in that window. See the Vulnerability Management Guide.

Where identity fits

Many intrusions now run on valid credentials: stolen passwords, session cookies, OAuth tokens and leaked API keys. For these incidents the usual containment action, isolating a host, does nothing. Define identity-specific stops for MTTC:

• Human accounts: password reset, all sessions and refresh tokens revoked, MFA methods reviewed.
• Non-human identities: every exposed API key, service account credential, certificate and secret rotated, and the old value confirmed unusable.
• Third-party access: OAuth grants and integration tokens for the affected application revoked.

Measure "time to full credential revocation" as its own metric. The Cloudflare breach shows why: credentials left unrotated after the earlier Okta support system breach later let an attacker in, so the earlier response had not fully contained the exposure. See the ITDR Guide.

SOC dashboard and SOC reporting to leadership

MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center (Strategy 10, "Measure Performance to Improve Performance") separates measures for internal SOC use, measures that show the SOC's value and status to stakeholders, and findings about the wider organisation's security, and warns that "Not all measures result in positive outcomes". Build one dashboard per audience from the same data.

• Lead with outcomes: for leadership, the share of emulated ransomware precursor techniques detected this quarter against last quarter lands better than an alert count.
• Explain movement: every trend line needs a sentence on why it moved and what you are doing about it.
• Show regulatory clocks: where NIS2 applies, report time from detection to the 24-hour early warning and 72-hour notification. See the NIS2 Directive Guide.
• Never show raw alert volume as a success measure: more alerts is not more security.

Decision guidance: choosing the right set

• Small SOC (a handful of analysts or a single shift): confirmed incidents are too few for meaningful means. Track MTTA and time to triage for alerts, report each confirmed incident individually with its timeline, and get detection efficacy from an annual purple team exercise.
• Large or 24x7 SOC: enough volume for percentiles by severity and incident type. Add per-rule true positive rates, analyst utilisation by shift and quarterly emulation testing, and give detection engineering its own metrics.
• Outsourced or hybrid SOC: provider contracts usually set service levels on acknowledgement and notification time, which the provider controls. Add outcome measures you can verify: escalation accuracy, exercise detection rate, and time from provider notification to your own containment, which is often the longest interval.
• Speed versus quality trade-off: when a target forces a choice, prefer the quality metric. A slower MTTA with high escalation accuracy is safer than a fast queue that closes real intrusions.

Implementing a SOC metrics programme

1. Agree definitions. Publish a one-page metric dictionary with the timeline table above, disposition codes and severity definitions, approved by the SOC manager and incident response lead.
2. Instrument the case system. Add mandatory timestamp fields (first malicious event, detection, acknowledged, triaged, declared, contained, eradicated, recovered), disposition and detection source. Backfill nothing you cannot verify.
3. Baseline for 90 days. Collect without targets so analysts do not adjust behaviour before you understand normal.
4. Add quality controls. Sample a fixed percentage of closed alerts each month for second review; report reopen rate and escalation accuracy next to every speed metric.
5. Pilot the dashboards. Run the team and manager views for one quarter, fix data quality issues, then introduce the leadership view.
6. Set targets carefully. Set targets on outcome and quality metrics (internal detection share, tested coverage, MTTC p90) rather than on throughput metrics such as alert closure rate.
7. Review and retire. Review the set quarterly as NIST CSF 2.0 GV.OV-03 expects ("performance is evaluated and reviewed for adjustments needed"). If a metric is driving bad behaviour, retire it publicly; that is the rollback.

Framework mapping

For how to select and specify measures generally, NIST SP 800-55 Vol. 1 (December 2024) covers identifying and prioritising measures that show "the adequacy of in-place security policies, procedures, and controls".

Common failure patterns

• Time-to-close targets: analysts close ambiguous alerts as false positives to hit the number, and the true positive rate quietly falls.
• Undefined MTTR: the board sees "MTTR four hours" while incident response means acknowledgement and IT means recovery; nobody notices until a major incident takes weeks.
• Means on skewed data: a single long intrusion swings the quarter, so the trend line reflects luck rather than performance.
• Counting rules as coverage: hundreds of untested rules against log sources that stopped reporting months ago.
• Early containment declarations: the incident is closed when the host is reimaged while the stolen token or key stays valid.
• Excluding externally reported incidents: the worst cases fall outside MTTD, so the metric improves as detection gets worse.

Practitioner checklist

• Publish a metric dictionary with one incident timeline and fixed start and stop points.
• Capture each timestamp as a mandatory case field, in UTC, with event and ingestion time kept separate.
• Report medians and p90 by severity and incident type, plus open incident count and age.
• Report internal detection share next to MTTD and dwell time.
• Pair every speed metric with a quality metric and a monthly sample of closed alerts.
• Measure detection efficacy through red, purple or emulation exercises at least twice a year.
• Stop the MTTC clock for identity incidents only when all sessions, tokens and keys are revoked or rotated.
• Track analyst utilisation and protect time for tuning, hunting and training.
• Give leadership four to six KPIs with trend and narrative each quarter.

Standards and references

• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• NCSC: Building a SOC, Detection practices
• MITRE ATT&CK: Detection Strategies
• Google Cloud (Mandiant): M-Trends 2026, Data, Insights, and Strategies From the Frontlines

Related NHI Mgmt Group resources: SOC Guide · SOC Maturity Model · Top 10 SOC Challenges · Incident Response Guide · SIEM Guide