---
{
  "title": "Security operations metrics",
  "summary": "Measure detection and response without rewarding the wrong behavior.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Measure the work without distorting it

Security operations metrics help a team understand workload, capability, and outcomes. Useful measures answer specific questions: are important cases waiting too long, do analysts have the evidence they need, and do response actions reduce harm? A number becomes useful when its definition, scope, and limitations are understood.

No single metric proves that a SOC is effective. Alert volume can increase because visibility improved or because a rule became noisy. Faster closure can reflect better tooling or rushed decisions. Interpret measures alongside case quality and changes in the environment.

## Define the clock before comparing teams

Consider a fictional academy measuring time to triage. Does the clock start when the source event occurred, when the alert was generated, when it reached the queue, or when the analyst's shift began? Does it stop at first review or at a documented decision? Those choices can change the result substantially.

Separate detection delay, queue delay, investigation effort, and time waiting for another team where the data supports that distinction. Otherwise a long end-to-end duration may be blamed on analysts when the real issue is delayed logging or unavailable approval.

Averages alone can hide a small group of cases waiting much longer than the rest. Review distributions or appropriate percentiles and examine the delayed cases. Compare similar incident types and impact levels rather than combining everything into one ranking.

## Pair activity with quality

Closed-ticket counts describe throughput. Pair them with review of evidence quality, escalation appropriateness, repeat incidents, and actions completed. A team that closes a case quickly but leaves the underlying access path open has not necessarily achieved a better outcome.

Track detection health as well as case handling. A falling alert count may look efficient while a required source has stopped reporting. [[logs-and-telemetry]] and [[detection-engineering]] help distinguish operational improvement from lost visibility.

Metrics should also account for scope changes. Adding cloud services, endpoints, or new event categories changes the workload and the coverage available. Record those changes when presenting trends so readers do not mistake a different denominator for improved performance.

## Use a measure to make a decision

For practice, define a metric for cases awaiting specialist review. Specify which cases count, the timestamps used, exclusions, owner, and decision the measure supports. Then pair it with a quality check on a small sample of handovers.

If waiting time is high, investigate whether the problem is missing context, unclear ownership, insufficient capacity, or an unnecessary approval step. The metric identifies a question; case review supplies the explanation. [[soc-roles]] and [[incident-reporting]] connect measurement to changes the team can actually make.

## Related concepts

- [[alert-triage]]
- [[project-monitoring]]