Use different fix deadlines by phase. New services get your standard deadlines. Legacy code in active use gets risk based deadlines driven by exploitation and reachability. Code awaiting retirement gets time boxed exceptions with owners. Set the actual numbers with your risk owners, since they vary by organization.
Why one SLA fails
A single deadline for everything either punishes legacy teams with impossible targets or lets new services slide. A modernization project has code in at least three states, and each deserves its own rule. This post gives a structure. It does not prescribe numbers, since the right ones depend on your sector, contracts and capacity.
Phase one: new services
These are built with current tools and have few findings. Hold them to your standard deadlines, and enforce them with a pull request gate. When these services miss a deadline it usually signals a process problem and is worth investigating.
Phase two: legacy code in active use
Here the SLA should depend on risk, not just severity.
- Exploited in the wild: CISA's Known Exploited Vulnerabilities catalog is described by CISA as an input to prioritization. Treat a catalog entry in a reachable component as the shortest clock.
- Reachable and exposed: next shortest.
- Reachable, internal only: standard clock.
- Not reachable: longer clock, with the option to delete the code.
Phase three: code awaiting retirement
Teams want to skip fixes here. Allow exceptions, but make them explicit.
| Field | Required |
|---|---|
| Finding and component | Yes |
| Reason for exception | Yes |
| Compensating control | Yes |
| Planned retirement date | Yes, with owner |
| Expiry of the exception | Yes, shorter than the retirement date |
When the exception expires, either the fix lands, the date is reconfirmed by a named owner, or the exception is not renewed.
Putting it together
| Phase | Deadline basis | Enforcement |
|---|---|---|
| New services | Standard | Pull request gate |
| Legacy, active | Exploitation and reachability | Gate on regressions, scheduled review |
| Awaiting retirement | Time boxed exception | Expiry alerts |
Measure it
Track time to fix by phase, number of exceptions and age of the oldest one. A growing pile of renewed exceptions shows that the retirement plan is slipping, and leadership should see it. Fowler's reminder that replacing a serious system takes a long time is a useful caution when judging dates.
Write it down
A short policy page, approved by security and engineering leaders, avoids arguing each case. It should state the phases, the basis for deadlines and the exception process. Auditors and customers often ask for it. We cover content for such a policy in what a written vulnerability management policy should cover.
Safeguard's policies and compliance and evidence automation can help enforce deadlines and keep the records.
Quick check
Should severity alone set the deadline?
It is a starting point. Exploitation, reachability and exposure should adjust it.
How long can an exception last?
Shorter than the retirement date it relies on, and renewable only by a named owner.
Sources
Last reviewed: 19 October 2026.
