A merged dependency policy is working when coverage is complete, fix times are falling or steady against the baseline, exceptions expire instead of piling up, gate overrides are rare, and developers can explain the rules. Track a handful of signals monthly, and read them together rather than alone.
Signals worth tracking
Coverage. What share of repositories and services are scanned and gated under the merged policy. A policy that covers half the estate is a policy for half the estate. Include repositories from both former companies, and list any that are missing.
Time to fix. How long findings stay open, by severity, measured from the same start and stop points on both sides. Compare against your baseline. See measure time from fix merged to fix deployed.
Exception age and count. How many exceptions are open, how many are past expiry, and how many were renewed more than once. Many repeated renewals mean a rule that does not fit.
Gate overrides. How often people bypass or force through a failed check. A high number means friction or a rule that blocks too much. A near zero number with many exceptions elsewhere might mean the process moved somewhere else. Read policy gate override rate, what it tells you.
New versus inherited. New findings introduced after the policy began, against old debt that existed at baseline. A good policy shows new findings staying low even while old debt is worked down.
Developer friction. Pipeline time added by the gate, number of support questions, and a short pulse survey. Hard to count, but easy to feel.
A simple monthly view
| Signal | Reading that is healthy | Reading that needs attention |
|---|---|---|
| Coverage | Rising toward all repositories | Flat with unknown gaps |
| Time to fix | Steady or falling | Rising on severe findings |
| Exceptions | Expiring on schedule | Piling up, repeated renewals |
| Overrides | Rare and explained | Frequent or unexplained |
| New findings | Low and stable | Climbing |
| Friction | Quiet | Many complaints about one rule |
Avoid vanity numbers
Total finding counts can rise because you improved coverage, and fall because a scanner changed. Do not celebrate or panic over a raw count. Tie each number to a decision: if this moves, what will we do?
For related ideas, see measure if tool consolidation worked without ROI numbers and how to tell if shift left security is working.
Review and adjust
At each policy review, pick the one signal that looks worst and decide on one change: a clearer message, a longer transition, a different threshold, or better tooling. Small, recorded changes beat a big rewrite after a year.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how ongoing monitoring shows changes over time, which is what these signals depend on.
Safeguard's vulnerability management and compliance evidence views can give you these figures from the same scans and gates that enforce the rules.
Quick check
How soon can we judge the policy?
Early signals such as coverage and friction appear in weeks. Trends in time to fix need a few months of data.
Is a high override rate always bad?
It is a signal, not a verdict. It can mean a poorly fitted rule, or a gate that is catching real issues that people are pushing past. Look at the reasons.
Last reviewed: 19 October 2026.
