When CrowdStrike reports that attackers now move from initial access to lateral movement in 29 minutes, your 30-day patch window isn't just slow, it's irrelevant. CISA's Binding Operational Directive 26-04 acknowledges this reality by mandating risk-based patching for federal agencies, with remediation deadlines as short as three days for critical exposures.
This checklist helps you implement risk-based vulnerability management that aligns with BOD 26-04's approach, even if you're not a federal agency. The core principle applies universally: patch what matters most, first.
Prerequisites
Before you start, you need:
- Asset inventory with business context: You can't assess risk without knowing what systems do. Your CMDB should include data classification, revenue impact, and user access patterns.
- Vulnerability scanner with API access: Manual exports won't scale. You need programmatic access to vulnerability data.
- Defined SLAs for each risk tier: Your organization must agree on what "high risk" means and how fast you'll respond.
- Stakeholder buy-in from business units: Risk-based patching requires input from people who understand business impact, not just CVE scores.
Checklist Items
1. Define Your Risk Tiers Based on Real Exposure
☐ Document what constitutes each risk tier using multiple factors: exploitability, asset criticality, exposure, and business impact, not just CVSS scores.
☐ Reference BOD 26-04's framework as a starting point: three days for highest-risk vulnerabilities, seven days for high-risk, thirty days for moderate-risk.
☐ Create explicit criteria for each tier. For example, highest-risk might be: "Exploited in the wild AND affects internet-facing systems AND handles customer data."
What good looks like: Your developers can look at a vulnerability and predict which tier it falls into without waiting for security team review.
2. Map Vulnerabilities to Business Context
☐ Tag each asset with its business function, data classification, and regulatory scope (PCI DSS cardholder data environment, SOC 2 Type II in-scope systems, etc.).
☐ Cross-reference vulnerability scanner output with your asset inventory to automatically inherit business context.
☐ Identify which vulnerabilities affect revenue-generating systems versus internal tools.
What good looks like: When a new CVE drops, you know within minutes whether it affects your payment processing stack or your internal wiki.
3. Integrate Threat Intelligence
☐ Subscribe to at least one threat intelligence feed that tracks active exploitation (CISA KEV catalog is free and mandatory for federal compliance).
☐ Automate the promotion of any vulnerability to highest-risk tier if it appears in CISA KEV, regardless of CVSS score.
☐ Monitor for proof-of-concept code releases, they typically precede widespread exploitation by days, not weeks.
What good looks like: You're patching actively exploited vulnerabilities before your scanner even classifies them as critical.
4. Establish Fast-Track Patching Procedures
☐ Document an expedited change control process for highest-risk vulnerabilities. If your normal change window is two weeks out, you need a process that deploys in hours.
☐ Pre-approve specific types of security patches (OS security updates, application framework patches) so they don't require full CAB review.
☐ Identify which systems can be patched without business approval and which require stakeholder sign-off.
What good looks like: You can deploy an emergency patch to internet-facing systems within the same business day it's released, with appropriate testing.
5. Create Compensating Controls for Unpatchable Systems
☐ Document every system that can't meet your standard patch SLAs (legacy applications, vendor-managed systems, operational technology).
☐ Implement and verify compensating controls: network segmentation, WAF rules, access restrictions, enhanced monitoring.
☐ Review compensating controls quarterly, they're temporary measures, not permanent solutions.
What good looks like: Your audit log shows exactly why system X hasn't been patched in 90 days and what controls mitigate the risk.
6. Measure and Report on Risk Reduction, Not Patch Counts
☐ Track mean time to remediate (MTTR) separately for each risk tier.
☐ Report on the percentage of highest-risk vulnerabilities remediated within SLA, not total vulnerabilities patched.
☐ Calculate risk exposure over time: How many critical-asset-days of exposure did you accumulate this month?
What good looks like: Your executive dashboard shows "98% of highest-risk vulnerabilities remediated within 3 days" instead of "patched 1,247 vulnerabilities this month."
7. Test Your Process Under Pressure
☐ Run a tabletop exercise where a critical vulnerability drops on Friday afternoon. Who makes the call to patch over the weekend?
☐ Verify that your escalation procedures work: Can you reach business stakeholders outside business hours?
☐ Document what went wrong and update your procedures.
What good looks like: When the next Log4j happens, your team executes a documented playbook instead of improvising.
Common Mistakes
Treating all "critical" CVSS scores equally: A CVSS 9.8 vulnerability in an isolated development tool isn't the same risk as a CVSS 7.5 in your authentication service. Business context matters more than the number.
Ignoring compensating controls in risk calculations: If you've blocked all external access to a vulnerable service, it doesn't belong in your highest-risk tier just because the CVE is scary.
Patching everything immediately: Paradoxically, trying to patch everything fast means you'll patch nothing fast. Triage ruthlessly.
Forgetting to update risk tiers as context changes: A vulnerability in a system you just moved to the internet needs reclassification, even if the CVE hasn't changed.
Next Steps
Start with your internet-facing systems. Implement risk tiers for those assets first, then expand internally. You don't need to overhaul your entire vulnerability management program on day one.
Schedule a monthly review of your risk tier definitions. As AI continues to accelerate attack timelines, what qualified as "moderate risk" six months ago might need reclassification.
Most importantly: document your decisions. When you choose not to patch something within the standard window, write down why. Your future auditor (and your future self) will thank you.
The 29-minute breakout time isn't slowing down. Your patch process needs to speed up, selectively.
