A leading indicator is a measurement that moves before the outcome you care about. A lagging indicator moves after. Both are useful. Confusing them is how a program ends up managing the past.
Incidents in the last quarter is a lagging indicator. It is real, it is countable, and by the time you read it the quarter is over.
Share of internet-facing systems still unpatched past the agreed window is a leading indicator. It moves weeks before the incident it predicts, and it can be acted on today.
Lagging indicators tell you what happened. Leading indicators tell you what is being set up to happen.
Lagging numbers are easier. Incidents get logged. Breaches get investigated. Audit findings get recorded. The data collects itself as a byproduct of the work.
Leading indicators usually have to be constructed. They combine sources, they need a definition somebody agreed to, and they often depend on data that no security tool holds: whether the exercise was actually run, whether the training landed, whether the budget line was spent.
That extra effort is why most security reporting skews backward.
A useful set has both, and the pairing should be explicit. For each lagging outcome that matters, name the leading indicators that should move first.
Time to contain an intrusion is the lagging number. Detection coverage against relevant techniques and analyst caseload are among the leading ones. If containment time degrades and neither leading indicator warned you, the pairing is wrong and worth revisiting.
Leading indicators are more gameable than lagging ones, precisely because they measure effort and readiness rather than results. Set a target on training completion and completion will hit target. Whether behavior changed is a separate question. See Goodhart’s Law.
From the blog