Most patching plans fail for a boring reason: they try to treat every vulnerability like it deserves the same attention. Your team gets flooded, the urgent items blend into the noise, and the work turns into a constant game of catch-up.

CISA’s Known Exploited Vulnerabilities (KEV) catalog is a helpful filter. It’s not “every scary-sounding CVE”. It’s a list of vulnerabilities CISA says are being exploited in the real world, which makes it a practical input to your patch priorities.

Start with the why: KEV is about what’s actually being used

CISA maintains the KEV catalog as an authoritative list of vulnerabilities that have been exploited “in the wild”, and they explicitly recommend using it as an input to your vulnerability management prioritisation.

For a small IT team, the value is simple: KEV gives you a short list you can act on without needing a full-time vulnerability analyst.

Two important guardrails:

  • KEV doesn’t replace patching. It helps you decide what gets patched first.
  • Exposure still matters. A KEV on an internal-only system is usually less urgent than a KEV on something exposed to the internet.

Your monthly KEV routine (the checklist)

Here’s a routine you can run once a month, plus a quick “new KEV” mini-routine you run weekly (or whenever you see an alert).

1) Refresh your list of internet-facing systems

If you only do one inventory step, do this one. Internet-facing systems are where patch delays become expensive.

CISA’s exposure reduction guidance is blunt about the goal: you need visibility into publicly exposed systems, and they point to scanning and internet-exposed asset identification tools as a way to get that visibility.

Your practical output should be a simple list you can hand to anyone on your team:

  • Public IPs you own. Include offices, data centres, and cloud.
  • Domains and subdomains. Especially anything used for remote access, portals, and web apps.
  • What’s behind them. Firewall/VPN, remote desktop gateways, email security portals, web servers, line-of-business apps, and any vendor-managed appliances.

A good rule: if a system can be reached from outside your network, it should show up in your inventory with an owner and a patching method.

2) Pull the KEV list in a way you can work with

The KEV web page is useful for humans, but for process you want something you can sort and track.

CISA publishes the KEV catalog as machine-readable feeds (JSON and CSV). That makes it realistic to download the list regularly and compare it to last month’s list to see what’s new.

You don’t need to build tooling on day one. Many teams start with a monthly download saved to a shared folder, then track “new since last run” in their ticketing system.

3) Match KEVs to your environment (inventory meets reality)

This is the step that turns “interesting security news” into actual risk reduction.

For each new KEV entry, ask:

  • Do we run this product anywhere? Include servers, desktops, network devices, and cloud services you manage.
  • Is it internet-facing? Treat anything public as higher priority.
  • Do we have compensating controls? For example, if a service is behind a VPN and MFA, that changes urgency, but it rarely eliminates the need to patch.

If your vulnerability scanner already tags KEVs, great. If not, manual matching is still workable if your asset inventory is clean.

4) Set patch SLAs your team can actually hit

A patch SLA is just a promise with a clock attached. The mistake is making it either unrealistic (so it’s ignored) or vague (so it’s debated).

CISA’s more recent federal guidance on prioritising security updates focuses heavily on two ideas that translate well to small businesses: whether an asset is publicly exposed, and whether a vulnerability is in the KEV catalog.

A simple, workable SLA set for a growing business looks like this:

  • KEV + internet-facing: 72 hours. If it’s exposed and known exploited, you move fast.
  • KEV + internal-only: 7 days. Still urgent, but you have room to schedule a maintenance window.
  • Non-KEV critical updates: 30 days. Keep your baseline patching healthy.

If 72 hours sounds tight, make it easier on yourself by pre-authorising emergency change windows for a short list of systems (firewalls, VPNs, remote access, web servers). That way you’re not negotiating process during the moment you need speed.

5) Patch, but don’t stop there: verify remediation

This is where a lot of teams get burned. “We installed the update” is not the same as “we are no longer vulnerable”.

NIST’s patch management guidance treats patching as a full lifecycle that includes verifying installation, not just deploying updates.

Verification can be simple:

  • Scanner confirmation. Re-scan the asset and confirm the finding is gone.
  • Version confirmation. Check the installed version or firmware level matches the fixed release.
  • Service validation. Make sure the business-facing function still works (VPN login, web app, SSO).

If you can’t patch quickly (legacy systems happen), document a temporary mitigation and put a date on it. “We’ll get to it” is where KEVs linger.

6) Close the loop with a monthly review (30 minutes)

Once a month, review:

  • What KEVs were applicable to us? (And how many were not.)
  • Did we hit our SLAs? If not, what blocked us?
  • Which internet-facing systems are hardest to patch? Those are usually your best upgrade candidates.

This is also where you improve your inventory. Every surprise KEV is a clue that something is missing from your system list.

A quick weekly mini-routine for new KEV additions

Monthly is a good cadence for housekeeping. But KEV additions happen throughout the month, and some come with short remediation timelines in federal contexts.

A lightweight weekly routine:

  • Check for new KEV entries. Pull the latest feed and compare it to last week.
  • Triage in 15 minutes. Is it in your environment? Is it internet-facing?
  • Open tickets immediately. Assign an owner and an SLA clock.

That’s it. The point is to avoid finding out about a “known exploited” issue during your next quarterly patch cycle.

If you want this to run quietly, not heroically

The end goal is boring patching that happens on schedule, with a fast lane for the few items that deserve it.

If you would like help turning the KEV catalog into a repeatable patch routine (including internet-facing inventory, SLAs, and verification), the Flexnet Networks team can build and run that process with you.

Sources