Vulnerability Management Policy Template (CVSS 4.0, EPSS, KEV, SSVC)

Vulnerability Management Policy: [Organisation name]

Enterprise policy for finding, prioritising, remediating and reporting vulnerabilities in the technology an organisation runs: scope and asset coverage, scanning cadence, risk-based prioritisation, remediation SLAs, exceptions and risk acceptance, metrics and reporting. Prioritisation combines FIRST CVSS v4.0 (November 2023), the FIRST Exploit Prediction Scoring System (EPSS), the CISA Known Exploited Vulnerabilities (KEV) catalog and a decision model in the style of the CISA Stakeholder-Specific Vulnerability Categorization Guide (November 2022: Track, Track*, Attend, Act). It draws on NIST SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning (April 2022) and describes the factors of CISA Binding Operational Directive 26-04 (June 2026) as a reference model. This is the consumer-side policy; product security response (producer side) is covered by PSIRT Vulnerability Handling (security/psirt-vulnerability-handling) and EU CRA duties by CRA Vulnerability Handling and Reporting Procedure (security/cra-vulnerability-handling). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

1. Purpose
2. Scope
3. Roles and responsibilities
4. Asset coverage
5. Discovery and scanning cadence
6. Policy statements
7. Risk-based prioritisation
8. Remediation SLAs
9. Remediation, verification and closure
10. Exceptions and risk acceptance
11. Metrics
12. Reporting and governance
13. Compliance measurement and review
14. Related documents
15. Glossary and references

1. Purpose

This policy sets how [Organisation name] identifies vulnerabilities in the systems it operates, decides which to fix first, fixes or mitigates them within defined times, and accepts risk when it cannot. Its objectives are:

1. Reduce the window in which known exploited vulnerabilities are reachable on [Organisation name] systems.
2. Spend remediation effort where exploitation is likely and impact is high, not where scores are merely high.
3. Make every unremediated vulnerability past its SLA a visible, owned and time-limited decision.
4. Give leaders and customers reliable evidence of vulnerability exposure and trend.

2. Scope

2.1 In scope

• All hardware, operating systems, firmware, applications, containers, cloud services, network and security appliances, and third-party components that [Organisation name] owns, operates or configures, in all environments that hold production data or connect to production.
• Open source and commercial dependencies in software that [Organisation name] builds and runs (consumer view of software composition analysis findings).
• Cloud configuration weaknesses with a CVE or vendor advisory. General misconfigurations are handled by Cloud Security Posture Review (security/cloud-security-posture-review).
• Suppliers that operate systems on behalf of [Organisation name], through contract clauses requiring equivalent SLAs.

2.2 Out of scope

3. Roles and responsibilities

R = responsible, A = accountable, C = consulted, I = informed.

4. Asset coverage

4.1 Asset tiers

4.2 Assessment methods per asset class

5. Discovery and scanning cadence

Intake sources: scanners, SCA, the CISA KEV catalog, vendor advisories, CSAF and VEX documents from suppliers, threat intelligence, bug bounty and penetration test reports, and internal reports. Where a supplier publishes a VEX statement that a product is not affected, record it and close the finding with that evidence (see SBOM and VEX Policy, security/sbom-vex-policy).

6. Policy statements

7. Risk-based prioritisation

7.1 Inputs

Decision point names follow the CISA SSVC guide (Exploitation, Technical Impact, Automatable, Mission Prevalence, Public Well-being Impact, and the combined Mission and Well-being). The guide contains the full CISA decision tree; the table in 7.2 is an organisation-specific simplification in original wording.

7.2 Decision model (Example)

Evaluate the rules in order; the first match sets the decision.

Decision meanings, paraphrasing the CISA guide:

• Track: no action outside the standard remediation cycle.
• Track*: remediate in the standard cycle but monitor closely for changes, such as new exploitation.
• Attend: remediate sooner than standard timelines; supervisory-level staff are involved, and the issue may be notified internally or externally.
• Act: remediate as soon as possible with supervisory and leadership attention; coordinate internally and, where needed, externally.

7.3 Overlays (Example)

1. KEV overlay. A KEV listing sets Exploitation to Active (VM-04).
2. EPSS overlay. If the EPSS probability is at or above [0.10] (Example), raise Track to Track*, and Track* to Attend when the asset is T1.
3. Exposure overlay. A T1 asset raises Track* to Attend when Technical impact is Total.
4. Compensating control downgrade. A verified control that removes the attack path (for example the vulnerable service is disabled) can lower the decision by one level with a recorded reason; it does not close the finding.
5. Missing inputs. If decision inputs cannot be established within one business day, use CVSS-BTE: 9.0 or above is treated as Attend, 7.0 to 8.9 as Track*, otherwise Track, until the analysis is complete. A KEV-listed finding is never handled under this fallback: it starts at Attend or above.
6. Regulatory and directive overlay. Where a binding directive, regulation or contract sets shorter timelines for a system, those timelines override this internal model. For US federal systems, and for supplier systems where a contract imposes it, CISA BOD 26-04 applies: take the timeline for each combination of factors from Table 1 of the directive at cisa.gov, and use it whenever it is shorter than the SLA in section 8. A KEV-listed finding on an exposed asset (T1 or internet-reachable flag set) MUST never fall into the slowest band: its decision is never lower than Attend, overlay 4 cannot lower it further, and when its technical impact is Total it is handled as Act with the compromise check in section 9.3.

7.4 Reference model: CISA BOD 26-04

