Vulnerability Remediation SLA Generator: Build Your Policy and Timelines
This free vulnerability remediation SLA generator builds the patching deadlines for your team and writes the full vulnerability management policy around them. Pick a starting point such as PCI DSS 4.0 or a CISA-style schedule, adjust the days for each severity and asset tier, and copy or download a ready policy with scope, roles, exceptions, scanning and reporting. It runs in your browser and nothing you enter is sent anywhere.
- Free
- No signup
- Runs in your browser
- 5 starting presets
- Policy as Markdown
| Severity | Tier 1Internet-facing or critical data | Tier 2Internal business systems | Tier 3Low impact or isolated | Tier 2 if found today |
|---|---|---|---|---|
| CriticalCVSS 9.0 to 10.0 | ||||
| HighCVSS 7.0 to 8.9 | ||||
| MediumCVSS 4.0 to 6.9 | ||||
| LowCVSS 0.1 to 3.9 | ||||
| Known exploitedListed in CISA KEV or exploited in the wild |
How it works
- 1Pick a starting pointChoose balanced, strict, PCI DSS 4.0, CISA-style or small team, and set your asset tiers.
- 2Adjust the daysEdit the days for each severity and tier. The tool warns about orders that do not make sense.
- 3Copy the policyCopy or download a full policy with scope, roles, exceptions, scanning and reporting.
How this vulnerability remediation SLA generator works
The vulnerability remediation SLA generator starts from a preset schedule, lets you change the days for each severity and each asset tier, and checks your numbers as you type. It warns you if a more severe finding gets more time than a less severe one, if internet-facing systems get longer than internal ones, or if you break a PCI DSS 4.0 or CISA limit in the preset you chose. It then writes the whole policy, including the SLA table, so you can copy or download it as Markdown and paste it into your document system.
What is a vulnerability remediation SLA?
A vulnerability remediation SLA is the deadline your organisation sets for fixing a security flaw, based on how severe it is and how important the affected system is. It is the core of a vulnerability management policy. Without it, scan reports pile up with no owner and no due date. With it, every finding has a deadline, an owner and a way to be measured.
Typical vulnerability remediation SLA timelines
There is no single legal standard. Some frameworks set maximums and others leave the days to you. This table shows what the main references say.
| Source | Timeline | Notes |
|---|---|---|
| PCI DSS 4.0 (requirement 6.3.3) | Critical and high security patches installed within one month of release. | Applies to in-scope system components. Other patches follow a risk-based timeframe. |
| CISA BOD 19-02 | Critical within 15 days and high within 30 days of detection. | For internet-accessible systems of US federal agencies. Many companies use it as a benchmark. |
| CISA BOD 22-01 | Each Known Exploited Vulnerabilities entry has a due date set by CISA. | For US federal agencies. Useful as a model for exploited flaws. |
| ISO/IEC 27001:2022 (Annex A 8.8) | No fixed number of days. | You set risk-based timelines and show that you meet them. |
| NIS2 (Article 21(2)(e)) | No fixed number of days. | Vulnerability handling must be proportionate to risk and evidenced. |
| Common practice | Critical 7 days, high 30, medium 90, low 180. | Typical starting point for companies without a framework deadline. |
How to rate severity: CVSS, EPSS and KEV
Most teams start with the CVSS base score: critical is 9.0 to 10.0, high 7.0 to 8.9, medium 4.0 to 6.9 and low 0.1 to 3.9. CVSS measures how bad a flaw could be, not how likely it is to be attacked. Two other sources fill that gap. EPSS, from FIRST, estimates the probability that a vulnerability will be exploited in the next 30 days. The CISA Known Exploited Vulnerabilities (KEV) catalog lists flaws that attackers are using now. A medium CVSS flaw on the KEV list is more urgent than a critical one nobody exploits. The free CVE Priority Checker shows all three for a list of CVE IDs.
What a vulnerability management policy should include
A policy that auditors accept covers the same core points. The generator writes each one for you.
- Purpose and scope: what the policy is for and which systems it covers.
- Roles: who owns the policy, who fixes findings and who verifies the fix.
- Severity ratings: how a finding gets its rating, including CVSS, EPSS and KEV.
- The SLA table: days to fix by severity and asset tier.
- The clock: whether it starts at vendor release or at detection.
- Exceptions: how to ask for more time, with compensating controls and an end date.
- Scanning and verification: how often you scan and how a fix is confirmed.
- Reporting: mean time to remediate, percentage within SLA and overdue items.
Vulnerability remediation SLA and compliance frameworks
Auditors do not usually ask for a particular number of days. They ask whether you have a policy, whether it is risk-based and whether you follow it. ISO/IEC 27001:2022 Annex A 8.8 covers the management of technical vulnerabilities. NIS2 Article 21(2)(e) names vulnerability handling as a required security measure, and the NIS2 Checker tells you whether it applies to you. PCI DSS 4.0 requirement 6.3.3 sets the one-month limit for critical and high patches, and requirements 11.3.1 and 11.3.2 cover internal and external scans. SOC 2 criterion CC7.1, CIS Controls v8 Control 7 and NIST SP 800-40 Rev. 4 on enterprise patch management give further guidance.
How to measure SLA performance
Track three numbers every month. The first is the percentage of vulnerabilities fixed within their SLA, which should meet your target such as 95%. The second is mean time to remediate by severity, to see whether you are getting faster. The third is the overdue backlog and its age, including open exceptions. Known exploited vulnerabilities past their deadline should always be zero. Scan regularly so the numbers are real: a free network vulnerability scan shows what is exposed, and the Software End of Life Checker finds software that will never get a patch.
How to handle exceptions
Some fixes cannot be made in time, for example because a patch breaks a business system or the vendor has not released one. The policy should not pretend this never happens. It should require a short written exception with the reason, the risk, compensating controls such as isolation, a WAF rule or extra monitoring, an end date and an approver. Review each exception before it expires, and never renew one automatically.
Frequently asked questions
What is a vulnerability remediation SLA?
A vulnerability remediation SLA is a written deadline for fixing a security vulnerability, set by severity. For example, critical flaws within 7 days and high flaws within 30 days. It turns scan results into a clear timeline for patching, makes teams accountable, and gives auditors evidence that you manage technical vulnerabilities.What are typical vulnerability remediation SLA timelines?
A common starting point is critical within 7 days, high within 30 days, medium within 90 days and low within 180 days. Vulnerabilities that attackers are already exploiting are usually fixed in 48 hours to 2 weeks. Internet-facing systems get shorter deadlines than internal ones. Regulations such as PCI DSS 4.0 and CISA BOD 19-02 set maximums for critical and high findings.How fast must critical vulnerabilities be fixed under PCI DSS?
PCI DSS 4.0 requirement 6.3.3 expects critical and high security patches to be installed within one month of release. Requirements 11.3.1 and 11.3.2 also require regular internal and external vulnerability scans and the resolving and rescanning of high-risk findings. Many organisations set shorter targets than one month for critical flaws.When does the remediation SLA clock start?
Choose one starting point and write it down. Some policies start the clock when the vendor releases a fix, which is how PCI DSS 6.3.3 is worded. Others start it when the vulnerability is first detected on your systems, as CISA BOD 19-02 does. Starting at detection is stricter because a delay in your own scanning counts against you.How should known exploited vulnerabilities be handled?
Treat vulnerabilities in the CISA Known Exploited Vulnerabilities catalog, or with a high EPSS score, as an emergency whatever their CVSS score. Give them their own, shorter SLA, usually 2 days to 2 weeks, and fix them before other work. The CVE Priority Checker shows KEV and EPSS data for a list of CVE IDs.What if we cannot patch within the SLA?
Raise a formal exception before the deadline passes. It should state the reason, the risk, the compensating controls (such as network isolation, a WAF rule or extra monitoring), an end date and an owner, and it should be approved by a named manager. Keep exceptions short, usually no more than 90 days, and review them before they expire.Does NIS2 or ISO 27001 require specific patching deadlines?
No. NIS2 Article 21(2)(e) requires vulnerability handling and ISO/IEC 27001:2022 Annex A 8.8 requires management of technical vulnerabilities, but neither sets a number of days. You decide risk-based timelines, write them in a policy like this one, and show that you follow them. An auditor will test whether you meet your own SLAs.Is the policy I build here sent to ScanTitan?
No. The generator runs in your browser. The organisation name, days and options you enter are not sent anywhere and not stored. The text it produces is a starting template, not legal advice, so have your security lead and your auditor review it before you adopt it.A policy sets the deadline. Scan to find out what is actually exposed and overdue.
Run a free network scanSee pricing