Good SOC metrics show whether attackers are noticed and stopped faster over time: time to detect, time to contain, detection coverage and the share of alerts that mattered. Misleading ones count activity, like alerts closed or tickets opened, because teams can raise those without reducing risk.
Why SOC metrics go wrong
A SOC produces a stream of events, so counting is easy. The trouble is that counts respond to tuning, data sources and staffing as much as to threats. A dashboard that rewards closing alerts quickly teaches analysts to close alerts quickly.
Think in outcomes. NIST SP 800-53 control SI-4 asks organizations to detect attacks and unauthorized connections, analyze detected events and adjust monitoring as risk changes. Metrics should tell you how well each of those is going.
Metrics that matter
Time to detect. From the start of malicious activity to alert. Real starts are unknown, so measure with exercises and planted harmless test events, and note how many you ran. Report the median and the slowest cases.
Time to acknowledge and time to contain. Separate them. Acknowledge shows whether someone picked it up. Contain shows whether it stopped. Include approval delays in contain.
Detection coverage by behavior. MITRE ATT&CK catalogs adversary behavior. Map your detections to techniques that matter for your environment, and track which are tested and working. The gaps list is more valuable than the percentage.
Log source health. Count critical sources that sent data in the last day, against the sources you expect. A SOC cannot detect on silence.
True positive rate by rule. Of alerts from each rule, how many were real? Low rates mark tuning work. Very high rates on a rule may mean you are catching only the obvious cases.
Escalation quality. Sample escalations monthly and score them: did the ticket contain the facts the next person needs? Poor handoffs lengthen every incident.
Analyst workload. Alerts per analyst per shift and time on repeat noise. Sustained overload predicts missed events.
Repeat incidents by cause. Learning shows when the same cause does not return. NIST control IR-4 includes incorporating lessons learned from incident handling into procedures, training and testing, and repeat causes show whether that happened.
Time from threat report to hunt. When new intelligence arrives, how long until you have checked your environment? NIST control RA-10 describes hunting for indicators of compromise and threats that evade existing controls.
Metrics that mislead
Alerts closed. Incentivizes speed over thought. Pair with quality sampling or drop it.
Total alerts. Moves with data volume and rule changes.
Mean time to resolve across everything. Mixes false positives with real incidents. Use medians and split by type.
Number of detection rules. Counts effort, not coverage or quality.
Percent of alerts automated. Automation of noise looks good and changes nothing. Automation of containment for confirmed cases is a better thing to measure.
Uptime of the SIEM or platform alone. Necessary, and says nothing about detection.
Threats blocked. Mostly automated commodity noise.
A constructed contrast
Team A reports 12,000 alerts closed this month and a mean time to resolve of 20 minutes. Team B reports a median time to contain of 38 minutes for confirmed incidents, three coverage gaps found in exercises and fixed, and one noisy rule retired. Team A's numbers look busier. Team B's tell you more. Both teams are invented for this example.
How to run the reporting
Choose eight metrics at most. Write a one-line formula for each and keep it stable across quarters so trends mean something. Review quarterly with leadership, with the gaps list on the first page.
What should you do when a metric looks great?
Be suspicious and sample. A very low time to close may hide shallow reviews, and a very high true positive rate may mean a rule only catches the obvious. Pull ten closed cases at random each month, read them as an outsider would, and ask whether the notes justify the closure. This costs an hour and tells you more than another chart.
What to do
- Measure detection and containment with periodic harmless exercises.
- Track log source health daily and alert on silence.
- Report medians and worst cases, split by incident type.
- Review true positive rate per rule and retire or tune the worst.
- Sample escalations monthly for quality.
- Remove any metric that people can improve without reducing risk.
Where Safeguard fits
SOC tooling is outside Safeguard's focus and Safeguard does not replace it. Safeguard works on the application and software supply chain side, and can give a SOC context on whether a vulnerable dependency is reachable in the application involved.
Quick check
What single metric should a new SOC start with?
Log source health. If critical sources are not reporting, every other metric is built on missing data.
Is a faster time to close always good?
No. Speed is only good if closure quality holds. Sample cases to check.
Sources
Last reviewed: 18 October 2026.
