A CISA advisory or a new Known Exploited Vulnerabilities (KEV) Catalog addition is only useful if a team acts on it before an adversary already exploiting it in the wild reaches their environment. This is a concrete, step-by-step response process, built around the reality that most security teams don’t have a dedicated intel analyst to run it manually every time a new advisory lands.
Step 1: Check the affected-products list first
Before reading anything else, check the specific products, versions, or configurations the advisory names. This is the fastest way to determine whether an advisory applies to your environment at all — most advisories don’t, for most organizations, and confirming that in minutes rather than after a full read is what makes this process sustainable for a small team. If nothing matches, log the advisory as reviewed and move on.
Step 2: Check whether the CVE is on the KEV catalog
If a CVE is referenced, check whether it’s also listed on CISA’s KEV Catalog specifically, not just whether it has a high CVSS score. A high CVSS score describes theoretical severity; a KEV listing is a factual confirmation of active exploitation, and the two should drive different response speeds. Our vulnerability research traces exploitation status back to both NVD and KEV directly, and you can verify a reported severity score yourself with our CVSS calculator rather than trusting it at face value.
Step 3: Determine your remediation timeline
If your organization is a federal civilian executive branch agency, Binding Operational Directive 26-04 sets a mandatory remediation timeline that starts the moment a vulnerability is added to KEV. Most organizations aren’t bound by BOD 26-04, but adopting its underlying logic — patch on a fixed, short timeline once a vulnerability is confirmed exploited, not whenever it fits the normal patch cycle — is a reasonable default even without the regulatory requirement, since the exploitation evidence itself doesn’t depend on who’s bound by the directive.
Step 4: Patch, or remove the exposure
CISA’s own guidance describes two valid remediation paths: apply the vendor’s patch, or, if a patch isn’t available or immediately feasible, remove the vulnerable product from the network entirely until it is. A compensating control — a firewall rule, a WAF signature — can reduce risk in the interim, but shouldn’t be treated as a substitute for one of the two real remediation paths if a patch does become available.
Step 5: Map the advisory’s TTPs to your own detection coverage
If the advisory includes MITRE ATT&CK technique IDs — most Cybersecurity Advisories do — check them against your own detection rules, not just the patch status of the named CVE. A vulnerability can be patched while the broader technique an adversary used to exploit similar flaws remains an open detection gap. Our ATT&CK technique lookup resolves any technique ID against MITRE’s own dataset directly in the browser, which is a faster check than re-reading the advisory’s narrative section each time.
Step 6: Search for indicators of compromise, if the advisory includes them
For advisories with a published IOC list, run a retrospective search across available logs for any sign the indicators already appeared in your environment before the advisory was published — not just going forward. This is the step most likely to get skipped under time pressure, but it’s the only one that answers “were we already hit” rather than “are we protected going forward.”
Step 7: Log what you checked, even when nothing applied
For every advisory reviewed — including the ones where nothing matched your environment — keep a short record of what was checked and when. This isn’t bureaucratic overhead; it’s what lets you answer, weeks later, whether a specific advisory was actually reviewed or simply missed, without having to reconstruct the answer from memory.
A minimal response checklist
- Affected products checked against your actual environment
- CVE cross-checked against the KEV catalog, not just CVSS score
- Remediation timeline set based on KEV status, not the normal patch cycle
- Patched or removed from the network — not just mitigated with a compensating control alone
- ATT&CK technique IDs checked against your detection coverage
- IOCs searched retrospectively across available logs
- Review logged, even for advisories that didn’t apply
For background on what a CISA advisory actually is, see our complete explainer, and for how advisories are structured and issued, see our guide for security teams.
Frequently Asked Questions
How fast should a small team respond to a new CISA KEV catalog addition? As fast as your patching process allows once you’ve confirmed the CVE applies to your environment — treat a KEV addition as confirmed active exploitation, not a routine patch-cycle item, since that’s the factual difference a KEV listing represents.
What should I do if a CISA advisory doesn’t include a patch, only mitigations? Apply the mitigations as an interim measure and continue monitoring for a vendor patch — CISA’s own guidance frames removing the vulnerable product from the network as the alternative to patching when no fix exists yet, not a permanent substitute for one.
Is it worth reviewing a CISA advisory if none of the affected products match my environment? A quick affected-products check is still worth the few minutes it takes, since it’s what confirms the advisory doesn’t apply — logging that confirmation is cheap insurance against having to re-verify it later from memory.
Grounded in CISA’s published cybersecurity advisories, the CISA Known Exploited Vulnerabilities (KEV) Catalog, and the National Vulnerability Database (NVD). See more vulnerability research.