An actionable metric is one that a specific person can respond to with a specific decision. The word gets used loosely, as though actionability were a property of the number. It is not. It is a property of the number plus its context.
Someone owns the value. Not the definition, the value. A named person whose job includes moving it.
There is a threshold that separates acceptable from not. Without it, every reading is just a reading, and the response is always to note it and move on.
The owner has levers. A metric that depends entirely on decisions made in another function is informative but not actionable by the person receiving it.
It arrives while action is still possible. A quarterly number describing a condition that changes weekly cannot be acted on, only explained.
Most security metrics fail at least one. Many fail three.
Not the absence of a threshold, though that is close. It is the absence of levers.
Consider a metric for share of end-of-life systems still in production. The security team owns the number and is accountable for it in every review. The decision to fund replacement sits with infrastructure, and the decision to tolerate the risk sits with the business. The metric is being reported to someone who cannot move it.
The fix is not a better metric. It is moving ownership of the value to whoever holds the lever, and giving the security function ownership of the definition and the escalation.
Name the owner of the value, separately from the owner of the definition.
Set the threshold with that owner, in advance.
Define what happens at the threshold, including who gets told.
Match reporting frequency to how fast the number can move.
If you cannot complete all four, the metric belongs in the context layer rather than the decision layer. That is a legitimate place for it. Pretending otherwise is what produces packs full of numbers nobody responds to.
From the blog