SOC Metrics: Metrics That Truly Improve Detection and Response

What is the purpose of measurement?

Before choosing a KPI, define a decision. If the metric goes up or down, what will you do? A high Triage time might justify a Queue change, automation, or training. A high False Positive rate justifies Tuning. A lack of logs from a critical asset requires Data Pipeline remediation.

Separate Volume, Efficiency, Quality, Coverage, and Outcome. Volume describes how much work came in; Efficiency — how much time and resources were required; Quality — whether decisions were correct; Coverage — what can be detected; Outcome — whether an impact was stopped and whether it recurs.

For each metric, define an Owner, data source, formula, frequency, segmentations, and usage limits. Without a Data Dictionary, two managers can calculate “MTTR” differently.

Time Metrics

Mean Time to Triage measures the time from Incident creation until meaningful analyst contact or first change, according to definition. Time to Assign measures time until Owner. Time to Contain measures time until an action stops spread. Time to Close measures until administrative closure. These are different points and should not be confused.

MTTD — Mean Time to Detect — is harder to measure because the attack start time is not always known. It is possible to use First Activity Time versus Created Time, but it should be noted that this is an approximation. MTTR is a vague term: Respond, Remediate, Recover, or Resolve. Write the full word in every report.

Segment by Severity, Use Case type, Detection source, working hours, Owner, and asset. A general average hides slow High incidents within a large volume of fast Low ones.

Why Percentiles are Important

An average is affected by outliers. If nine Incidents were closed in an hour and one after a hundred hours, the average will be 10.9 hours — a figure that describes neither most cases nor the tail. Median (P50) describes the middle case; P90 shows the time below which 90% of cases were closed.

Microsoft presents KQL examples for calculating Time to Triage and Time to Closure percentiles from SecurityIncident. For a team, it is recommended to track at least P50 and P90, and investigate the P90: Is it an IT approval, lack of Owner, Data Gap, or manual process?

Do not compare percentiles between periods if the definition of CreatedTime, FirstModifiedTime, or ClosedTime has changed. Document changes in the system and Workflow.

Detection Quality Metrics

False Positive Rate alone is not enough, because a Benign Positive can be a correct Detection of authorized activity. It is better to classify: True Positive, Benign Positive, False Positive, Undetermined, and Duplicate. Analyze by Rule and not just at the SOC level.

Also measure Actionability: In what percentage of Alerts are there Context and Entities that enable investigation? How many Tickets were closed without evidence? How many Incidents were reopened? How many escalations were returned for completion? These metrics reflect operational quality.

For Detection Engineering, add Precision and Coverage where possible, but beware of calculating Recall without Ground Truth. Purple Team, Simulation, and Atomic tests can provide controlled testing of Use Cases.

Coverage and Visibility Metrics

SOC cannot detect what is not collected. Measure the percentage of critical assets sending logs, Freshness, abnormal volume, Parsing failures, missing fields, Retention, and Clock Sync. Data Source Availability should be an operational KPI, not just an infrastructure problem.

Build a Coverage Map against Use Cases and MITRE ATT&CK: Which techniques are relevant to the organization, which Data Sources are required, which Rules exist, and when were they tested? The number of “covered” techniques is not proof of quality, but it helps identify gaps.

Also measure Detection Debt: Rules without Owner, without Test, without documentation, without Review, or with a changed Data Source. Such debt increases risk even if the dashboard shows Alerts.

Workload and Process Metrics

Track Backlog, Aging, Alerts per Analyst, Incidents without Owner, waiting time for external teams, Reassignment rate, and On-call hours. High workload is not necessarily a staffing problem; it could be a noisy Rule or an unnecessary Workflow.

Do not rank analysts by the number of Tickets closed. Such a metric encourages choosing easy cases and fast closure. It is better to use group metrics and combine quality Review, complexity, documentation, contribution to Tuning, and ability to identify Scope.

Measure Standardization: The percentage of Incidents where required Tasks were completed, Playbook was executed, Classification included reasoning, and Timeline was written. The goal is not to create a form, but to ensure a professional minimum.

Impact and Improvement Metrics

The important outcome is reduced impact and recurrence. Measure Time to Contain in verified incidents, the number of assets affected before and after Detection, recurring incidents from the same Root Cause, implemented Recommendations, and time to close Logging or Control gaps.

Post-Incident Review should create measurable Actions: a new Rule, Policy change, training, Asset tagging, or Backup improvement. Track the percentage of completed Actions and check if the incident recurred.

Management should be presented with risk-related metrics: time without visibility in critical assets, Privileged incidents, service impact, and recovery time — not just Alert volume.

Monthly Scorecard for a Small SOC Team

How to Prevent Gaming

For each KPI, define an Anti-Metric. If measuring closure time, check Reopen Rate and Classification quality. If measuring fewer Alerts, check Coverage and Detection tests. If measuring fewer False Positives, check that Missed Detections were not created.

Present trends, not a “single score”. A large change requires a Data Quality check: Did a source stop sending? Did the Workflow change? Do Incident updates create duplicates in the table? Microsoft warns that every Update to an Incident creates a new record in SecurityIncident, so Queries need to select the last record.

Hold a monthly Review where analysts explain what the metrics do not show. Healthy measurement creates questions, not just a green color.

Practical Checklist

• ✓For every KPI, there is a decision it is supposed to improve.
• ✓The formula and data source are documented.
• ✓I use P50/P90 and not just the average.
• ✓MTTR is defined in full word.
• ✓Metrics are segmented by Severity and Use Case.
• ✓Quality and coverage metrics balance speed metrics.
• ✓There is an Anti-Metric to prevent Gaming.
• ✓Data Quality is checked before conclusions.
• ✓The team performs Review and generates Actions.

Common Mistakes

• Measuring only the number of Alerts and Tickets.
• Comparing periods with different definitions.
• Ranking analysts by the number of closures.
• Presenting Average without Percentiles.
• Ignoring incidents without Owner and Backlog.
• Reducing noise by turning off Detection without checking Coverage.
• Presenting a green KPI when a log source stopped sending.

Summary and CTA

Choose one month and build a small Scorecard with P50/P90 Triage, Classification by Rule, log availability, Backlog, and Time to Contain. Next to each metric, write what decision it is supposed to generate. In HPI's Cybersecurity & AI course, students practice investigation and SIEM, a foundation that allows understanding the meaning behind the metrics and not just displaying a Dashboard.

FAQ