You can, but only with care. Link pay to broad outcomes that are hard to bend, such as sustained team level exposure, and never to a single count like open findings. Direct bonuses on one number are where gaming starts. Many teams do better with recognition and protected time instead.
Why compensation raises the stakes
Campbell's law says that the more a quantitative indicator is used for decisions, the more it is subject to corruption pressure. Money is the strongest form of that pressure. Once a number moves a paycheck, every ambiguity in its definition gets resolved in the direction that helps the person being paid.
That is not a character flaw. It is the normal response to the setup. A definition that was fine as a dashboard figure, such as what counts as critical or when the clock starts, becomes a negotiation.
A decision guide
Ask these questions in order before you link any metric to pay.
- Can the metric be changed by relabeling? If severity, status, or scope is set by the same people who are paid on it, do not link it.
- Does it have a counter metric on the same page? If not, add one first.
- Is it measured at team level, not for individuals? Individual links push people to hide work and avoid risky but important cleanup.
- Is it measured over a long window? Short windows create end of period spikes.
- Has someone outside the team sampled the data? If nobody audits, assume drift.
If any answer is no, use the metric for learning, not for reward.
Safer options
| Option | Why it works |
|---|---|
| Team level goal on exposure window for exploited issues | Hard to bend, close to real risk |
| Recognition for removing a risky dependency or retiring a service | Rewards causes, not counts |
| Protected time each sprint for security cleanup | Makes the work possible instead of merely demanded |
| A shared goal across engineering and security | Avoids the friction DORA warns about when teams are isolated by their own metrics |
DORA also warns against making one metric the goal for everything and against setting metrics as goals in broad statements. Its advice is to use several metrics with a healthy amount of tension between them.
Metrics that are poor candidates for pay
- Open vulnerability count, because status and severity can be reclassified.
- Number of findings fixed, because easy items win.
- Scan pass rate, because rules can be loosened.
- Training completion, because content can be clicked through.
- Time to fix measured only on closed items, because old items can stay open forever.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how a gate changes behavior at the point of the change, without needing a payment to make anyone care.
A policy gate enforced in the pull request is an example of a control that works through the workflow, not through a bonus. Safeguard's policies and gates cover that case, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is it ever safe to pay on a security metric?
It is safer when the metric is team level, measured over a long window, audited by someone outside the team, and paired with a counter metric. Even then, keep the weight small.
What if leadership insists on a security goal in objectives?
Offer an outcome goal such as keeping exploited issues from staying open past an agreed window, with sampling checks, instead of a raw count.
Sources
- Campbell's law (Wikipedia)
- DORA, software delivery performance metrics and common pitfalls
- Goodhart's law (Wikipedia)
Last reviewed: 19 October 2026.
