NIST enriched nearly 42,000 CVEs in 2025, a 45% increase over previous years. Yet they just announced they're scaling back. Why? CVE submissions jumped 263% between 2020 and 2025, and the old model of comprehensive enrichment broke under the load.
For compliance teams, this isn't just a NIST problem—it's a forcing function. You can't wait for government databases to tell you what matters. This checklist helps you build a risk-based triage process that works whether NIST enriches a CVE or not.
Checklist Overview
This guide helps you prioritize vulnerabilities when volume overwhelms traditional workflows. You'll establish criteria for what gets patched first, automate the initial triage, and maintain compliance documentation that auditors accept.
Prerequisites
Before you start, ensure you have:
- Access to multiple vulnerability feeds: NIST NVD, CISA KEV catalog, vendor advisories, and at least one commercial threat intelligence source.
- Asset inventory with criticality ratings: Know what's running where and what it protects.
- Defined SLAs for patch deployment: Critical, high, medium, low—with realistic timelines.
- Scanning infrastructure that can tag findings: Correlate CVEs with your asset criticality and exposure.
Risk-Based Vulnerability Triage Checklist
1. Configure automated ingestion of CISA KEV catalog entries
Set up daily pulls from the CISA Known Exploited Vulnerabilities catalog. Any CVE that appears here moves to your critical queue automatically, regardless of CVSS score.
Good looks like: Your ticketing system creates P1 incidents within 1 hour of CISA adding a CVE to KEV, with automatic assignment to the relevant asset owner.
2. Map your software inventory to Executive Order 14028 critical software categories
Identify which of your applications fall under EO 14028 definitions: software with privileged access to networks, security functions, or direct access to networking/computing resources. NIST prioritizes enrichment for these categories.
Good looks like: A maintained spreadsheet or CMDB field that tags applications as "EO 14028 critical" with justification, reviewed quarterly.
3. Establish a tiered enrichment process that doesn't depend on NIST
Since NIST now enriches selectively, build your own lightweight enrichment for everything else. Define who checks for exploit code availability, whether the vulnerability is remotely exploitable, and if it affects internet-facing assets.
Good looks like: A documented runbook with specific checks (GitHub exploit search, Exploit-DB, vendor bulletins) and a 4-hour SLA for initial enrichment of high-CVSS findings.
4. Create decision criteria beyond CVSS scores
CVSS alone won't tell you what to patch first. Document your priority matrix that considers: CISA KEV status, exploit availability, asset criticality, internet exposure, and compensating controls.
Good looks like: A scoring rubric that produces "patch within 24h", "patch within 7d", "patch within 30d", or "accept risk" outcomes, with approval requirements for each tier.
5. Implement automated tagging for internet-facing assets
Your scanner needs to know which findings affect externally accessible systems. This context matters more than the CVE's CVSS score in most risk calculations.
Good looks like: Scan results automatically tagged with "external" or "internal" based on network zone, with separate SLAs for each (e.g., 7 days external vs. 30 days internal for high-severity findings).
6. Set up vendor-specific advisory monitoring
NIST's selective enrichment means you can't rely on NVD for complete coverage of your technology stack. Subscribe to security advisories from every vendor in your environment.
Good looks like: RSS feeds or email subscriptions for all major vendors, routed to a shared mailbox, with weekly review responsibility assigned and documented.
7. Document your rationale for deprioritizing low-risk CVEs
Auditors will ask why you didn't patch everything. Maintain records showing how you classified vulnerabilities as low-risk, including the criteria you applied and who approved the decision.
Good looks like: Risk acceptance forms for any CVE older than 90 days marked as low priority, signed by the asset owner and security team, referencing your priority matrix.
8. Establish a feedback loop from incident response to triage criteria
When you get compromised, update your prioritization rules based on what the attacker exploited. This keeps your model aligned with real-world threat patterns.
Good looks like: Post-incident reviews include a "triage improvement" section, and your priority matrix shows version history with justifications for criteria changes.
9. Configure compliance reporting that shows risk-based decision making
Your SOC 2 Type II or ISO 27001 auditor needs to see that you're managing vulnerabilities systematically, not that you've patched everything. Build reports showing coverage of critical assets and high-risk findings.
Good looks like: Monthly metrics showing: percentage of CISA KEV findings remediated within SLA, mean time to patch for critical internet-facing assets, and trend lines for your risk score (not just open CVE count).
10. Test your process with a tabletop exercise
Run a scenario where a new CVE drops for a critical component, NIST hasn't enriched it yet, and you need to decide within 4 hours whether to emergency-patch production.
Good looks like: Your team can execute the triage runbook, reach a patch/no-patch decision, and document the rationale—all within your defined SLA, without waiting for external enrichment.
Common Mistakes
Waiting for CVSS scores before acting: If it's in CISA KEV, you patch it. The score doesn't matter. Teams that wait for NIST enrichment before starting remediation work miss their SLA windows.
Treating all internet-facing assets equally: Your public marketing site and your authentication API have different risk profiles. Tag assets with business impact ratings, not just network exposure.
Ignoring vendor advisories because they're not in NVD yet: The 263% increase in CVE submissions means lag time between vendor disclosure and NIST enrichment. Your vendor knows their product's risk before NIST does.
Building priority rules you can't actually execute: A 24-hour SLA for "all high-severity findings" sounds good until you have 3,000 of them. Be honest about capacity and focus on what actually reduces risk.
Next Steps
Start with items 1, 2, and 4—CISA KEV automation, critical software mapping, and priority criteria. These give you immediate wins and form the foundation for everything else.
Then tackle your vendor advisory monitoring (item 6) and compliance reporting (item 9). These take longer to set up but prevent surprises during audits.
Schedule your tabletop exercise (item 10) for 60 days out. That gives you time to implement the process and pressure-test it before an actual emergency.
The vulnerability flood isn't stopping. NIST's selective enrichment is the canary in the coal mine—you need a triage system that works at scale, with or without government support.
