You already know patching matters. The hard part is the Tuesday morning reality: 47 “critical” alerts, a packed calendar, and one person asking if you can “just do it after hours”.

A good risk based patching process for small business does two things at once. It gets the truly dangerous fixes in fast, and it stops your team from living in emergency mode for every update.

CISA’s Binding Operational Directive 26-04 (BOD 26-04) is written for federal agencies, but the idea translates cleanly to growing companies: prioritise patches using a few risk signals that actually predict trouble, not just a severity score.

Why “patch everything fast” breaks down in the real world

If you try to treat every vulnerability the same way, you end up with one of two outcomes.

  • You patch too slowly. The handful of issues that are actively being exploited sit in the queue behind a mountain of noise.
  • You patch too aggressively. You push changes without enough coordination, break line-of-business apps, and your patching programme loses trust.

BOD 26-04’s core message is practical: you don’t need the fastest response for every vulnerability. You need the fastest response for the vulnerabilities that combine exposure, exploitation, and impact.

The four signals that should drive your priorities

BOD 26-04 uses four decision points to drive response timelines: whether the vulnerability is in CISA’s Known Exploited Vulnerabilities (KEV) catalog, whether the asset is publicly exposed, whether exploitation is automatable, and the likely technical impact if exploited.

Here’s how to translate those into plain-English questions you can ask in a small business.

  • Known exploitation (KEV). Is the vulnerability on CISA’s KEV list, meaning there’s evidence it’s being exploited in the wild? If yes, treat it like a live fire drill, not “next maintenance window”.
  • Internet exposure. Is the affected system reachable from the public internet by unauthenticated or untrusted users (for example, a VPN portal, remote access gateway, public web app, or anything with open inbound ports)? Publicly exposed systems deserve a shorter clock.
  • Easy to automate. Can attackers reliably automate exploitation steps at scale? If yes, the time between “patch released” and “mass scanning starts” tends to be short.
  • How bad is “bad”. If exploited, does the attacker get limited access (partial impact) or full control and broad data access (total impact)? Total impact pushes the item up the list.

One important SMB twist: add asset importance as your business tie-breaker. A vulnerability on a kiosk PC is not the same as a vulnerability on the server that runs your accounting system, even if the CVE looks identical.

Turn that into a managed IT workflow your team can run weekly

This is the part most patching articles skip. You don’t need more alerts. You need a repeatable routine with owners, timeboxes, and a place to record decisions.

A simple workflow looks like this:

  1. Maintain a living asset list. You can’t patch what you can’t see. At minimum, tag endpoints, servers, network gear, and cloud services, then flag which ones are internet-facing and which ones are “business-critical”.
  2. Ingest vulnerability signals. Your patch tool and vulnerability scanner tell you what’s missing. KEV tells you what’s being exploited. Vendor advisories and your security stack fill in the gaps.
  3. Triage in one short meeting. Fifteen minutes, once or twice a week. The goal is to assign a response tier, not to debate CVSS.
  4. Execute through standard change control. Even “emergency” patching should have a ticket, an owner, and a rollback plan.
  5. Verify and close the loop. Confirm the patch applied (or the mitigation is in place), then document what you did and why.

If you’re outsourcing IT, this is also where you set expectations. A provider can’t hit aggressive patch SLAs without clear access, a tested deployment method, and someone on your side who can approve downtime when it’s truly necessary.

A realistic 72-hour, 7-day, and 30-day patch SLA for a growing company

BOD 26-04 includes response timelines as short as 3 days for the highest-risk combinations of signals. For a small business, you can mirror that intent with three simple SLAs that people can remember.

  • 72 hours (emergency track). Use this when all of these are true:
  • the vulnerability is known exploited (KEV),
  • the affected system is internet-facing,
  • and compromise would be high impact (for example, remote code execution, domain-wide access, or access to sensitive data).

Operationally, this means: same-day triage, rapid testing where possible, and a scheduled patch window inside three days. If you can’t patch safely, you put a compensating control in place immediately (for example, disabling the vulnerable service, restricting inbound access, or isolating the system) and then patch as soon as the risk is controlled.

  • 7 days (fast track). Use this for items that are serious but not “drop everything”, such as:
  • KEV items on non-internet-facing systems,
  • or internet-facing issues that are not known exploited but have strong risk signals (for example, widely targeted products, clear exploitability, or high-value assets).

This is the tier that keeps you ahead without breaking the business. In practice, it’s a weekly patch cycle with a short exception process.

  • 30 days (routine track). Use this for the bulk of updates:
  • standard OS and third-party application patches,
  • issues with lower exploitability, lower impact, or low business relevance.

The point of a 30-day tier is not to be lax. It’s to keep patching sustainable, predictable, and testable, so your emergency tier stays truly reserved for emergencies.

What makes risk-based patching work (and what quietly ruins it)

Most patch programmes fail for operational reasons, not because people don’t care.

  • Clear “internet-facing” definitions. Decide what counts, then tag it. If your team argues about exposure every time, your clock is already ticking.
  • A short list of crown-jewel systems. Keep it to 10 to 20 assets or services that would cause real damage if compromised or down. Those get priority when two patches look equally urgent.
  • A default maintenance window. If everyone knows “we patch Wednesdays at 7pm” (or similar), routine work stays routine and emergency work stands out.
  • An exception process that is not a loophole. Sometimes you can’t patch inside the SLA. Fine. But every exception should have: the reason, a temporary mitigation, a new deadline, and an owner.
  • Proof, not vibes. Your provider should be able to show patch compliance by tier, plus evidence that patches actually installed.

A calm next step

If you want a risk based patching process for small business that your team can actually follow, start by tagging internet-facing assets and defining your 72-hour, 7-day, and 30-day patch lanes in writing.

If you would like help setting up a risk-based patch workflow, including patch SLAs, asset tagging, and reporting you can review in a monthly ops meeting, the Flexnet Networks team can build and run it with you.

Sources