A lagging indicator measures an outcome after it has happened. Incidents last quarter. Losses recorded. Findings raised in the annual audit. By the time the number exists, the period it describes is closed.
They are the only indicators that confirm anything. A leading indicator predicts. A lagging indicator settles the question.
They also validate the leading set. If detection coverage improved for three quarters and containment time did not, the leading indicator was measuring the wrong thing. Without the lagging number there is no way to find that out.
And they carry weight with people outside the function. A board that discounts a readiness metric will not discount a loss figure.
Two reasons, and the second is worse than the first.
The obvious one is latency. Acting on a lagging indicator means acting on a condition that may no longer exist.
The subtler one is that serious security outcomes are rare. An organization can go two years without a material incident while its exposure worsens continuously. Zero incidents is compatible with both a well-run programme and a lucky one, and the lagging indicator cannot distinguish them. Managing on rare events means managing on noise.
For each lagging outcome that matters, name the leading indicators that should move first, and write the pairing down. Review it when the lagging number moves and the leading ones did not.
This is also the cheapest defence against gaming. A leading indicator that improves while its paired lagging outcome degrades is a signal in itself. See counter-metric.
From the blog