If you're still patching every CVE in CVSS score order, you're wasting resources on vulnerabilities that don't threaten your organization while active exploits remain unpatched. CISA's recent addition of four vulnerabilities to its Known Exploited Vulnerabilities Catalog highlights the need for risk-based prioritization.
This checklist guides you in implementing the core principles from Binding Operational Directive 26-04, which requires prioritizing vulnerabilities that pose actual risk over theoretical severity scores. While BOD 26-04 applies to Federal Civilian Executive Branch agencies, its framework benefits any organization tired of chasing CVSS 9.8 vulnerabilities on internal servers while internet-facing assets run exploited code.
What This Checklist Covers
This checklist helps establish a risk-based vulnerability management program that prioritizes patching based on exploit evidence, asset criticality, and exposure rather than severity scores alone. You'll end with a defensible process that focuses remediation efforts where they matter most.
Prerequisites
Before starting, ensure you have:
- Asset inventory with exposure classification: You can't prioritize risk to assets you don't know exist. Your inventory must distinguish internet-facing systems from internal ones.
- Vulnerability scanning capability: Whether commercial or open-source, you need automated discovery of CVEs across your environment.
- Defined patch windows: Risk-based management requires different SLAs for different risk tiers. Document your existing patch cycles before restructuring them.
- Executive sponsor: Shifting from "patch everything high and critical" to "patch exploited vulnerabilities first" changes how you report metrics. Your CISO or CIO needs to understand why your critical vulnerability count might temporarily rise.
Checklist Items
1. Integrate the KEV Catalog into your vulnerability management workflow
Configure your vulnerability scanner or GRC platform to flag any CVE that appears in CISA's Known Exploited Vulnerabilities Catalog. This isn't a one-time import; the catalog updates regularly as CISA adds newly exploited vulnerabilities.
2. Classify all assets by control tier
Identify which systems, if fully compromised, would grant an attacker total control over critical data or operations. Adapt BOD 26-04 by classifying your assets into tiers based on exposure and potential impact.
3. Establish risk-based remediation SLAs
Replace your CVSS-based patch windows with risk-tiered requirements. KEV vulnerabilities on Tier 1 assets demand immediate action. Non-KEV criticals on Tier 4 assets can wait for the next maintenance window.
4. Implement pre-patch compromise detection for KEV remediation
When patching a KEV vulnerability, especially on internet-facing systems, determine if exploitation occurred before remediation. BOD 26-04 requires federal agencies to check for compromise; you should too.
5. Create a KEV response playbook
When CISA adds a vulnerability to the KEV Catalog, your team needs a defined process that doesn't require emergency meetings. Document roles for scanning, prioritizing, approving emergency patching, and communicating with stakeholders.
6. Track KEV remediation separately from overall patch metrics
Distinguish between KEV and non-KEV remediation rates in your vulnerability metrics. This shows you're addressing active threats faster than theoretical ones.
7. Submit KEV nominations when you detect exploitation
If you observe active exploitation of a CVE not yet in the KEV Catalog, submit it through CISA's nomination form. Include the CVE ID, evidence of exploitation, and clear mitigation guidance.
8. Review and update asset exposure quarterly
Systems move from internal to internet-facing. New applications launch. Risk tiers change. Your risk-based approach only works if asset classifications stay current.
Common Mistakes
Treating KEV as just another severity score: Organizations often add KEV to their existing CVSS-based workflow without changing prioritization. A KEV-listed CVE with CVSS 7.2 on an internet-facing server demands faster action than a non-KEV CVSS 9.8 on an internal system.
Ignoring internal assets entirely: BOD 26-04 focuses on publicly exposed assets, but lateral movement makes internal KEV vulnerabilities dangerous too. Don't skip them; just assign them longer remediation windows.
Failing to document pre-patch compromise checks: Patching a KEV vulnerability without checking for prior exploitation leaves you blind to whether you're closing the door after the attacker left. Even if you find nothing, document that you looked.
Setting unrealistic SLAs: If you commit to patching all KEV vulnerabilities in 72 hours but your change management process takes five days, you've created a compliance failure before you start. Design SLAs around your actual operational constraints.
Next Steps
After completing this checklist, you should have a functioning risk-based vulnerability management program. Your next moves:
- Run a tabletop exercise simulating a new KEV addition to test your response playbook.
- Analyze your last quarter's patch data to see how many KEV vulnerabilities you would have missed under your old CVSS-only approach.
- Brief your audit committee on the shift from severity-based to risk-based metrics so they understand why your critical vulnerability count might look different.
- Review your cyber insurance policy to confirm that KEV remediation speed meets any requirements for coverage.
The four vulnerabilities CISA just added to the KEV Catalog (CVE-2026-85102, CVE-2026-93616, CVE-2026-93952, and CVE-2026-94127) won't be the last. Organizations that wait for the next breach to prioritize exploited vulnerabilities will keep explaining to regulators why they patched theoretical risks while ignoring active threats.
