Lagging indicators report outcomes after the fact, such as incidents and breaches. Leading indicators show conditions that make outcomes more likely, such as unpatched exposed services or missing owners. A good program tracks a few of each and checks that the leading ones actually predict the lagging ones.
Lagging indicators
These are what boards ask about, and they are important, but they arrive late and are rare.
- Security incidents by severity.
- Customer reported security issues.
- Findings from external audits or penetration tests.
- Time to contain an incident.
Because incidents are infrequent, a single quarter's count is noisy. Do not draw conclusions from one data point.
Leading indicators
These move earlier and give you something to act on.
- Exploited vulnerabilities open on internet facing assets.
- Age of the oldest open critical item.
- Assets without an owner.
- Share of repositories with a gate on new high risk dependencies.
- Secrets found in repositories and time until rotated.
- Share of production images rebuilt in the last 30 days.
Pick leading indicators that you can influence
The test is whether a team can change the number within a quarter by doing something concrete. "Assets without an owner" passes: assign owners. "Threat actor activity in our industry" does not, so it is context, not a metric.
Check that leading indicators predict
After a few quarters, look back. Did the services with old exploited findings have more incidents? Did the repositories without gates introduce more bad dependencies? If a leading indicator never relates to outcomes, retire it. If you cannot test this because incidents are too rare, use near misses and findings from tests as the outcome signal.
Balance on a dashboard
A workable layout for a one page view:
- Top row: two or three lagging indicators with a trend.
- Middle: four to six leading indicators, each with a threshold.
- Bottom: coverage and data quality notes.
Keep the lagging row small. The leading rows are where discussion should go.
Avoid mixing activity with leading risk
"Scans run" and "training sessions held" are activity, not indicators. See the vanity metrics checklist.
A worked pairing
Suppose your lagging indicator is the number of customer reported security issues per quarter. Pair it with a leading indicator such as exploited vulnerabilities open on public services, and another such as repositories without a gate on new high risk dependencies.
If customer issues stay flat while both leading indicators improve, you may simply be between events, and that is fine. If customer issues rise while the leading indicators look green, your leading indicators are measuring the wrong things. That is the moment to review them rather than to defend them.
Be careful with small numbers
Lagging counts are often tiny. Going from 2 incidents to 3 is a 50 percent increase and almost certainly noise. Report raw counts with context, and consider a rolling twelve month view rather than quarter on quarter percentages.
Quick check
Is time to remediate leading or lagging?
It is lagging for a given finding, since it measures a completed fix, but open age of current findings is leading.
How many indicators are enough?
Roughly eight to twelve in total for a program of modest size, each with an owner.
Last reviewed: 19 October 2026.
