You do not have time to read vulnerability news all day. You also do not want to be the company that gets hit by something the internet already knew was being exploited.

That is exactly what the CISA Known Exploited Vulnerabilities (KEV) Catalog is for: a short, curated list of specific flaws that are confirmed to be exploited in the wild, not theoretical. If you turn it into a routine, patching gets calmer and a lot more effective.

What the KEV Catalog is really telling you

Most vulnerability lists are huge. KEV is intentionally not. CISA maintains it as an authoritative, living list of vulnerabilities that have evidence of active exploitation, and the catalogue includes a “due date” field that federal civilian agencies must follow under Binding Operational Directive (BOD) 22-01.

You are not a federal agency, but the signal is still useful: if a CVE is in KEV, attackers are already using it against real targets. That is why this list is such a good owner-friendly prioritisation tool.

The monthly routine (owner-friendly, ops-friendly)

Pick one day a month and make it a calendar event. For a lot of businesses, the first Tuesday or Wednesday works well because it avoids end-of-month chaos.

Here is the checklist.

  • Pull the current KEV list. Use the official KEV page or the machine-readable JSON/CSV feed so you are always looking at the latest entries.
  • Filter to what you actually run. Cross-check against your asset inventory (firewalls, VPNs, remote access tools, server OS, email, line-of-business apps). If you do not have a reliable inventory, that becomes step zero.
  • Sort by exposure first. Put anything internet-facing at the top of the pile, even if it is not the “highest CVSS”. Attackers cannot exploit what they cannot reach.
  • Decide the patch window. For each relevant KEV item, you are choosing either an emergency change (within days) or a planned change window (still fast, just scheduled).
  • Document the decision. A simple note is enough: what is affected, what you changed, when, and who approved downtime.

If you do this monthly, you stop relying on memory and gut feel. You also stop patching based on whichever headline you happened to see.

Your 7-day SLA for confirmed exploited vulnerabilities

A “patch SLA” is just a promise you make internally about how fast you will act.

For KEV items that apply to your environment, a practical target for a growing business is:

  • 7 calendar days to remediate. That can mean patching, upgrading, or applying the vendor’s required mitigation when a patch is not available.

A few clarifications that keep this sane:

  • Start the clock when you confirm you are affected. Not when you first hear a rumour. The monthly KEV review plus basic monitoring for new KEV additions is how you avoid long delays.
  • Remediate means “risk is removed,” not “we installed something.” If the vendor says the fix is a version upgrade, a config change, or disabling a vulnerable feature, that is still remediation.
  • If you cannot hit 7 days, write down why and set a new date. Sometimes you have a vendor dependency or a critical business deadline. The point is visibility and intent, not perfection.

Prioritise the stuff that sits on the internet

When small businesses get burned by patching gaps, it is often on the edge of the network, where the internet can touch you directly.

Put these in your “drop everything” lane when they show up in KEV:

  • Firewalls and VPN appliances. If your firewall or remote access VPN has a known exploited flaw, treat it like a broken lock on the front door.
  • Remote access services. RDP gateways, remote support tools, VDI portals, and anything that publishes a login page to the internet.
  • Email and identity. Products tied to authentication, single sign-on, and email access are high-value targets because they lead to account takeover.
  • Public-facing apps and portals. Customer portals, booking systems, and any web application exposed to the public.

This is also where “we will patch it later” quietly turns into “we forgot,” because these systems tend to be stable and rarely touched. That is exactly why attackers like them.

Decide who can approve downtime before you need it

Patching breaks down when nobody is allowed to say, “Yes, take it down and fix it.” So decide now, while you are calm.

Use a simple rule:

  • Name the business approver. Usually the owner, COO, or operations lead. This person decides when downtime is acceptable.
  • Name the technical approver. Your IT manager, internal admin, or MSP. This person decides what the safest remediation path is.
  • Define the emergency change threshold. For example: any KEV that affects an internet-facing system can be patched outside normal hours with same-day approval.
  • Pre-approve the communication plan. Who tells staff, who tells customers (if needed), and what the message template looks like.

When those roles are clear, your team can move quickly without arguing in the moment.

A quick template you can copy into your monthly agenda

Keep this as a standing agenda item for your ops meeting.

  • KEV check completed. Date checked, who checked it.
  • Relevant items found. List affected systems and owners.
  • 7-day SLA status. On track, at risk, or missed (and why).
  • Downtime approvals needed. What is being requested, what window.
  • Follow-ups. Vendor tickets, upgrades scheduled, monitoring changes.

This is not about turning you into a vulnerability analyst. It is about making sure “confirmed exploited in the wild” triggers a predictable response in your business.

Want help turning this into a real process?

A KEV routine works best when it is tied to an accurate inventory, clear patch ownership, and a change process that does not create drama. If you would like help setting up a KEV-based patching routine with a 7-day SLA and clear downtime approvals, the Flexnet Networks team can build and run that process with you.

Sources