Prioritization
Vulnerability remediation timelines: how to set SLAs for clients
How fast should Critical, High and Medium vulnerabilities be fixed? Common remediation timelines, what frameworks require, and a starting SLA matrix MSPs can adapt per client.
Varaxon Technologies · · 3 min read
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.
| 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 |
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 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.
Turn your next scan export into a client-ready report.
Run a free pre-flight check