Patching can feel like trying to drink from a firehose. Every week brings another batch of updates, another “critical” headline, another vendor email that sounds urgent.

The problem is not that you do not care. It is that your business cannot stop work every time a new CVE drops. What you need is a calm way to decide what gets fixed first, and what can wait.

Why CISA’s BOD 26-04 is worth copying (even if you’re not the government)

CISA’s Binding Operational Directive 26-04 is aimed at federal agencies, but the idea translates cleanly to a growing business. Stop treating patching as “highest CVSS first” and start treating it as “highest risk to our business first.”

Risk-based patching is really just two questions:

  1. How likely is this to be used against us soon?
  2. If it is used, how bad is the outcome?

BOD 26-04 pushes agencies to prioritise using signals that map well to real life, especially:

  • Public exposure. Can an attacker reach it from the internet, or is it tucked away behind VPN and access controls?
  • Evidence of exploitation. Is this already being exploited in the wild, or is it still theoretical?
  • Exploit automation. Can it be exploited at scale with tooling, or does it require a rare skill chain?
  • Technical impact. Does exploitation lead to full control, data theft, or something more limited?

You do not need a huge security team to use those signals. You need a repeatable workflow.

The workflow: triage first, then patch

Here is a practical rhythm that works well for a 20 to 300 person environment.

  • Daily (10 to 20 minutes): check for “drop everything” items. This is your fast lane. You are looking for a small number of vulnerabilities that justify interrupting the normal patch cycle.
  • Weekly: normal patch window. This is where most OS and app updates should land.
  • Monthly: catch-up and cleanup. Firmware, “nobody wants to touch it” systems, and anything deferred for testing.

The trick is that daily triage decides whether something jumps the queue.

What to patch in 24 to 72 hours

For most small and mid-sized businesses, you want a clear rule that lets your IT team act quickly without a committee meeting.

Patch (or mitigate) within 24 to 72 hours when you have at least two of these signals:

  • It’s internet-reachable in your environment. Think VPN appliances, firewalls, remote access portals, email gateways, public web apps, and anything with an open port from the outside.
  • It’s on CISA’s Known Exploited Vulnerabilities (KEV) Catalog. That is CISA saying, “This is being exploited in the wild.”
  • The technical impact is “takeover” level. Remote code execution, authentication bypass, privilege escalation to admin, or anything that gives an attacker broad control.
  • Exploit likelihood is high and rising. EPSS is useful here because it is recalculated frequently and aims to estimate near-term exploitation probability.

A concrete example: if a VPN appliance vulnerability is added to KEV and your VPN is exposed to the internet, that is a 24 to 72 hour item. In practice that might mean patching the appliance, but it can also mean an immediate mitigation while you schedule the patch (for example, temporarily disabling a vulnerable feature, restricting access by IP, or putting the service behind stronger access controls).

One practical note: “patch” is the goal, but risk reduction is the job. If you can make the vulnerability not internet-reachable today, you have bought time to patch safely.

What can usually wait for the next patch window

A lot of vulnerabilities are real, but not urgent for your business this week. These are often good candidates for your normal weekly cycle, assuming you are not seeing active attack signs.

  • Not internet-exposed, and not in KEV. For example, a client-side app update on standard office PCs, where exploitation would require a user to do something unusual.
  • Low business impact systems. A lab machine, a kiosk, or a non-sensitive internal tool, as long as it is segmented and not a stepping stone to critical data.
  • Updates with meaningful break risk. Line-of-business apps, legacy components, or anything that historically causes outages when patched. You still patch, you just plan it.

Waiting does not mean ignoring. It means you are documenting the decision, setting a deadline, and keeping an eye on whether the risk picture changes.

The signals that matter most (and the ones that waste your time)

If you only improve one part of your patching process, improve your inputs. The right signals reduce noise.

  • KEV status. If it is in KEV, assume attackers are already using it, because that is the point of the list.
  • Your exposure, not “global exposure.” A vulnerability in a product you do not run is irrelevant. A vulnerability in a product you run, but only internally, is a different problem than one reachable from the internet.
  • Asset criticality. A patch on the CFO’s laptop is not the same as a patch on a server that holds customer data, or an identity system that controls access to everything.
  • EPSS as a tie-breaker, not a dictator. EPSS is helpful for prioritising among the huge middle group of vulnerabilities, especially when you are deciding what to include in the next sprint.

Signals that often waste time when used alone:

  • CVSS severity by itself. Severity is not the same as likelihood, and it does not know your environment.
  • Vendor email urgency. Vendors understandably want you to patch their product quickly. Your job is to patch what reduces your risk fastest.

How to run this with a small IT team (without burning out)

Risk-based patching only works if it is doable. A simple division of labour helps.

  • Name an owner. One person is responsible for the daily triage call. That does not mean they patch everything, it means they keep the queue honest.
  • Keep a short “internet-facing” inventory. You do not need a perfect CMDB to start. You need a list of what is exposed: VPN, firewall, remote management tools, email security, public web apps, and cloud admin portals.
  • Write your SLAs down. For example:
  • 24 to 72 hours: KEV plus internet-reachable, or takeover-level impact on a critical system.
  • 7 days: high-likelihood items on important internal systems.
  • 30 days: everything else that is reasonable to patch.
  • Build in verification. After patching, confirm the version, confirm the vulnerability is closed in your scanner, and confirm the service still works.

This is also where a managed IT partner earns their keep. The value is not just “we apply updates.” The value is consistent triage, good documentation, and fewer surprises.

A simple way to start this week

If your patching process is currently “we do Windows Updates and hope for the best,” do this first:

  • Pick your fast lane criteria. Decide what qualifies for 24 to 72 hour action.
  • Subscribe to KEV updates. Make sure someone actually sees them.
  • List your internet-facing systems. If you have to guess, that is your first visibility gap to fix.
  • Run one tabletop. Ask: “A KEV drops for our VPN. Who decides, who patches, who tests, who tells staff if there is downtime?”

If you would like help turning risk-based patching into a simple, auditable workflow (with clear 72-hour, 7-day, and 30-day targets), the Flexnet Networks team can build and run that with you.

Sources