A vulnerability remediation SLA policy states how quickly issues must be fixed, based on risk tiers that combine severity, exposure and evidence of exploitation. It defines when the clock starts, who owns the fix, how exceptions work and how compliance is reported. Keep it short and enforceable, or teams will ignore it.
Step 1: define the tiers
Severity scores alone are a weak basis. A critical score on an internal system with no path from the internet is different from a medium on a public login page. Build tiers from three inputs.
- Severity of the flaw.
- Exposure of the asset: internet facing, internal, or isolated.
- Exploitation evidence: whether the issue is known to be used in attacks.
CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritization. Making "listed as known exploited" an automatic top tier is a simple, defensible rule.
Step 2: set deadlines
Pick durations for each tier, such as days for the top tier and longer windows for lower tiers. Choose numbers your teams can meet today, then tighten over time. A policy nobody can meet teaches people to ignore it.
Do not copy another organization's numbers blindly. Look at your current median fix times first, and set targets one step better.
Step 3: define the clock
State exactly when time starts: when the finding is confirmed, not when a scanner first printed it. Say what counts as fixed: patched and verified, mitigated by a documented control, or removed. Clarify whether a fix that is available but untested still counts as open. It does.
Step 4: assign ownership
Every finding needs one accountable team. Route findings automatically to the owning repository or service, so nobody has to hunt. Security tracks and reports. Engineering fixes.
Step 5: include exceptions
Link to your exception process. A valid exception has an owner, compensating controls and an expiry. Findings under a valid exception are reported separately, not hidden.
Step 6: report fairly
Report the share of findings fixed within SLA by tier, and the list of overdue items by age. Avoid league tables that shame teams with older systems. Show trends, and discuss structural causes with leaders.
Make it practical for developers
Developers meet the policy in pull requests. Where possible, fail a build only for the top tier, and show lower tiers as warnings with a ticket. Reachability information, which shows whether vulnerable code is actually called, helps teams focus on what is truly exposed.
Click through it at your own pace, or open it full screen.
Safeguard supports policies and gates that can enforce rules like these in pull requests, and a free scan at https://gold.safeguard.sh/scan shows what your dependencies look like today.
Quick check
When should the SLA clock start?
When the finding is confirmed and assigned to an owner. State this in the policy so there are no disputes.
Should every vulnerability have the same deadline?
No. Use tiers based on severity, exposure and evidence of exploitation.
Sources
Last reviewed: 19 October 2026.
