QuietHours by securITDiscuss your scope

Operations

SOC metrics that matter: from alert volume to investigation quality

Most SOC dashboards measure throughput. Throughput tells you how busy the team is. It says almost nothing about whether the next real intrusion will be caught, and it can improve while your security position gets worse.

Minimalist measurement grid with a single accented point

A SOC that closes 40,000 alerts a month with a 99.7% closure rate looks excellent on a slide. It is also perfectly consistent with a team that has tuned out the detections that would have caught the intrusion currently in progress. Volume metrics are activity metrics, and activity is not the outcome you are buying.

The metrics that mislead

MetricWhat it appears to showHow it goes wrong
Alerts processedTeam productivityRises when detections get noisier; a noisy SOC scores well
Alert closure rateEfficiencyOptimised by closing quickly, which is the opposite of investigating
Mean time to detectDetection speedAveraged over trivial alerts; the one that mattered is lost in the mean
False positive rateDetection accuracyImproved by deleting sensitive detections, not by better tuning
Uptime of the SIEMReliabilityThe platform can be up while a critical log source is silent

Metrics that actually predict performance

1. Detection coverage against a technique framework

Map your detections to MITRE ATT&CK techniques relevant to your environment and threat profile, and track coverage as a percentage with a confidence level per technique. This is the only metric that tells you what you cannot see. It should be reviewed quarterly, and it should get worse when your environment changes — if it never does, nobody is actually re-checking it.

2. Log source health, measured as silence

Track expected event volume per source with an alert when volume drops below a floor. A source that stops sending is invisible in every other metric and is one of the most common causes of a missed incident. Measure the time between a source going silent and someone noticing; if you have never measured it, the number will be uncomfortable.

3. Time to escalate a true positive

Not time to detect across all alerts. The time between a genuinely malicious event entering the pipeline and a human deciding it is real and escalating it. This is the number that determines whether you can meet a 24-hour regulatory notification obligation, and it can only be measured honestly through exercises or real incidents.

4. Escalation precision and recall

Of escalations raised, what proportion were genuinely worth escalating? Of confirmed incidents, what proportion were escalated by the SOC rather than discovered another way? The second number is uncomfortable to collect and is the single most informative metric on this list.

5. Detections created and retired per quarter

A healthy detection estate changes. New techniques get coverage; obsolete rules are retired. A SOC whose rule set has not materially changed in a year is not maintaining detection, it is maintaining a service.

6. Time from technique demonstrated to detection deployed

After a purple team exercise or a penetration test demonstrates a viable technique, how long until a detection for it is live and validated? This measures the improvement loop rather than the steady state, and it is the metric that most distinguishes a maturing SOC from a static one.

How to instrument this without a large project

  1. Start with log source health. It is the cheapest to build, catches the most dangerous failure mode, and needs only expected-volume baselines with a floor alert.
  2. Add escalation outcome tagging. Every escalation gets one of: true positive actioned, true positive benign, false positive, or insufficient data. Four values, tagged at closure, and you can compute precision from week one.
  3. Build the coverage map incrementally. Do not attempt full ATT&CK coverage in one exercise. Map the techniques your last penetration test actually used — that is a prioritised list handed to you for free.
  4. Measure time-to-escalate during exercises. You cannot wait for real incidents to produce a sample, and an exercise gives you a controlled timestamp for the moment malicious activity entered the pipeline.
  5. Review quarterly with the detections created and retired counts. If both are zero, that is the finding.

What to put in front of a board

Boards do not need six metrics. Under NIS2 and DORA, management bodies have to approve and oversee risk-management measures, which means they need something they can defensibly approve. Three numbers are enough.

  • Detection coverage against the techniques relevant to us, with the direction of travel and the largest known gap.
  • Time to escalate a true positive, measured in our most recent exercise, against the notification obligation we carry.
  • Proportion of confirmed incidents that we detected ourselves rather than being told about.

Those three are hard to game, map directly to obligations, and produce useful board questions rather than reassurance. If a provider's reporting cannot support them, that is worth knowing before the contract renews.

Frequently asked questions

What are the most important SOC metrics?

Detection coverage against a technique framework, log source health measured as unexpected silence, time to escalate a confirmed true positive, escalation precision and recall, detection rule churn, and time from a demonstrated technique to a deployed detection. These resist gaming in a way that alert volume and closure rate do not.

Why is mean time to detect a poor SOC metric?

Because it averages across all alerts, most of which are trivial. The detection time that matters is for the one genuinely malicious event, and it disappears into the mean. Measuring time to escalate a confirmed true positive is far more informative and maps directly to regulatory notification deadlines.

How do I measure detection coverage?

Map existing detections to MITRE ATT&CK techniques relevant to your environment, with a confidence level per technique rather than a binary yes or no. Build it incrementally by starting with the techniques your most recent penetration test or purple team exercise actually used, which gives you a prioritised list for free.

Talk to the team

Need this tested rather than described?

QuietHours is a European cybersecurity practice operated by the securIT team. Send us the system, service, or control you are concerned about and we will help turn it into a workable scope.

Discuss your scope

Related reading