# Vulnerability remediation timelines: how to set SLAs for clients

**The short version:**

- There is no universal deadline; the client's policy, contract or framework sets it.
- Base SLAs on exploitation and exposure, not severity alone.
- A common starting point: known exploited and internet-facing within days, Critical 14 days, High 30, Medium 90.
- Track the age of open findings so missed SLAs are visible before the next review.

## Why remediation SLAs matter

A scan without a deadline produces a report that ages on a shelf. Remediation service level agreements turn findings into commitments: who fixes what, by when. For an MSP they also define the scope of the service and protect both sides when something is exploited later.

## Common timelines

Organizations set their own numbers, but published policies cluster around similar values. US federal agencies must fix vulnerabilities in the CISA KEV catalog by the due date CISA sets (Binding Operational Directive 22-01), commonly two to three weeks for newly added entries. Many security teams aim for 7 to 14 days on Critical, about 30 days on High, 60 to 90 days on Medium and the next maintenance cycle for Low.

*A starting SLA matrix to adapt per client*

| Priority | Internet-facing or critical system | Internal system |
| --- | --- | --- |
| Known exploited (CISA KEV), especially with ransomware use | 72 hours | 14 days |
| Critical (CVSS 9.0 or above) | 7 days | 14 to 30 days |
| High (CVSS 7.0 to 8.9) | 14 days | 30 days |
| Medium (CVSS 4.0 to 6.9) | 30 days | 90 days |
| Low and informational | Next maintenance cycle | Next maintenance cycle |

> These are a starting point for a conversation, not a standard. Agree them with each client in writing, and check any contractual or regulatory requirement first.

## What frameworks say

- **PCI DSS v4:** critical security patches must be installed within one month of release (requirement 6.3.3), and internal scans must show high-risk and critical vulnerabilities resolved.
- **CISA BOD 22-01:** mandatory for US federal civilian agencies; widely used by everyone else as a benchmark for known exploited vulnerabilities.
- **CIS Controls v8:** Control 7 calls for a documented remediation process and risk-based remediation on a monthly or more frequent basis.
- **HIPAA, SOC 2, ISO 27001:** require a risk-based process and evidence that it is followed, rather than fixed day counts.

## Handling exceptions

Some findings cannot be fixed in time: a legacy system the vendor no longer supports, a line-of-business application that breaks on the new version. Treat these as risk acceptances, not silent misses. Record the finding, the reason, any compensating control (isolation, restricted access, monitoring), who accepted the risk and a review date.

## Tracking SLAs between scans

An SLA is only real if someone can see it being missed. Compare each scan with the previous one per client: what is new, what was fixed and how long each open finding has been open. Bring overdue items to the next client review with a reason.

Varaxon Scan Hub keeps reports per client and tracks the age of open findings between scans, so overdue known exploited vulnerabilities stand out. Remediation actions become HaloPSA or ConnectWise PSA tickets once you review and approve them. The [priority bands](https://varaxontech.com/guides/cvss-vs-epss-vs-cisa-kev?utm_source=hashnode-blog&utm_medium=referral&utm_campaign=vulnerability-remediation-sla) map directly onto the matrix above.

## Common questions

**What is a reasonable SLA for critical vulnerabilities?**

Between 7 and 30 days is common, shortened to days when the vulnerability is in the CISA KEV catalog or the system is reachable from the internet.

**Who should own remediation, the MSP or the client?**

Whoever controls the system. MSPs usually own patching on managed endpoints and servers, while line-of-business applications and vendor-managed systems need a named client or vendor owner in the report.

---

*This guide first appeared on [varaxontech.com](https://varaxontech.com/guides/vulnerability-remediation-sla).*

I'm building [Varaxon Scan Hub](https://varaxontech.com?utm_source=hashnode-blog&utm_medium=referral&utm_campaign=vulnerability-remediation-sla). It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan  
Founder, Varaxon Technologies