Clearly defined vulnerability management SLAs you can use today
Introduction
Frameworks like NIST and CIS provide guidance on vulnerability management– but they don't really spell out exact remediation timelines for all types of vulnerabilities with a full scope of considerations (PCI is the closest). Instead, they leave it up to each organization to define their own SLAs based on business needs and risk tolerance.
That flexibility is great in theory, but in practice, it can lead to poor decisions, especially if the team doesn’t have the experience, context, or security depth to make those calls.
So, to remove that ambiguity and avoid guesswork, we’re going to lay out clear, practical SLA standards for vulnerability management– built specifically for how MSPs and MSSPs actually operate.
Methodology breakdown
CISA reports that the average time between the discovery of an exploitable vulnerability and its active exploitation is approximately 15 days. This means it's critical that vulnerabilities are remediated or mitigated in less than 15 days, but does this mean all vulnerabilities? Ideally yes, but we do have some constraints-- time, and labor. So, we need to ensure we're prioritizing how we address vulnerabilities based off the risk to keep the process manageable.
So, how do we determine the risk? Unfortunately, not all details are clear up front-such as exploitability, so we need to consider the likelihood of exploit. This is just one angle though, because we also know that anything listed on CISA KEV is already actively exploited. Then, we have the consideration of edge facing vs internal, and more.
In short, we need a framework. Here are the key components:
- External exposure (edge-facing systems)
- EPSS
- CVSS
- CISA KEV
Let's looks at each of these factors to help us get a sense of priority.
External exposure
Systems that are edge-facing carry significantly higher risk because they are discoverable through automated tools like port scans, which are continuously run by attackers and threat actors. Unlike internal vulnerabilities that typically require a foothold inside the network to be exploited, edge-facing vulnerabilities can be targeted directly from the internet with no prior access. This makes them the first line of attack and often the fastest route to compromise—especially for unpatched systems or misconfigurations exposed to the public internet.
EPSS
EPSS provides a risk-based score that reflects the likelihood a vulnerability will be exploited from 0 – 1 (0 and 100%) where the higher the score, the greater the probability that a vulnerability will be exploited. Because it accounts for real-world exploitation trends and technical characteristics, it’s a strong indicator of which vulnerabilities require urgent remediation or mitigation.
CVSS
CVSS offers a standardized severity score based on impact, exploitability, and other factors. While CVSS helps gauge how damaging a vulnerability could be, it does not account for whether it is likely to be exploited– making it most useful when paired with EPSS and our external exposure context.
CISA KEV (Known Exploited Vulnerabilities)
The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities that are confirmed to be actively exploited in the wild. It’s maintained by CISA and is one of the most reliable sources we have for identifying real-world threats that are being used right now. If something shows up in KEV, that means attackers are already taking advantage of it-- it’s not theoretical. So regardless of what the CVSS or EPSS score says, KEV listings automatically move that vulnerability to the front of the line. These are the ones that demand immediate attention.
Methodology summary
When you combine external exposure, EPSS, CVSS, and KEV, you get a much clearer picture of real-world risk. Exposure tells us how reachable the system is.
- CVSS gives us an idea of potential impact
- EPSS helps us predict whether attackers are likely to exploit it
- KEV removes all doubt-- if it’s on that list, it’s already happening.
Looking at these sources together helps us make better decisions about what to fix first, what can wait, and what absolutely cannot be ignored. Now let’s put that into a practical, easy to reference model.
Reference Table
Risk factor | What it tells us | Why it matters | Use for |
External Exposure | Whether the asset is publicly reachable (firewall, VPN, public web server) | Edge-facing systems are scanned 24/7 by threat actors and typically targeted first | Prioritizing systems most likely to be attacked |
CVSS Score | Severity of potential impact if exploited | Helps estimate business risk and urgency | Categorizing “Critical”, “High”, “Medium”, etc. |
EPSS Score | Probability that a vuln will be exploited in the wild | Adds predictive insight into which issues are most likely to become threats | Distinguishing urgent from theoretical risks |
CISA KEV Listing | Whether the vulnerability is already being exploited in the wild | Removes all doubt — immediate action is required | Identifying “Drop everything and fix this” scenarios |
Mapping
SLA category | Criteria | Justification |
Zero-Day / Actively Exploited | Listed in CISA KEV OR Vendor or threat intel confirms active exploitation | If it’s known to be actively exploited, it’s no longer theoretical. Immediate action is required—even if patching isn’t possible, compensating controls must be applied. |
Critical (Edge-Facing + High Risk) | Externally exposed (edge-facing) AND CVSS ≥ 7.0 OR EPSS ≥ 0.7 | These systems are exposed to the internet and have a high likelihood or impact of exploitation. They represent the highest risk after known-exploited vulnerabilities. |
High (Internal + High Risk) | Not edge-facing AND CVSS ≥ 7.0 OR EPSS between 0.4–0.69 | Internal assets may not be directly exposed, but still present significant risk if exploited. A week allows structured remediation. |
Medium (Moderate Risk) | CVSS 4.0–6.9 OR EPSS between 0.1–0.39 (any exposure type) | These present moderate likelihood and/or impact and can be handled during normal patch cycles. |
Low / Informational | CVSS < 4.0 OR EPSS < 0.1 OR already mitigated via compensating controls | Low-risk vulnerabilities that don’t justify immediate effort. Can be handled in routine cycles or accepted where appropriate. |
Recommended SLA Table
Using the criteria mapped out above in the Mapping table, here is your quick reference guide to what I recommend for your SLAs
SLA category | Resolution objective |
Zero Day | 48 hours |
Critical | 72 hours |
High | 7 days |
Medium | 30 days |
Low / Informational | 60-90 days (or risk accepted) |
Summary
Keep in mind that managing vulnerabilities can be a big task to take on. If you’re just starting out on vulnerability management, the SLAs above may be difficult to meet, and that’s okay-- it can take time. Start out less aggressive in your resolution objectives and make these SLAs the goal posts. Even if you double these to start out so 0 days are 4 days for example, that’s certainly significantly better than no defined SLAs in your organization at all.
Remember, security is a journey, not a destination. One step at a time, better every day, never perfect. Don't let perfection be the enemy of progress!
If you made it this far, congrats! I have an entire free course about ready to go all around vulnerability management. Subscribe to my blog here if you enjoyed this or it at least helped you, or reach out on LinkedIn or Instagram and I'll add you to my list for free access.