Library Vulnerability Update Policy Guide - Designing Severity-Based SLAs from Global Standards

“How many days should we allow to patch a library vulnerability?” — no single authoritative standard provides a universal answer. NIST says “within an organization-defined time period,” ISO 27001 calls for “appropriate and timely action,” and most other frameworks use similarly qualitative language.

Yet concrete, severity-based deadlines do exist.

Framework	Key Deadlines
CISA BOD 19-02	Critical 15 calendar days / High 30 calendar days
FedRAMP	Critical/High 30 days / Moderate 90 days / Low 180 days
PCI DSS	Critical 30 days
UK SS-033	Critical 7 days (conditional) / High 14 days / Medium & Low 45 days
AUS ASD	Active exploit 48 hours / Others 2 weeks

By combining these anchor points, organizations can build well-grounded patching SLAs.

This article surveys major global and Japanese standards at the primary-source level and presents a unified SLA that any organization can adapt.

What “Severity” Actually Means — Positioning CVSS

Before designing severity-based SLAs, let’s clarify the CVSS classification we’ll use as our baseline.

Severity	CVSS v3.1 Score	Response Direction
Critical	9.0–10.0	Top priority. Easy to exploit remotely with catastrophic impact
High	7.0–8.9	Rapid response needed. Serious impact but more complex attack conditions
Medium	4.0–6.9	Address within regular update cycles
Low	0.1–3.9	Address during planned maintenance

However, CVSS measures severity, not risk. A Medium-scoring vulnerability with confirmed active exploitation should be treated as Critical. Our SLA design therefore always factors in:

Exploitability: Active exploitation (in-the-wild), KEV catalog listing
Asset exposure: Internet-facing vs. internal systems
Mitigations available: Whether WAF rules, network segmentation, or other compensating controls are feasible

The Three Global Frameworks with Hard Deadlines

Among the world’s many security frameworks, only a handful prescribe binding, severity-based remediation timelines.

CISA Binding Operational Directives (United States)

CISA enforces the most aggressive timelines through two complementary directives.

BOD 19-02 (2019) mandates that internet-facing federal systems remediate Critical vulnerabilities within 15 days and High vulnerabilities within 30 days.

BOD 22-01 (2021) shifts focus from CVSS scores to Known Exploited Vulnerabilities (KEV), assigning per-CVE deadlines: two weeks for CVEs assigned in 2021 or later, and six months for older CVEs. CISA’s analysis shows that 42% of exploited CVEs are weaponized on day zero, and 75% within 28 days.

FedRAMP (United States)

FedRAMP fills in the blank parameters that NIST SP 800-53 deliberately leaves to organizations, creating the most comprehensive severity-tiered framework currently in effect.

Severity	Remediation Deadline
Critical / High	30 days
Moderate	90 days
Low	180 days

These 30/90/180-day timelines have become the de facto industry benchmark, referenced even by organizations with no FedRAMP obligation.

PCI DSS v4.0.1 (International)

PCI DSS v4.0.1 (June 2024), Requirement 6.3.3, mandates that critical security patches be installed within 30 days of release. For High and below, the timeline is “as determined by the entity.”

Notably, PCI DSS v4.0 had proposed a 30-day requirement for both Critical and High patches, but v4.0.1 narrowed this back to Critical only — an intentional design choice to preserve risk-based judgment for organizations.

Framework-Based Standards — No Numbers, But Process Requirements

Most major standards avoid prescribing specific day counts, instead requiring organizations to define and operate their own SLAs.

NIST SP 800-53 Rev 5 / SP 800-40r4

NIST SP 800-53’s SI-2 (Flaw Remediation) requires security updates “within [Assignment: organization-defined time period].” The commonly cited “30/90/180 days” actually originates from FedRAMP’s parameterization, not from NIST itself.

SP 800-40r4 (2022) frames patching as “preventive maintenance” and broadly scopes its guidance to all software and firmware, making it directly applicable to dependency management.

ISO/IEC 27001:2022 / 27002:2022

