SOC Metrics That Matter: MTTD, MTTR, and Beyond

Why most SOC dashboards measure the wrong things

Walk into a lot of security operations centers and the wall monitor shows one number in a very large font: alerts today. It feels like productivity. It is almost useless. A rising alert count can mean your detections are working, your tuning is broken, or an attacker is generating noise on purpose to bury the one event that matters. The count alone cannot tell you which.

The metrics that actually predict whether your team stops an intrusion are about time and coverage, not volume. They answer three blunt questions a board will eventually ask: How fast do we notice? How fast do we contain? And are we even looking in the places attackers operate? Everything below is built to answer those three questions in a way you can defend in an audit or a post-incident review.

The core time metrics, defined precisely

Loose definitions are where metrics programs go to die. If two analysts compute MTTR differently, the trend line is fiction. Pin these down in writing and make the start and stop events unambiguous.

• MTTD (Mean Time to Detect). From the moment malicious activity begins to the moment your tooling or an analyst first flags it. The clock starts at the adversary's first action in your environment, which you usually only learn after the fact from forensics — not when the alert fired.
• MTTA (Mean Time to Acknowledge). From alert generation to a human owning it. This isolates your triage and staffing, separate from investigation quality. A long MTTA at 3 a.m. is a coverage problem, not a skills problem.
• MTTR (Mean Time to Respond, or Resolve). The one everyone quotes and few define the same way. Decide explicitly whether "R" means respond (attacker contained, threat neutralized) or resolve (fully remediated and closed). These can differ by days. Report both if you can; never blur them into one number.
• Dwell time. From initial compromise to full eviction. It spans MTTD plus everything after. This is the single number most correlated with breach cost, because every extra day of dwell is another day for lateral movement, data staging, and exfiltration.

Figure: measure each stage separately — a great MTTR hides a slow MTTA, and blending them into one number tells you nothing about where to fix the process.

Report these as medians and 95th percentiles, not just means. A handful of weekend incidents that dragged on for days will pull an average far away from the typical case. The median tells you the normal experience; the 95th percentile tells you how bad your worst realistic day looks — which is the number an attacker is counting on.

Why raw alert counts mislead

Alert volume is an input metric masquerading as an outcome. It moves for reasons that have nothing to do with whether you are safer:

• A single noisy rule or a misconfigured log source can double your count overnight while adding zero security value.
• Suppressing or tuning out low-value alerts lowers the count, which looks like regression on a dashboard but is actually your team getting healthier.
• Attackers who "live off the land" using legitimate admin tools may generate almost no alerts at all, so a quiet day can be the most dangerous one.

Track alert volume only as an operational signal for capacity planning, never as a scorecard. The useful companion metric is alert-to-incident ratio: of everything that fired, how many became real incidents. If 10,000 alerts yield three incidents, your signal-to-noise is drowning your analysts, and that is a tuning project, not a hiring one. A modern security operations center is judged by how few alerts a human ever has to touch, not how many.

Detection coverage: are you even looking?

Fast response to the threats you can see says nothing about the threats you cannot. Coverage metrics close that blind spot, and the practical framework is MITRE ATT&CK. Map your detections to ATT&CK tactics and techniques, then measure the gap.

1. Inventory your detection rules and tag each to the ATT&CK technique(s) it covers.
2. Overlay your log sources. A detection for a technique is worthless if you are not collecting the telemetry it depends on. Coverage requires both the rule and the data.
3. Score coverage per tactic — Initial Access, Execution, Persistence, Lateral Movement, Exfiltration, and so on — so gaps are visible by category.
4. Validate with adversary emulation. Run atomic tests or a purple-team exercise and confirm the detection actually fires. A rule that exists but never triggers is a coverage illusion.

Beware of chasing "we cover 100 percent of ATT&CK." Breadth without depth is a vanity number; a shallow detection an attacker trivially evades still counts on the map. Prioritize techniques relevant to your industry and the ones observed in recent threat reporting, and pair coverage measurement with periodic penetration testing so an independent adversary validates what your dashboard claims.

The metrics that predict burnout

A SOC's throughput is capped by the health of its analysts, and two metrics predict when a team is heading for collapse.

• False-positive rate. The share of alerts that were never threats. High false positives are the leading driver of alert fatigue: when most alerts are noise, analysts start rubber-stamping them, and the one real detection gets closed at 4 a.m. with the rest. Industry surveys routinely put the fraction of alerts that go uninvestigated at roughly a third or more, precisely because of this. Every point you shave off the false-positive rate buys back attention for real work.
• Analyst touch rate and escalation load. How many alerts require human eyes, and how many escalate. If this only ever rises, automation and tuning are not keeping pace, and turnover will follow. SOC roles already carry some of the highest burnout in the industry; a metrics program that ignores the humans will optimize your team straight out the door.

The fix is disciplined tuning, enrichment, and automation of repetitive triage — often through managed MDR and XDR that absorbs the tier-1 volume so your people spend time on judgment calls, not noise.

Escalation SLAs: putting numbers under the process

Metrics without commitments are just observations. Escalation SLAs turn them into promises you can be held to, and they should scale with severity.

• Define severity tiers (for example, critical, high, medium, low) with explicit criteria, not gut feel.
• Set a time-to-acknowledge and time-to-respond target per tier. A critical alert might carry a target of minutes to acknowledge and well under an hour to contain; a low-severity one, hours.
• Track SLA attainment as a percentage, and review every miss. The misses are where your process actually lives.

Anchor these targets in adversary reality. Measured "breakout time" — how long from initial foothold to lateral movement — has been observed at roughly an hour on average, with the fastest intrusions moving in minutes. If your critical-alert response target is longer than your adversary's breakout time, your SLA is conceding the network. Wire these SLAs into your incident response plan so the clock and the runbook are the same system, not two documents that disagree under pressure.

Using metrics to improve, not to look busy

The failure mode of every metrics program is Goodhart's law: the moment a number becomes a target, people optimize the number instead of the outcome. Guard against it deliberately.

• Pair every efficiency metric with a quality metric. Chase MTTR down and you risk premature closures and reopened incidents; watch the reopen rate alongside it.
• Review trends, not snapshots. One month is noise. A six-month trend in dwell time or SLA attainment is signal. Tie each trend to a specific improvement — a new detection, a tuned rule, an added log source.
• Report to two audiences differently. Executives need dwell time, coverage, and financial exposure in plain language; the SOC needs MTTA, false-positive rate, and per-technique coverage to know what to fix Monday morning.
• Close the loop. Every post-incident review should propose a detection or tuning change, and the next coverage report should show it landed. That loop — measure, fix, re-measure — is the entire point.

Good metrics are not a report card you file and forget. They are a control system: they tell you where detection is blind, where response is slow, and where your analysts are drowning, so you can put resources exactly there.

If your dashboards are full of numbers that go up and to the right but nobody can say whether you would catch a real intrusion faster than last quarter, it may be time for an outside read. intSignal builds detection coverage, escalation SLAs, and the metrics that actually predict outcomes into our managed detection and response service. When you want a straight answer on how your SOC would perform under a real attack, talk to our security team.