Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you design vulnerability remediation SLAs?
Updated
A remediation SLA is a documented, risk-tiered commitment your organization sets and defends — not a number handed down by a framework. NIST SP 800-40r4, SOC 2, ISO/IEC 27001:2022, and PCI DSS all expect a defined process; none states your day-counts for you. This page is not legal advice.
Last verified 10 September 2026 against NIST SP 800-40 Revision 4, the AICPA SOC 2 Trust Services Criteria CC7.1 and CC7.2, ISO/IEC 27001:2022 Annex A control 8.8, and PCI DSS v4.0.1 Requirement 6 (including 6.3.1 and 6.3.3). Not legal advice. It does not determine which framework applies to YOUR organization, does not set YOUR SLA tiers, and does not start a remediation clock.
This is a template, not a mandate, and not YOUR SLA
Audience: an eng leader or security lead who has been asked, by an auditor or a customer, 'what is your remediation SLA?' and does not yet have a documented, defensible answer. This page is not legal advice. It does not determine which framework applies to YOUR organization, and reading it does not create, start, or satisfy any SLA. The matrix and checklist below are a starting point to adapt, not a control you can point to as already met.
None of the frameworks named on this page — NIST SP 800-40r4, SOC 2, ISO/IEC 27001:2022, or PCI DSS — hands an organization a fixed table of days per severity tier. Each one expects the organization to define its own risk-based process and then evidence that it followed it consistently. An SLA matrix is how most programs make that process concrete and auditable. The remediation-timeframes guide on this site covers the narrower cases (CISA BOD 26-04, PCI DSS's specific 30-day critical-patch clock) where a text does state a day-count for a defined population.
- The program-checklist guide on this site is where SLA design sits inside a full vulnerability management program. The accepted-risk guide on this site covers what happens when a finding cannot be fixed inside its SLA and needs a documented exception instead.
- The vulnerability management pillar on this site is not published yet; naming it here is not a link.
Example SLA matrix — a template to adapt, not a mandate
The table below is an illustrative example, not a citation from any framework and not this organization's recommendation for every environment. Real programs typically tier by both finding severity and asset criticality (a critical finding on a public-facing production system usually gets a tighter window than the same finding on an isolated internal dev box). Adapt the numbers, the tiers, and the asset-criticality axis to your own risk appetite, then document the result. Not legal advice.
- This matrix does not classify any specific finding in YOUR environment and does not itself satisfy any framework's control — a written policy plus evidence that the organization followed it does that.
- A finding confirmed on the CISA KEV catalog, or under active exploitation, is commonly escalated above whatever tier its CVSS score alone would place it in, regardless of the matrix above.
| Severity tier | Internet-facing / production | Internal / lower-exposure | Notes |
|---|---|---|---|
| Critical (CVSS 9.0-10.0, or on CISA KEV, or confirmed actively exploited) | 3-7 days | 14 days | Many programs collapse this tier to a single window regardless of exposure once a finding is confirmed on KEV. The exploitability-vs-severity guide on this site covers why exploitation evidence, not CVSS alone, should set this tier. |
| High (CVSS 7.0-8.9) | 14-30 days | 30-45 days | PCI DSS v4.0.1 Req 6.3.3's 30-day clock applies only to patches an entity's own risk-ranking process (Req 6.3.1) classifies as critical — treat any 30-day figure here as your own choice, not a quotation of the standard. |
| Medium (CVSS 4.0-6.9) | 45-60 days | 60-90 days | Commonly batched with routine patch or release cycles rather than tracked as an individual emergency ticket. |
| Low (CVSS 0.1-3.9) | 90 days, or next release cycle | Best-effort / backlog | Some programs formally accept low-tier findings on lower-exposure assets rather than tracking an SLA at all — see the accepted-risk guide on this site for that governance path. |
Framework-driven inputs vs an SRM-recommended default
Do not present a framework's control text as though it states the numbers above. Last verified 10 September 2026. Not legal advice.
| Framework | What it actually requires | What it does not state |
|---|---|---|
| NIST SP 800-40 Revision 4 | Recommends leadership, business owners, and security teams jointly build a risk-tiered enterprise patching strategy, with faster handling for higher-risk assets and vulnerabilities. | Does not publish a specific days-per-tier table. Any such table built from it is the organization's own operationalization of the guidance. |
| SOC 2 Trust Services Criteria CC7.1 | Requires detection and monitoring procedures to identify configuration changes introducing vulnerabilities and susceptibility to newly discovered ones, including periodic vulnerability scanning with 'timely' remediation of deficiencies. | 'Timely' is not defined as a number of days by the criterion itself. Auditors evaluate the entity's own defined and evidenced remediation timeline against what it committed to, not against an AICPA-stated day-count. |
| SOC 2 Trust Services Criteria CC7.2 | Requires monitoring system components for anomalies indicative of malicious acts, natural disasters, and errors, and analyzing anomalies to determine whether they represent security events. | Is about detection and monitoring, not a remediation-timeline requirement; it is listed here because it sits in the same CC7 System Operations series auditors evaluate alongside CC7.1. |
| ISO/IEC 27001:2022 Annex A control 8.8 | Requires that information about technical vulnerabilities be obtained, exposure evaluated, and appropriate measures taken. Deliberately technology- and timeline-neutral. | States no day-count at all. An ISO 27001 auditor checks for a documented process and evidence it operated consistently, not compliance with a specific SLA number. |
| PCI DSS v4.0.1 Requirement 6 (6.3.1, 6.3.3) | Requires a documented risk-ranking process (6.3.1) and a 30-day patch-installation clock for whatever that process classifies as critical (6.3.3); everything else is on an entity-defined, documented timeframe. | Does not set a fixed day-count for anything other than the critical-patch tier. A 'PCI-compliant' 90-day figure for lower tiers is the entity's own choice, not the standard's text. |
| The example matrix on this page | An illustrative starting template, informed by common practice across the frameworks above. | Is not a citation from any of the four frameworks, is not this organization's universal recommendation, and does not fit every risk appetite or regulatory posture without adaptation. |
Checklist for SLA governance
An SLA matrix without governance around it is a document nobody enforces. This checklist covers what auditors and internal reviewers typically expect to see operating, not just written down. Not legal advice; this page does not evidence any of these items for YOUR organization.
- Documented tiers: severity, and ideally asset criticality or exposure, with a written definition of how a finding gets assigned to a tier — not left to individual judgment call by call.
- A named owner per tier or per system, so an SLA breach has a person accountable for it, not just a ticket queue.
- A defined exception path: who can approve an SLA extension or a formal risk acceptance, what justification is required, and an expiry or review date on every exception. The accepted-risk guide on this site covers this in depth.
- SLA-attainment measurement: percentage of findings closed inside their tier's window, count and age of overdue findings, and the age of the oldest open critical finding — tracked over time, not just at audit season.
- Escalation on KEV or confirmed active exploitation: a rule that overrides the normal tier assignment when a finding is confirmed on the CISA KEV catalog or under active exploitation, regardless of its CVSS-based tier.
- Re-scan or verification before closure: a finding marked 'fixed' without a rescan or equivalent verification is not evidence the SLA was actually met — the prove-remediation guide on this site covers what an auditor accepts as proof.
- A review cadence for the matrix itself: risk appetite, threat landscape, and asset criticality change; a matrix set once and never revisited stops reflecting real risk.
Common SLA governance failure modes
Most SLA programs that fail an audit or quietly rot do not fail because the numbers were wrong. They fail because of a handful of recurring governance gaps. Naming them is not a claim that any of them applies to YOUR program.
| Failure mode | Why it happens | What tends to fix it |
|---|---|---|
| The matrix exists on paper but nobody tracks attainment against it. | SLA tiers get written once, during a compliance push, and then no dashboard or recurring review checks whether findings actually close inside their window. | A recurring (weekly or biweekly) attainment view: findings closed on time, overdue findings by tier, and age of the oldest open critical finding — reviewed by an owner, not just generated. |
| Findings get closed without verification. | A ticket marked 'done' by the engineer who filed the fix, with no independent rescan or check, looks the same in a report as a verified fix. | Require a rescan or equivalent verification before a finding leaves 'open' status. The prove-remediation guide on this site covers what evidence an auditor accepts here. |
| Exceptions accumulate with no expiry. | An SLA extension approved once, during a busy sprint, that is never revisited becomes a permanent, silent exception. | Every exception gets an expiry or review date at approval time, and a recurring report of exceptions approaching or past that date. |
| One severity tier absorbs everything. | Without an asset-criticality axis, a critical finding on an isolated dev box gets the same urgency as one on public-facing production, which either over-alarms the team or trains it to ignore the tier. | Add asset criticality or exposure as a second axis, even a coarse one (internet-facing vs. internal), so the SLA reflects actual blast radius, not severity alone. |
| The matrix was set once and never revisited. | Risk appetite, asset inventory, and the threat landscape change; a matrix frozen at its first draft stops reflecting current risk within a year or two. | A scheduled annual (or more frequent) review of the matrix itself, not just of individual findings against it. |
What to do now
This page does not build or approve YOUR SLA matrix. The list below is the operational sequence most programs follow to get from 'we don't have one' to 'we have one and can evidence it.'
- Decide your tiers and axis (severity alone, or severity x asset criticality) and draft day-counts using the example matrix on this page as a starting point, not a citation.
- Write down which framework(s), if any, actually bind your organization (see the remediation-timeframes guide on this site for CISA BOD 26-04 and PCI DSS's specific clocks) and layer any hard legal or contractual deadline on top of your own tiers rather than replacing them.
- Assign an owner per tier, define the exception path, and set a measurement cadence before you publish the matrix internally — a matrix without an owner or an exception path tends to erode within a quarter.
- Track attainment and overdue counts continuously, not just before an audit; a scramble to hit numbers right before a SOC 2 or ISO 27001 review is itself a common audit finding.
- Revisit the matrix at least annually, and immediately after any material change in your threat model, asset inventory, or regulatory posture.
Where this shows up in ShipReady Metrics
Signed-in app → Security → Findings lets the organization configure its own SLA tiers and tracks each finding's age and overdue status against them, with per-source deduplication so one underlying issue surfaced by multiple scanners is not counted, or aged, more than once. That surface does not set YOUR tiers, does not decide which framework binds your organization, and does not patch anything. A named human on the team owns the tier definitions, the exception approvals, and the remediation decisions.
This page does not document a public product demo path.
Primary sources (last verified 10 September 2026)
NIST Special Publication 800-40 Revision 4, Guide to Enterprise Patch Management Planning (April 2022). AICPA SOC 2 Trust Services Criteria, common criteria CC7.1 (vulnerability and configuration detection) and CC7.2 (security event monitoring), within the CC7 System Operations series. ISO/IEC 27001:2022 Annex A, control 8.8, Management of technical vulnerabilities. PCI Security Standards Council, PCI DSS v4.0.1 (June 2024), Requirements 6.3.1 and 6.3.3. Not legal advice. These are not a complete list of every framework an individual organization might need to satisfy (contract-specific SLAs and sector rules can add further obligations this page does not cover).
The remediation-timeframes guide, the program-checklist guide, and the accepted-risk guide on this site are the closest related pages.
Frequently asked questions
Is this legal advice?
No. It is a template SLA matrix and a governance checklist distilled from NIST SP 800-40r4, SOC 2 CC7.1/CC7.2, ISO/IEC 27001:2022 A.8.8, and PCI DSS v4.0.1 Requirement 6, none of which states a universal day-count. Whether any specific framework binds YOUR organization, and what SLA windows are defensible for your risk profile, are questions for your own security and compliance leadership, or counsel where a contractual question is genuinely live.
Does any framework require a 30-day fix window for critical vulnerabilities?
PCI DSS v4.0.1 Requirement 6.3.3 requires patches an entity's own risk-ranking process (Requirement 6.3.1) classifies as critical to be installed within one month of release — but that binds only entities in scope for PCI DSS. NIST SP 800-40r4, SOC 2, and ISO/IEC 27001:2022 do not themselves state any universal day-count for any severity tier; they require a documented, risk-based process instead.
Is the example SLA matrix on this page a mandate?
No. It is an illustrative starting template built from common practice, not a quotation from any framework and not a universal recommendation. Real programs adapt the tiers, the day-counts, and the axis (severity alone, or severity x asset criticality) to their own risk appetite, then document and evidence the result.
What happens if we cannot fix something inside its SLA window?
A documented exception process — who can approve a deferral or a formal risk acceptance, what justification is required, and an expiry or review date — is what auditors expect instead of a silently missed deadline. The accepted-risk guide on this site covers building that exception-record process in detail.
Does ShipReady Metrics set our SLA tiers for us?
No. Signed-in app → Security → Findings tracks finding age and overdue status against SLA tiers the organization configures itself, with per-source deduplication so a single issue is not double-counted. It does not decide which framework binds your organization, does not set your day-counts, and does not patch anything. A named human owns the tier definitions and the remediation decisions.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.