ISO 27002:2022 Control 8.8 (Management of Technical Vulnerabilities) requires “appropriate and timely action” but prescribes no numerical deadlines whatsoever. Certification audits evaluate whether a functioning process exists, not whether specific day counts are met. The “48-hour Critical” figure sometimes cited by auditors has no basis in the standard text.

SOC 2 (AICPA Trust Services Criteria)

SOC 2’s CC7.1 requires vulnerability scans “on a periodic basis” with remediation “on a timely basis.” As a principles-based framework, auditors evaluate whether controls operate effectively as designed — not against specific timelines.

CIS Controls v8.1

CIS Controls take a uniform approach: automated patch management running monthly or more frequently, with no severity differentiation.

Additional Standards with Concrete Timelines

Beyond the big three, two government standards provide particularly useful severity-tiered benchmarks.

UK Security Standard SS-033 (2024)

The UK Department for Work & Pensions’ SS-033 is one of the most directly actionable primary sources for severity-based SLAs:

Severity	Deadline	Exception Review
Critical (conditions met; otherwise 14 days)	7 days	—
High	14 days	—
Medium	45 days	—
Low	45 days	3 months maximum for risk acceptance

Australian ASD/ACSC Patching Guidance (2023)

Australia’s Signals Directorate recommends patching internet-facing services within two weeks, tightening to within 48 hours when the vendor rates the vulnerability as Critical or when working exploits exist.

Cross-Reference Comparison Table

Framework	Critical	High	Medium	Low	Binding?
CISA BOD 19-02	15 days	30 days	—	—	Mandatory (federal)
CISA BOD 22-01 (KEV)	Per-CVE (2 weeks / 6 months for older CVEs)	Same	Same	Same	Mandatory (federal)
FedRAMP Rev5	30 days (same as High)	30 days	90 days (Moderate)	180 days	Mandatory (CSPs)
PCI DSS v4.0.1	30 days	Entity-defined	Entity-defined	Entity-defined	Mandatory (cardholder data)
CIS Controls v8.1	30 days (uniform)	30 days	30 days	30 days	Voluntary
NIST SP 800-53	Org-defined	Org-defined	Org-defined	Org-defined	Mandatory (federal)
ISO 27001/27002	Not specified	Not specified	Not specified	Not specified	For certification
SOC 2	Not specified	Not specified	Not specified	Not specified	For attestation
UK SS-033	7 days (conditional, else 14)	14 days	45 days	45 days	Mandatory (scope)
AUS ASD/ACSC	48 hours (exploit)	2 weeks	2 weeks	2 weeks	Recommended

Unified SLA Design — Building an Operationally Practical Policy

Synthesizing the above, here is a unified SLA suitable for most organizations. It uses the UK SS-033 (7/14/45 days), Australian ASD (48 hours), and IPA (triage/permanent two-phase model) as external benchmarks while satisfying the process requirements of NIST, SOC 2, and ISMS.

Severity (CVSS)	Triage Start	Interim Mitigation	Permanent Fix (Patch)	Notes
Critical (9.0–10.0)	Same day	48 hours	7 days (14 days max)	Shortest timeline for internet-facing + exploit confirmed
High (7.0–8.9)	1 business day	As needed	14 days	Escalate to Critical if easily exploitable + high exposure
Medium (4.0–6.9)	5 business days	As needed	45 days	Handle within change management process
Low (0.1–3.9)	Regular triage	Generally not needed	Routine updates / re-evaluate within 3 months if accepted	Quarterly inventory review

Two-Phase Response: Interim and Permanent

A key practical insight is separating responses into two phases:

Interim mitigation: When patching takes time, reduce the attack surface immediately through WAF custom rules, feature disablement, or network isolation
Permanent fix: Library upgrade, patch application, or migration to an alternative

