CISA KEV Response Guidance

Turn known exploitation into owned response without skipping validation.

Use this guide when a CISA KEV entry needs to become a patch deadline, mitigation plan, SOC check, exception, leadership update, or closure decision.

Start responseKEV QueueResponsible KEV

Response rule: KEV means exploitation has been observed in the wild, but it does not prove your environment is affected, exposed, unpatched, compromised, or late. Treat it as a strong response trigger, then require local product, version, exposure, owner, and closure evidence.

Intakeidentify scope

CVE, vendor, product, known-exploited status, required action date, and affected business owners.

Validateprove local fit

Installed version, feature state, exposure path, asset role, backport status, and owner confirmation.

Respondchoose lane

Patch, mitigate, isolate, monitor, vendor case, exception, not affected, or SOC review.

Closeattach evidence

Version proof, control proof, scan retest, owner signoff, SOC note, and review trigger.

Response Path

Move KEV entries through a response lane, not a panic lane.

1Open KEV itemCapture CVE, source date, vendor, product, known-exploited context, and references. 2Validate fitConfirm affected version, package, platform, feature, deployment mode, and backport status. 3Pick lanePatch, mitigate, monitor, isolate, escalate, exception, or not-affected closure. 4Prove closureAttach change proof, control proof, retest result, owner signoff, and review trigger.

Response Lanes

Choose the safest lane for the local evidence.

Patch now

Use when affected scope is confirmed, a safe fixed version exists, exposure or asset role is meaningful, and change risk is acceptable.

Evidence: installed version, fixed target, change window, rollback plan, post-change proof.

Mitigate first

Use when patching is delayed, risky, or incomplete but a temporary control can reduce reachability, feature exposure, or exploit path.

Evidence: control config, test result, owner, expiry date, monitoring plan.

SOC check

Use when exposure is plausible, exploitation is relevant to the environment, logs exist, or leadership needs assurance before closure.

Evidence: log sources, query scope, timeframe, findings, caveats.

Vendor clarification

Use when affected versions, fixed versions, cloud responsibility, support status, or workaround limits are unclear.

Evidence: vendor case, exact question, response, date, next review trigger.

Exception

Use when affected risk remains after deadline because patching is blocked, unsafe, unavailable, or requires longer coordination.

Evidence: business reason, temporary controls, approver, expiration, renewal trigger.

Not affected

Use when product, version, platform, feature, package, deployment mode, or backport evidence disproves applicability.

Evidence: product mismatch, version proof, feature proof, backport note, owner signoff.

What To Ask

Owner questions that keep KEV work concrete.

Asset owner

Do we run the affected product, version, platform, component, or feature? Where is it deployed, who owns it, and what evidence proves affected or not affected?

Patch owner

What fixed version or mitigation is available, when can it be applied, what could break, and what proof will show the vulnerable state is gone?

SOC owner

Can we review relevant telemetry for the affected exposure path and timeframe? What can the available logs prove, and what remains unknown?

Risk owner

If the deadline cannot be met, what temporary controls, approvals, expiration date, and review triggers make the exception defensible?

Safe Language

Say exactly what KEV proves and what it does not.

Say

This CVE is in CISA KEV, so we are treating it as a high-priority validation and response item.

Do not say: We have been exploited.

Say

Local affected status is confirmed for these assets and unknown for these owners.

Do not say: All matching products are vulnerable.

Say

Remediation is complete for assets with attached version proof and retest evidence.

Do not say: The KEV item is closed everywhere.

Copy Template

CISA KEV response note

CISA KEV response note - [CVE]
Known exploited signal: [KEV entry/source/reference/date]
Local scope: [affected assets/products/owners or unknown scope]
Validation evidence: [installed version, feature state, exposure, backport, owner confirmation]
Response lane: [patch / mitigate / isolate / SOC check / vendor case / exception / not affected]
Action owner and timeline: [team/person/date/dependency]
SOC review: [needed / in progress / not needed] because [reason]
Closure evidence required: [version proof, control proof, retest, owner signoff, exception approval]
Safe caveat: KEV proves known exploitation somewhere; it does not by itself prove local compromise.
Review trigger: [new vendor guidance, failed change, scanner retest, exposure change, exception expiry]