Building a detection maturity model your team will actually use

Most detection maturity models fail for the same reason most maturity models fail in general: they measure activity instead of outcomes. Counting the number of rules you've shipped tells you nothing about whether they catch anything or whether anyone trusts them enough to act on the alert. A coverage heatmap that turns green the moment a rule exists, regardless of whether that rule actually fires on the technique it claims to cover, is measuring effort, not capability.

Where the popular models go wrong

Ryan Stillions' original Detection Maturity Level framework was a genuine step forward when it separated detections by the semantic level they operate at — atomic indicators versus tactics, techniques, and procedures. The problem isn't the framework; it's how teams operationalize it. In practice, most implementations turn into an ATT&CK Navigator layer where a cell goes green the moment someone writes a rule that superficially maps to a technique ID, with no attached information about whether that rule has ever actually fired correctly, how often it's wrong, or who's responsible when it breaks.

That produces a heatmap that looks impressive in a quarterly review and tells the SOC nothing useful about what will actually happen during a real intrusion.

Three facts, not a scorecard

A maturity model worth keeping tracks exactly three things per detection, and refuses to let anything else stand in for them:

• Technique mapping — which specific sub-technique this detects, and just as importantly, which adjacent sub-techniques it does not cover, so coverage gaps stay visible instead of getting rounded up to "covered."
• Measured false-positive rate — not an estimate from testing, but the actual observed rate in production, refreshed on the same cadence as tuning review.
• Named owner — a specific person or team who gets paged when the detection breaks or drifts, not "the detection engineering team" as an abstraction nobody is accountable to.

Everything else — dashboards, coverage heatmaps, ATT&CK Navigator layers — is presentation built on top of those three facts, not a substitute for them. If a heatmap cell can turn green without an entry existing for all three, the heatmap is lying.

What this looks like operationally

In practice this is a flat table, not a piece of dashboard software: one row per detection, with columns for technique ID, measured precision, owner, last review date, and current status (active, tuning, retired). No detection ships without every column filled in, and no detection stays active past its review date without someone explicitly re-signing off on it.

The governance cadence matters more than the tooling. A monthly review where the whole table gets walked, row by row, with owners present to speak to anything overdue, does more for actual detection quality than a much more sophisticated system that nobody looks at between quarterly audits.

A short case study

One team's coverage heatmap showed 40% ATT&CK coverage under the old model. Rebuilding the same coverage claim under the three-fact model — requiring a named owner and a measured precision figure for every green cell — dropped the honest number to 22%. That felt like a regression in a leadership readout, but it was the same detections; the first number had just been fiction. The corrected number became the baseline the team actually improved against over the following two quarters, instead of a heatmap that could never fail a review because nothing behind it was ever checked.