From MTTD and MTTR to Real Value: How to Organize SOC Metrics Effectively

Anatoly Antipov, head of L1 analysts at a small in-house SOC, explains why traditional time-based metrics like MTTD and MTTR often lead to superficial incident handling and analyst burnout. Drawing on NIST SP 800-61 and the latest SANS SOC Survey, the article shows how speed-focused KPIs encourage analysts to game the system rather than improve security. The team replaced vague verdicts with a five-level matrix including TP.Ext, TP.Int, BP, FP, and FP.SOC to separate real incidents, benign activity, and internal detection debt. Weekly reports were restructured around three blocks covering overall volume, verdict distribution, and confirmed violations with actual effort metrics. Regular quality audits of closed alerts now check verdict accuracy, documentation completeness, and whether FP.SOC items trigger rule improvements. The approach helps small SOC teams focus on genuine risk reduction instead of dashboard optics.

HabrTranslated from Russian

Read at source

Anatoly Antipov, who leads the L1 analyst group in a small in-house SOC of up to eight people, describes how classic time-based metrics often produce the opposite of their intended effect. Many leaders start the day reviewing dashboards built around MTTD, MTTR, and similar indicators recommended by NIST SP 800-61. These numbers look clean in quarterly reports, yet they frequently hide shallow investigations and growing technical debt.

The SANS SOC Survey highlights the same pattern: when speed and volume become the only targets, analysts begin optimizing for the metric instead of security outcomes. One documented case showed a simple script automatically moving new alerts into the “in progress” state to keep MTTA numbers green while real cases sat untouched for hours.

To address this, the team introduced a strict five-level verdict matrix. The categories are TP.Ext for confirmed external attacks, TP.Int for internal policy violations, BP for authorized testing activity, FP for legitimate business or IT actions, and FP.SOC for problems inside detection content, parsing, or filtering logic. This classification makes it immediately visible where the SOC is generating value and where it is accumulating its own technical debt.

The weekly report was rebuilt around three focused blocks. The first shows overall alert volume, closure rates, backlog, and shift workload distribution. The second breaks alerts down by the new verdict matrix so managers can see whether rising false positives stem from business changes or from SIEM and SOAR content issues. The third block lists real confirmed incidents together with concrete effort indicators such as emails sent, EDR scans launched, and indicators blocked.

Every week a sample of closed alerts from each analyst undergoes quality review. Reviewers check whether the verdict is correct, whether actions are fully documented, whether sufficient artifacts are attached, and whether FP.SOC items include clear recommendations for rule improvement. The process prevents analysts from being rated solely on speed.

The changes demonstrate that Mean Time metrics remain useful when paired with quality controls, transparent verdicts, and regular audits. Without these additions, small SOC teams risk turning into expensive click farms that look efficient on dashboards while actual risk reduction quietly declines.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Policy & Regulation

Russian Minister Proposes Blocking All SIM Cards Linked to Fraudsters Banned in MAX Messenger
Russia Ready to Disclose Source Code of Social Networks, Messengers and AI Models
Russia Mulls Mandatory Two-Week IMEI Registration for Foreign Smartphones via Gosuslugi