flowchart TD
    A[Vulnerability Detected] --> B[Impact Assessment & Triage]
    B --> C{Critical / KEV / Exploit?}
    C -- Yes --> D[Interim Mitigation within 48h]
    D --> E[Permanent Fix within 7 days]
    E --> F[Verification & Re-scan]
    F --> G[Record & Close]
    C -- No --> H{High?}
    H -- Yes --> I[Patch within 14 days]
    I --> F
    H -- No --> J[Queue for Regular Update]
    J --> F
    B --> K{Exception - Accept Risk?}
    K -- Yes --> L[Risk Acceptance Approval]
    L --> M[Compensating Controls + Re-review within 3 months]
    M --> J

Aligning with ISMS and SOC 2 Audits

Despite different terminology, ISMS and SOC 2 audits ask essentially the same questions about vulnerability management.

Audit Concern	ISMS (ISO 27001)	SOC 2 (TSC)
Can you detect vulnerabilities?	Control 8.8: Technical vulnerability management	CC7.1: Identify susceptibilities
Can you prioritize?	Risk assessment process	Risk-based remediation
Can you remediate within deadlines?	PDCA cycle operational evidence	”Timely” objective evidence
Are exceptions controlled?	Residual risk acceptance & review	Documented exception approval
Is there an audit trail?	Internal audit records	Operating effectiveness over observation period

To objectify SOC 2’s “timely,” you need documented severity-based SLAs with compliance rate tracking as a KPI. In a SOC 2 Type II audit, every patch must be shown to have been applied within the defined timeline across a 3–12 month observation period. A single significant deviation risks being reported as an “Exception.”

An audit-ready policy should include at minimum:

Documented process: Information sources, triage criteria, severity-based SLAs, change management integration, exception management (approver, deadline, compensating controls)
Regularity and continuity: Continuous dependency monitoring (SCA), external assets scanned monthly or more, internal assets quarterly or more
Evidence trail: Detection → triage → mitigation → application → verification → close, SLA compliance rates, exception review records

Automation Best Practices

Three-Layer SCA Operations

Effective vulnerability management automation operates across three layers:

Continuous monitoring: Dependabot / Renovate / Snyk for always-on dependency monitoring
Scheduled updates: Monthly to quarterly batch library updates
Emergency response: SLA-driven immediate response for Critical / KEV vulnerabilities

Strategic Dependabot / Renovate Configuration

Simply enabling notifications leads to alert fatigue. Configure strategically:

Separate security from feature updates: Route security fixes through a priority pipeline; auto-merge patch-version (z-stream) updates after tests pass
Implement cooldown periods: Wait 3–7 days after new version releases to guard against supply chain attacks — but bypass this for known vulnerability patches
Leverage EPSS and reachability: Go beyond CVSS by incorporating EPSS (Exploit Prediction Scoring System) and function-level reachability analysis to filter actionable alerts

Exception Management When Patching Isn’t Possible

Legacy systems and compatibility issues will inevitably prevent timely updates. Rather than ignoring these, document the following process — required for SOC 2 and PCI DSS audits:

Formal exception request: Document technical and business reasons for non-compliance
Compensating controls: WAF custom signatures, network micro-segmentation, IPS hardening
Time-bound risk acceptance: Security leadership approval with mandatory re-review within 3 months

Key Takeaways

Few standards prescribe concrete timelines: CISA BOD 19-02 (15/30 days), FedRAMP (30/90/180 days), PCI DSS (30 days), and UK SS-033 (7/14/45 days) are the primary anchor points
Most standards require “define your SLA and operate it”: NIST, ISO 27001, SOC 2, and CIS Controls all follow this structure
CVSS alone is insufficient: The trend is toward exploitation-aware prioritization combining KEV/EPSS, asset exposure, and mitigation availability
Two-phase response is practical: Separate interim mitigation (shrink the attack surface immediately) from permanent fixes (planned library upgrades)
Exception management and evidence are audit keys: Both SOC 2 and ISMS require documented SLAs, compliance rate tracking, and controlled exceptions

There is no single right answer to “how many days to patch,” but by cross-referencing global standards, you can design an SLA that is well-grounded, audit-ready, and operationally practical.