SOC Metrics 2026: What Matters to a CISO, What Does Not

The finding first: most SOC dashboards we review in maturity assessments measure effort, not outcome. Alerts processed per day, tickets closed, events ingested per second. The numbers are large, they grow every quarter, and they do not answer the one question the board asks: are we better protected than a year ago?

Activity metrics carry two structural flaws. First, they reward volume: a SOC that generates more low-quality alerts looks more productive than one that tunes its detections and generates fewer. Second, they can be gamed without improving anything: bulk-closing tickets before the monthly cut-off or reclassifying severities is enough to bend the curve.

• Alerts processed: measures SIEM load, not detection capability. An actor who evades your rules generates no alert at all.
• Tickets closed within SLA: incentivizes fast, shallow closures rather than complete investigations.
• Log volume ingested: measures storage cost, not useful visibility. Ingesting more irrelevant sources degrades the signal.

An outcome metric measures whether the SOC detects sooner, contains sooner and covers the techniques that actually threaten it. These are harder to compute and harder to manipulate. That difficulty is precisely their value in front of a board or a regulator.

MTTD and MTTR remain valid, but both are saturated with gaming. The fix is methodological, not abandoning them. Always disaggregate by severity and by vector: an aggregate MTTR of 4 hours says nothing if ransomware incidents take days and the average is dragged down by false positives closed in minutes.

Dwell time is the most honest of the three because it measures the adversary, not the analyst. Its limitation is statistical: it only exists when there is a confirmed incident, so the quarterly sample is usually small. Report it as a range and an annual trend, not a quarterly average, and supplement it with exercise results: detections during purple team work or a TIBER-EU-style TLPT produce controlled dwell time data without waiting for a real incident.

The metric that improves by itself is suspect. If MTTD or MTTR improve quarter after quarter with no change in detections, staffing or automation, the most likely explanation is that the measurement changed, not the capability. An independent maturity assessment verifies measurement integrity, not just the number.

Detection coverage against MITRE ATT&CK is the central quality metric, with two conditions. First: relevant coverage, not absolute. Covering the entire framework is noise; covering the techniques of the actors that target your sector is the defensible figure. Second: validated coverage. A technique only counts as covered if the detection has been tested with a simulated attack, not because a rule with that name exists.

Use case lifecycle health is the indicator that separates a SOC that operates from one that improves. Every use case needs an owner, a last-validation date, a false positive ratio and a retirement criterion. The SOC-CMM 2026 report puts average ATT&CK coverage at around 60%; the difference between a healthy 60% and a decorative 60% lies exactly in that lifecycle.

• % of use cases validated through simulation in the last 12 months.
• % of use cases with false positives above the agreed threshold (candidates for tuning or retirement).
• Automation rate: % of tier-1 response actions executed by playbook without human intervention, reported alongside the automation's own error rate.

A metric in isolation has no context. Is an MTTD of 6 hours good? It depends on the maturity of the process that produces it. This is where the SOC-CMM score (a continuous 0-5 scale across five domains: Business, People, Process, Technology and Services) turns operational metrics into governance evidence: it tells you whether the number comes from a repeatable process or from heroic, unrepeatable effort.

The SOC-CMM 2026 report data gives the board useful reference points: domain averages of 2.5 in Business, 2.3 in People, 2.3 in Process, 2.7 in Technology and 2.2 in Services. A SOC with Technology at 3.5 but Process at 2.0 produces metrics that look good and break easily. One more uncomfortable fact: self-assessments overestimate maturity by roughly 0.6 points. If the same team that produces your metrics also scores your maturity, the board is looking at a mirror, not a measurement. An independent maturity assessment removes that bias.

The board does not need the SOC's dashboard; it needs one page it can read in five minutes and defend in front of a regulator. A proven structure, top to bottom:

1. 1.Maturity header: SOC-CMM score per domain against target and against the sector average, with the date of the last independent assessment.
2. 2.Three operational metrics: MTTD and MTTR by severity (four-quarter trend) and dwell time as an annual range.
3. 3.Three quality metrics: relevant, validated ATT&CK coverage, % of use cases validated in 12 months, automation rate with its error rate.
4. 4.Two risk metrics: open material SOC-CMM gaps and % progress on the remediation roadmap.
5. 5.One narrative: the quarter's 2-3 incidents or exercises, what was detected, what failed and what changed as a result.

Total: between 6 and 9 figures plus one narrative. Every figure with a trend, a target and a source. If a metric does not change any board decision, it does not belong on this page.