Which SecOps metrics are worth tracking?

The SecOps metrics worth tracking are the ones that change a decision: how long attacks go unseen, how fast you contain them, how much of your estate you can see, and whether the same problems keep returning. Define each metric precisely before charting it, or the numbers will mislead.

Why do most metrics fail?

Counts are easy and often useless. Alerts closed, tickets opened and scans run measure activity, not safety. A team can double its alert closures by lowering its standards. NIST SP 800-55 Volume 1, the measurement guide for information security,, asks organizations to build measures that show whether policies, procedures and controls are adequate, and it covers how to prioritize and evaluate them. The point is purpose: a metric exists to answer a question someone will act on.

Which measures earn their place?

Time to detect. From the start of malicious activity to the moment you notice. It is hard to know the start, so use the best evidence you have after the investigation and be consistent. A falling number means your visibility improved.

Time to contain. From detection to stopping the spread, such as isolating a host or disabling an account. It reflects process and tooling, and it is the number leadership understands.

Time to recover. From containment to normal operations. It exposes backup and rebuild problems.

Coverage. What share of assets send logs, run the endpoint agent, or get scanned. Detection time means nothing on assets you cannot see. Coverage ties directly to the asset inventory, so track inventory completeness as well.

Alert quality. The share of alerts that turn out to be real, or that need action. A low rate tells you to tune rules before adding people.

Repeat findings. How often the same type of incident or vulnerability returns after being closed. It shows whether you fix causes or symptoms.

Patch and vulnerability age. The time known exploited vulnerabilities stay open on exposed systems. Track the oldest, not just the average, since averages hide the tail.

Exercise results. The outcomes of tabletop and restore tests. They measure readiness before an incident.

NIST SP 800-61 Revision 3 places incident response within broader risk management, so these measures should feed back into prevention work and not sit in a report.

How should you present them?

Show trends over quarters, not single numbers. Use medians and the slowest cases, not only means. State the definition on the chart. Pair each metric with the decision it supports, for example: if time to contain on laptops stays above a day, fund remote isolation.

Constructed example: the falling alert count

A team reports alerts down by 40 percent and celebrates. A closer look shows a noisy rule was disabled, and coverage fell because several servers stopped sending logs after a migration. Time to detect, measured on incidents found later, rose. The count had improved while safety dropped. Pairing alert volume with coverage and detection time would have shown it at once.

What about vanity metrics?

Be wary of anything that always rises with effort: number of blocked attempts, number of scans, training completions without outcome data. They have a place as operational hygiene, but they are not evidence of risk reduction.

How to check or apply this

1. List the decisions your security leaders make each quarter, then pick metrics that inform them.
2. Write a one line definition for each, including start and end events and the data source.
3. Measure coverage first. Inventory assets and log sources before reading any speed metric.
4. Report medians and the slowest cases, with quarter over quarter trends.
5. Review the set twice a year and drop metrics nobody used.
6. After each incident, record detection, containment and recovery times the same way.

Quick check

Sources

• NIST SP 800-55 Vol. 1, Measurement Guide for Information Security
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations

Last reviewed: 18 October 2026.