Starting April 15, NIST will stop enriching and scoring lower-priority vulnerabilities. Submission volumes grew 263% while NIST enriched 42,000 CVEs in 2025 — they can't keep up. If your vulnerability management process relies on waiting for CVSS scores to appear in the National Vulnerability Database, you need a new approach by mid-April.
This checklist helps you build an internal vulnerability prioritization framework that doesn't depend on NIST's full coverage. Each item produces a specific artifact or capability you can verify.
Checklist Overview
You'll establish criteria for triaging vulnerabilities without external severity scores, identify which tools can fill the gap, and define ownership for ongoing assessment. This isn't about replacing NIST — it's about ensuring you can make risk decisions when NIST's analysis isn't available.
Prerequisites
Before starting this checklist, verify:
- Inventory completeness: You have a current SBOM (Software Bill of Materials) or dependency list for all production systems.
- Tool access: Your team can query vulnerability databases beyond NVD (GitHub Advisory Database, vendor security bulletins, OSV).
- Authority: Someone with budget authority has approved time for this work — building triage criteria requires input from both security and engineering.
Vulnerability Prioritization Checklist
1. Define Your Priority Criteria
Action: Document which vulnerability characteristics trigger immediate analysis at your organization, independent of CVSS scores.
What good looks like: A written policy stating that vulnerabilities meeting any of these conditions get full analysis within 24 hours:
- Present in CISA's Known Exploited Vulnerabilities catalog
- Affects critical software as defined by Executive Order 14028 (software with privileged access, direct control of hardware/systems, or critical operational functions)
- Found in internet-facing components
- Exists in dependencies handling authentication, authorization, or payment data
- Has public exploit code available
2. Map Your Attack Surface to Priority Zones
Action: Classify every application and service into risk tiers based on data sensitivity and exposure.
What good looks like: A spreadsheet or asset management system where each application has a tier (1-4) with explicit criteria. Tier 1 might include anything processing payment card data (PCI DSS), storing credentials, or accessible without VPN. Vulnerabilities in Tier 1 assets get analyzed regardless of external scoring.
3. Establish Vendor Security Bulletin Monitoring
Action: Subscribe to security advisories from every vendor whose software you run in production. Create a routing system so these reach your security team, not just IT operations.
What good looks like: A monitored email alias or Slack channel receiving vendor bulletins. Each bulletin triggers a ticket in your vulnerability management system within 4 hours of receipt. You're not waiting for NVD — you're acting on vendor disclosure.
4. Deploy Automated Dependency Scanning
Action: Integrate SCA (Software Composition Analysis) tools into your CI/CD pipeline that query multiple vulnerability databases, not just NVD.
What good looks like: Pull requests automatically blocked if they introduce dependencies with known vulnerabilities in your priority criteria (item #1). The tool checks GitHub Advisory Database, OSV, and vendor-specific databases. Developers see results before merge, not weeks later when NIST publishes enrichment.
5. Create Exploitability Assessment Criteria
Action: Define how your team evaluates whether a vulnerability is actually exploitable in your environment when external analysis isn't available.
What good looks like: A decision tree your analysts follow: Is the vulnerable function reachable from untrusted input? Does existing security architecture (WAF, network segmentation) prevent exploitation? Can you demonstrate non-exploitability through testing? Document the answers — "we think it's fine" isn't sufficient for audit purposes.
6. Assign Triage Ownership
Action: Designate who makes the call on vulnerabilities without CVSS scores. This cannot be "the security team" — name a role and backup.
What good looks like: Your vulnerability management procedure names a specific role (Security Architect, Lead AppSec Engineer) authorized to assign internal severity ratings. That person has documented criteria (items #1 and #5) to apply. Their decisions get logged in your ticketing system with justification.
7. Build an Exception Process
Action: Create a workflow for vulnerabilities you decide not to fix, especially when you lack external severity guidance.
What good looks like: A risk acceptance form requiring: vulnerability description, affected systems, exploitability analysis (item #5), compensating controls, business justification, and approver signature. This satisfies ISO 27001 Annex A.5.1 (policies for information security) and gives you an audit trail.
8. Test Your Process with Historical Data
Action: Take 20 CVEs from the past quarter that NIST scored as "Low" or "Medium." Run them through your new triage criteria.
What good looks like: You identify at least 2-3 that would have required immediate action under your criteria despite lower CVSS scores — perhaps they were in internet-facing components or had exploit code available. This validates your criteria catch what matters to your environment, not just what NIST prioritizes.
9. Document Tool Limitations
Action: Record which vulnerability sources your tools don't cover and how you'll monitor those gaps.
What good looks like: A list stating: "Our SCA tool doesn't scan [language/ecosystem]. We monitor this through [manual review cadence/alternative tool]." This prevents the assumption that automated scanning catches everything.
10. Schedule Quarterly Criteria Review
Action: Set recurring calendar holds to revisit your priority criteria (item #1) based on your organization's changing risk profile.
What good looks like: A quarterly meeting where security leadership reviews: Did we miss critical vulnerabilities with our criteria? Did we over-invest in low-risk items? Adjust criteria based on actual incidents and near-misses. Update the documented policy with version numbers and change dates.
Common Mistakes
- Waiting for CVSS scores to make decisions: After April 15, many vulnerabilities won't have scores. Your criteria (item #1) must work without them.
- Treating all unscored vulnerabilities as low-priority: NIST is deprioritizing based on their mission, not your risk profile. A vulnerability in your internet-facing API might not meet NIST's criteria but could be critical for you.
- Ignoring vendor bulletins: Vendors often disclose and patch before CVEs are published. If you only monitor NVD, you're weeks behind.
- No written justification for triage decisions: "We decided it wasn't important" won't satisfy auditors. Document your reasoning using your criteria.
Next Steps
- Complete items #1-6 before April 15 — these establish your minimum viable triage capability.
- Run the historical test (item #8) in the first week after deployment to validate your approach.
- Brief your engineering teams on the change: they'll see more vulnerabilities flagged without official CVSS scores and need to understand your internal rating system.
- Add a line item to your SOC 2 Type II or ISO/IEC 27001:2022 audit preparation: "Vulnerability triage process independent of external severity ratings."
NIST's change forces a maturity step many organizations should have taken already. You're building the capability to assess risk in your specific context rather than outsourcing that judgment to a general-purpose database.
