Set quarterly vulnerability targets as an outcome plus a guard metric. For example, reduce the age of the oldest known exploited item, while also tracking dismissals and reopens. The guard stops people hitting the target by changing the count rather than the risk. Start from a baseline and reward accurate reporting.
Why targets get gamed
Goodhart's law is the usual shorthand: when a measure becomes a target, it stops measuring well. In vulnerability work that shows up as findings downgraded in severity, dismissed with thin reasons, split or merged to change counts, or scans narrowed to exclude trouble spots. None of this needs bad intent. People respond to what is rewarded.
Choose outcome targets, not activity targets
| Weak target | Stronger target |
|---|---|
| Close 500 findings | Reduce the oldest open known exploited item to within policy |
| Scan all repos | Keep production services scanned, with the percentage measured against an asset list |
| Zero criticals | No critical finding on an internet-facing service past its window |
Activity targets reward motion. Outcome targets reward reduced exposure. Always pair a target with the question "could we hit this without lowering risk?" If yes, the target needs a guard.
Pair every target with a guard
- Dismissal rate. If closures rise because of dismissals, a sample review checks reasons.
- Reopen rate. Findings that return suggest fixes were not real. Counting them keeps closure honest.
- Coverage. A falling count with a shrinking scan scope is not progress.
- Severity changes. Track how often severity is edited after the scanner sets it.
You do not need to show guards to executives every time. Keep them in the definition card and review them yourselves.
Process steps
- Take a baseline for the last two to three quarters.
- Choose one or two outcome targets, not ten.
- Pick guards and define them before the quarter starts.
- Decide in advance who reviews a sample of closures and dismissals.
- At quarter end, report target, result, and guard readings together.
Reward honesty
If a team reports a bad number early with a plan, treat that better than a team that hides one. A culture that punishes bad news produces good looking dashboards and worse security. Say this out loud when you introduce the targets.
Agree the review before the quarter starts
Put the sampling rule in writing. For example, a reviewer outside the owning team checks a small random sample of closures and dismissals each month, and the result is shared with the team. Teams that know a sample will be checked tend to document reasons better, and the review costs little because it is a sample, not a full audit.
When a target is missed
Ask what changed: inflow, capacity, scope, or a priority conflict. Missing a target for a clear reason is a planning input. Missing it with a quiet change in method is a data quality problem and deserves a different conversation.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should targets be tied to bonuses?
That raises gaming pressure sharply. If you do tie them, use outcome measures with guards and keep human review of closures.
How many targets per team is reasonable?
One or two. More than that dilutes attention and makes tradeoffs hidden.
Last reviewed: 19 October 2026.