CISA Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk (10 June 2026), applies to US federal civilian executive branch agencies and replaces BOD 22-01 and BOD 19-02. It sets remediation timelines from a combination of four factors: whether the affected asset is publicly exposed, whether the vulnerability is in the KEV catalog, whether exploitation is automatable, and the technical impact of exploitation. The day counts for each combination are set in the directive's table and its implementation guidance, which CISA updates; they are not reproduced here. Organisations that must comply, or want to align, should read the directive and implementation guidance at https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk and set the SLA matrix in section 8 to be no slower than the directive requires for the systems it covers.

Mapping of this policy's inputs to the directive's factors:

7.5 Worked prioritisation (Example)

8. Remediation SLAs

All values are Example values measured in calendar days from detection.

Rules:

1. "Next standard patch cycle" refers to the routine cadence in Patch Management Policy (ops/patch-management-policy).

2. When a regulation, directive or contract sets a shorter time for a system, the shorter time applies (overlay 6 in section 7.3). Record those timelines here so analysts do not have to look them up per finding:

   Directive or contract	Systems covered	Timelines
   CISA BOD 26-04 (if it applies)	[Systems in scope of the directive or of a contract that imposes it]	[Copy the current Table 1 from the directive at cisa.gov, with the date you copied it]
   [Customer contract or regulation]	[Systems]	[Timelines]

3. If no fix exists, apply a vendor-recommended mitigation within the SLA and track the fix as a dependent action; a mitigation without a fix keeps the finding open with status "Mitigated".

4. A finding's SLA is recalculated from the date its decision rises (for example when it is added to KEV), and never extended when its decision falls.

5. End-of-support software follows VM-08 regardless of individual finding SLAs.

9. Remediation, verification and closure

9.1 Remediation options, in order of preference

1. Apply the vendor fix or upgrade to a fixed version.
2. Remove the vulnerable component or decommission the asset.
3. Apply a configuration change or vendor mitigation that removes the attack path.
4. Apply a compensating control (network isolation, WAF rule, feature disable) with an exception if the SLA will be missed.

9.2 Verification and closure

A finding that reappears within 90 days (Example) reopens with its original detection date for SLA measurement.

9.3 Act decisions on exposed assets

For an Act decision on a T1 asset, and for any finding the directive overlay (section 7.3, overlay 6) places in a directive's fastest tier, such as a KEV-listed vulnerability with total technical impact:

1. Open a security incident or emergency change per Incident Severity Matrix (ops/incident-severity-matrix).
2. Apply the mitigation or fix and verify by rescan.
3. Ask the SOC to hunt for indicators of exploitation from the earliest public exploitation date, using vendor and CISA guidance, and to preserve evidence if any are found.
4. Record the outcome of the compromise check on the finding.

10. Exceptions and risk acceptance

10.1 Approval levels (Example)

10.2 Exception record

Rules: exceptions are requested before the SLA expires (VM-06); expired exceptions revert the finding to overdue; a Medium or High residual risk is recorded in the enterprise risk register (Risk Register Template, compliance/risk-register).

11. Metrics

Example (Corvid Commerce, Q3): 4,410 of 4,600 inventoried assets assessed in cadence: coverage = 4,410 / 4,600 = 95.9%. 1,180 findings closed, 1,062 within SLA: adherence = 1,062 / 1,180 = 90.0%. KEV backlog at quarter end: 1 (VMF-088, under exception VMX-039).

12. Reporting and governance

13. Compliance measurement and review

1. The vulnerability management team checks compliance monthly using the metrics in section 11 and the inventory reconciliation.
2. Internal audit tests a sample of closed and excepted findings at least annually for evidence quality.
3. Repeated non-compliance by a team is escalated to its engineering director, then to the CISO.
4. The policy is reviewed annually and also when: a new directive or regulation changes timelines (for example BOD 26-04 implementation guidance updates), a major incident involves a known vulnerability, or SLA adherence stays below target for two quarters.

14. Related documents

15. Glossary and references

15.1 Glossary

15.2 References

• FIRST, Common Vulnerability Scoring System version 4.0, November 2023: https://www.first.org/cvss/
• FIRST, Exploit Prediction Scoring System (EPSS), scores published daily: https://www.first.org/epss/
• CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA, Stakeholder-Specific Vulnerability Categorization Guide, November 2022: https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
• CISA, Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, 10 June 2026, and its implementation guidance: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, April 2022: https://csrc.nist.gov/pubs/sp/800/40/r4/final
• NIST SP 800-53 Rev. 5, Release 5.2.0 (27 August 2025), controls RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Standard and licence note

Based on NIST SP 800-40 Rev. 4 (April 2022), NIST SP 800-53 Rev. 5, the CISA Stakeholder-Specific Vulnerability Categorization Guide (November 2022), the CISA KEV catalog and CISA BOD 26-04 (June 2026), which are works of the United States Government. SSVC decision point and outcome names are cited from the CISA guide; the decision rules in section 7.2 are an original simplification, not the CISA tree. CVSS and EPSS are FIRST specifications cited by name and notation only; no FIRST text is reproduced. BOD 26-04 day counts are deliberately not reproduced: read the directive and its implementation guidance. Check the current official versions at cisa.gov, nist.gov and first.org before relying on this policy, as updates may have been published. CVSS and EPSS are marks of FIRST; this template is not affiliated with or endorsed by FIRST or CISA. Original text written for this collection. Template licence: MIT.