Build the SLA from three inputs: how critical the asset is, whether it is reachable from the internet, and whether the vulnerability has exploit evidence. A small matrix of three or four tiers is easier to follow than a severity table, and it points effort where an attacker would actually go.
Why severity alone falls short
A critical score on a library in an internal batch tool and a medium score on an internet facing login service are not equal risks. A severity only SLA treats them as if the first is more urgent. It also floods teams with deadlines they cannot all meet, which leads to blanket exceptions.
The three inputs
Asset criticality. Classify each service as high, medium or low based on the data it holds and the business function it supports. Keep it to three levels and have the service owner confirm.
Exposure. Internet facing, internal only, or isolated. Use your inventory, not guesses. Services sometimes become exposed through a changed ingress rule, so refresh it.
Exploit evidence. Whether the vulnerability is on a known exploited list, or has a public proof of concept. See using EPSS and KEV for tiers.
A starting matrix
These durations are examples to adapt, not benchmarks.
- Tier 0: exploit evidence and internet facing and high criticality. Mitigate within a day, fix within days.
- Tier 1: exploit evidence elsewhere, or critical severity on exposed high criticality assets. Fix within about two weeks.
- Tier 2: high severity on exposed or high criticality assets. Fix within about a month.
- Tier 3: all the rest. Fix in normal maintenance, within a quarter.
Choose numbers your teams can actually meet. An SLA that is always missed teaches nobody anything.
Add reachability as a modifier
If you can show the vulnerable function is not called, move the finding down a tier and record why. This is a documented adjustment, not an exception. It reduces noise without hiding the item. Review it if the code changes.
Exceptions and extensions
Allow one extension per finding with a reason, an owner and an expiry. A second extension should require a manager's sign off. Report extension counts monthly. See SLA compliance hides the overdue tail.
Publish the matrix
The value of a matrix is predictability. Put it on one page in a place developers already look. If an engineer can look at a finding and know the deadline without asking security, you have succeeded.
Safeguard note
Safeguard's policies and gates let you encode rules such as blocking a new high risk dependency on a pull request, and reachability analysis supplies context for the modifier above.
A worked example
A critical vulnerability is reported in a templating library. Service A is an internet facing checkout API, high criticality, and the vulnerability is on a known exploited list. That is Tier 0: mitigate today, fix within days. Service B is an internal reporting job that never passes user input to the library. Reachability shows the vulnerable function is not called, so it moves down to Tier 3 with a note.
The same finding produces two very different deadlines, and both are explainable in one sentence. That is the goal of the matrix.
Quick check
How many tiers should we have?
Three or four. More tiers make the policy hard to remember and hard to enforce.
Who decides asset criticality?
The service owner proposes, security reviews. Revisit it yearly or after major changes.
Last reviewed: 19 October 2026.
