CISA KEV triage checklist for small IT teams

CalculatedIT Threat Pulse editorial resource · Reviewed against CISA and NIST primary references · No registration required

When to use this checklist

The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities for which CISA has determined there is evidence of exploitation in the wild. It is a particularly useful prioritization signal, but it does not tell you whether your own devices are affected. Your response needs an inventory match, exposure analysis, an authorized fix, and evidence that the fix worked.

Federal deadline caution: CISA Binding Operational Directive 22-01 sets due dates for covered Federal Civilian Executive Branch agencies. It does not automatically impose those deadlines on every private business. Other contractual or regulatory commitments may still apply; confirm your own obligations.

Seven checks before you call an alert closed

1. Confirm the official record. Record the CVE ID, date added, product, CISA required action, and source link. Consult the vendor advisory for affected versions, unsupported versions, and mitigations. If a description is ambiguous, mark it as such.
2. Locate the asset and accountable owner. Correlate the advisory with asset inventory, endpoint management, vulnerability scanning, software bills of materials where available, and service-owner records. A product name resemblance is not evidence of vulnerability.
3. Validate applicability. Confirm the affected component and version are present and assess relevant configuration, authentication requirements, and feature enablement. Record the evidence and the time it was observed. An uncertain match should be investigated, not silently marked as not applicable.
4. Evaluate reachability and consequence. Note internet exposure, network segments, privilege requirements, business criticality, and compensating safeguards. Escalate quickly if an exploited issue affects an externally reachable critical system.
5. Select and authorize a response. Compare a vendor-supported patch or update, a vendor-supported mitigation, disabling the affected feature, isolation, or retirement. Assign a person, target date, change window, and rollback plan. Document any risk exception through the organization's approved process.
6. Capture before-and-after evidence. Keep the original finding identifier, asset reference, approved change ticket, relevant configuration or version observation, and post-change validation. Consider rescan results and false-positive or scan-coverage limitations.
7. Get closure reviewed. Ask a responsible reviewer to verify that the evidence supports the claim, record residual exposure and dependencies, and mark the actual closure date. A successfully installed patch is not by itself proof that the original exposure has ended.

What a useful triage record contains

At minimum, capture CVE, asset ID, observed version, source finding, exposure, applicability status, decision, action owner, due date, validation method, evidence location, reviewer, and closure status. The downloadable template adds separate fields for unknowns and exceptions so unresolved work does not disappear into a green status.

Worked example: evidence versus assumption

Three mistakes to avoid

• Using CVSS alone as the queue. A theoretical severity number does not substitute for observed exploitation and local exposure.
• Treating CISA's date as your universal SLA. Distinguish covered federal deadlines from your own organizational policy and contracts.
• Closing from a change ticket alone. Closure requires verifying the originally affected condition, not just confirming a ticket was completed.

Primary references and scope

CISA Known Exploited Vulnerabilities catalog · CISA explanation of BOD 22-01 scope · NIST SP 800-40 Rev. 4.

This worksheet is informational and not a scan, vulnerability assessment, or authorization decision. Never publish internal asset lists or scan exports to a public website.

See recent KEV entries →   Read our scan-to-POA&M evidence guide →