Pick one fix deadline per severity by comparing the written targets with what each team actually meets today. Adopt the shorter target for the most severe findings, give the slower team a dated glide path, and keep one clock definition so both teams measure the same thing.
Written targets versus real behavior
Policies say seven days, thirty days, ninety days. Reality is often different. Before merging, pull the last quarter of closed findings from both teams and calculate how long each severity actually took. You are not looking for blame. You are looking for a target that is honest.
If one team writes fourteen days and meets it, and the other writes seven and misses it half the time, the seven day number is not the stricter policy. It is the louder one.
Agree on when the clock starts
Most disagreement hides in the definition. Decide these four things once:
- The clock starts when the finding is first reported by your tooling, not when someone triages it.
- The clock stops when the fix is deployed, not when the pull request is merged.
- Severity is taken from one scoring source, with a rule for when you override it.
- A finding that is not reachable or not exploitable in your usage follows a separate path, with a recorded reason.
Without these, the merged number means different things in different dashboards. See how to write a vulnerability remediation SLA policy and measure time from fix merged to fix deployed.
Set tiers that account for exploitation
A flat severity table ignores whether a flaw is being exploited. Add a faster lane for findings that appear in a known exploited list or that your reachability analysis shows are actually called. Keep the ordinary table for everything else.
| Finding | Suggested handling |
|---|---|
| Known exploited and reachable | Fastest lane, owner named immediately |
| High severity, reachable | Short deadline |
| High severity, not reachable | Longer deadline with a recorded reason |
| Medium and low | Batch into regular dependency updates |
The deadlines in each row are yours to choose. The structure is what matters.
Phase in the slower team
If one team must move from a thirty day target to a seven day target, do not flip the switch. Set interim targets, review them monthly, and track the backlog separately from new findings so the old debt does not hide fresh problems. See new versus inherited vulnerabilities, report separately.
Exceptions
Allow time bound exceptions with an owner and an expiry date, recorded in one place. An exception without an expiry is a policy change in disguise.
Try it yourself
Click through it at your own pace, or open it full screen. See how filtering to reachable findings changes the size of the queue a deadline applies to.
Safeguard offers reachability analysis and vulnerability management that can feed these lanes, and its fix pull requests are off by default, with every category set to Manual until you choose otherwise.
Quick check
Should we take the shortest deadline from either policy?
Only if the slower team can plausibly meet it with a transition plan. Otherwise you create a standing violation.
What if the two teams use different severity scores?
Choose one source for the merged policy, and write down how overrides are decided.
Last reviewed: 19 October 2026.
