If you run IT for a small business, you have probably opened a vulnerability scan and seen hundreds of findings, many of them marked "critical." Nobody with a part-time IT budget can fix all of them this week. The real question is which ones to fix first, and which can safely wait for the next routine update.

U.S. government guidance gives a fairly clear answer, even though most of it was written for large organizations and federal agencies. This guide turns that guidance into a priority order a small business can actually follow. It also explains in plain English what the scores you will run into, CVSS and EPSS, do and don't tell you.

Why patching is worth the hassle

CISA's guidance for small businesses puts it bluntly: "Many attacks succeed because the victims were running vulnerable software when a newer, safer version was available." It calls keeping systems patched "one of the most cost-effective practices to improve your security posture." It gives three instructions: monitor CISA's Known Exploited Vulnerabilities (KEV) catalog, prioritize the vulnerabilities in it, and turn on automatic updates wherever you can.

The National Institute of Standards and Technology (NIST) makes the same point from a planning angle. Its patch management guide, SP 800-40 Revision 4, describes patching as preventive maintenance, "a cost of doing business." It warns that routine patching "is often postponed and neglected" because updates can interrupt work, and that this "provides many additional windows of opportunity for attackers." Falling behind also makes emergencies harder, because an urgent fix may depend on older patches you skipped.

Step zero: know what you have

You can't prioritize patches for systems you don't know about. NIST says organizations should keep up-to-date software inventories for all their computing assets. It also says the old habit of refreshing that inventory with a monthly or quarterly vulnerability scan "should no longer be used," because systems change too quickly. For a small business, a workable version is a living list of every device and service. Mark which ones can be reached from the internet: the firewall, VPN or remote-access gateway, any server with a public address, the website and its content management system, and any on-premises email or file-sharing server. That last distinction, internet-facing or not, drives most of the priority order below.

The priority order

CISA's newest directive for federal agencies, Binding Operational Directive (BOD) 26-04, issued June 10, 2026, is a useful model even though it does not apply to private companies. It sets patch deadlines based on four questions. Is the system publicly exposed? Is the flaw in the KEV catalog? Can an attacker automate the exploit? And does exploitation give the attacker partial or total control? Applied to a small business, that logic gives an order something like this:

  1. Known exploited flaws on internet-facing systems. This is the top of the list, without exception. Under BOD 26-04, federal agencies get three days for most KEV-listed flaws on publicly exposed systems, and 14 days only in the narrowest case. Of the 137 entries CISA added to the catalog between June 10 and October 20, 2026, 111 carried a three-day due date, according to a ZeroDayFeed count of the KEV JSON feed (catalog version 2026.10.21). Your VPN, firewall, remote-access tools and web applications can be reached by anyone on the internet, and a KEV entry means the flaw has already been exploited in the wild.
  2. Known exploited flaws on internal systems. Next come KEV-listed bugs on workstations and internal servers. The federal table gives these 14 days, or three days plus a check for compromise when the flaw is automatable and gives total control. Attackers who get in by another route will use these to spread.
  3. Serious flaws on internet-facing systems that are not yet in KEV. A new critical bug in an exposed product may be exploited before it ever reaches the catalog. Here EPSS and vendor warnings help you decide how fast to move.
  4. Everything else, on a regular schedule. Most patches fall here. Turn on automatic updates for operating systems, browsers and office software, and set a recurring monthly window for the rest. Monthly vendor releases, such as Microsoft's record October 2026 Patch Tuesday, belong in this routine bucket, except for any exploited flaw they include. That October release had one, and it belongs at the top of the list.

CVSS, explained simply

The Common Vulnerability Scoring System (CVSS), maintained by FIRST, is the 0-to-10 number attached to almost every vulnerability. Its specification maps scores to labels: 0.1 to 3.9 is Low, 4.0 to 6.9 is Medium, 7.0 to 8.9 is High, and 9.0 to 10.0 is Critical.

The catch is that the number you usually see measures severity, not risk. CVSS version 4.0 has separate groups of metrics. The Base metrics describe the flaw itself, the Threat metrics reflect things like whether it is being exploited, and the Environmental metrics capture your own setup. The specification says vendors and the National Vulnerability Database "typically provide only the Base Scores," labeled CVSS-B, and that applying the Threat and Environmental metrics is the user's job. CISA's BOD 26-04 guidance quotes the CVSS user guide: Base scores "are designed to measure the severity of a vulnerability and should not be used alone to assess risk." CISA adds that "critical" or "high" labels "do not prescribe specific actions."

CISA's 2021 FAQ for the earlier directive, BOD 22-01, explains why that matters. It noted that many critical-rated flaws "are highly complex and have never been seen exploited in the wild," and that some of the most damaging attacks chained together flaws rated high, medium or even low. A 9.8 on an internal system nobody can reach may be less urgent than a 7.5 on your VPN that attackers are actively using.

EPSS, explained simply

The Exploit Prediction Scoring System (EPSS), maintained by a special interest group at FIRST, answers a different question: how likely is it that someone will exploit this flaw soon? FIRST describes it as "a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days." Every published CVE gets a score between 0 and 1, updated daily. Scores are free to download, with no registration.

Read the score as a probability. FIRST's example is that among many flaws scored around 0.05, exploitation activity would be expected for about 5 of every 100 within 30 days. Most scores look small because most vulnerabilities never get exploited. FIRST puts the base rate at around 2 to 3%. EPSS also reports a percentile, and FIRST says a probability of 0.10 currently sits around the 95th percentile.

FIRST is careful about what EPSS is not. It is "not a complete risk score": it does not know your environment or measure the damage exploitation would do. There is "no universal threshold." The commonly cited cutoff of 0.10 "carries no special authority." FIRST also says that multiplying EPSS by CVSS "is never a good idea," and that CVSS and EPSS are "empirically uncorrelated." Most important for this guide: if there is direct evidence of exploitation, such as a KEV listing, FIRST says that evidence "should supersede EPSS." EPSS is most useful for sorting the large pile of flaws that are not yet known to be exploited.

Putting the signals together

A simple way to combine them:

  • KEV listing: treat as urgent, whatever the CVSS or EPSS score says. Internet-facing first.
  • Not in KEV, but a high EPSS score on an exposed system: patch ahead of your normal cycle.
  • High CVSS, low EPSS, internal only: usually fine for the next routine window. Watch for it to show up in KEV.
  • Low on all three: routine updates.

For a more formal method, CISA points to Stakeholder-Specific Vulnerability Categorization (SSVC). This decision-tree approach sorts each vulnerability into one of four outcomes: Track, Track*, Attend or Act. CISA recommends fixing Track items "within standard update timelines" and Act items "as soon as possible."

When you cannot patch

Some systems can't be updated: an old device the vendor no longer supports, or a machine that runs something the business cannot take offline. NIST calls these "unpatchable assets" and recommends isolating them or otherwise reducing their risk. It also describes "emergency mitigation," temporary measures such as disabling a vulnerable feature while you wait for a fix. More broadly, its options for handling any vulnerability are to accept the risk, mitigate it, transfer it, or avoid it by removing the vulnerable software. Transferring can include moving to a software-as-a-service product where the provider handles patching.

Old edge devices deserve special mention. CISA's BOD 26-02 describes widespread exploitation campaigns targeting end-of-support edge devices, a category that includes firewalls, routers and other network security appliances. It requires federal agencies to decommission them, replacing them as needed with vendor-supported devices that still receive security updates. A small business running an unsupported firewall should treat it as a replacement project, not a patching problem.

CISA also offers a structural fix. Its small-business guidance urges moving on-premises mail and file servers to secure cloud services, because "few small businesses have the time and expertise to keep them secure." Every server you no longer run is one you no longer have to patch.

What It Means for Defenders

  • Build the list first. Inventory every device and service and mark which ones face the internet.
  • Check KEV weekly, at least. Subscribe to CISA's KEV email alerts and compare new entries against your inventory. Anything matching an internet-facing system goes to the top of the queue, with a target measured in days.
  • Turn on automatic updates for operating systems, browsers and common applications so routine patching happens without anyone remembering to do it.
  • Use scores as tie-breakers, not verdicts. Use EPSS to rank flaws that are not yet known to be exploited, and treat CVSS as a measure of how bad a flaw could be, not how likely it is to be used against you.
  • After an urgent patch on an exposed system, look for signs of compromise. If a flaw was exploited before you patched, the attacker may already be in.
  • Replace what can't be fixed. Retire end-of-support devices, isolate what you must keep, and move services you struggle to maintain to providers who patch for you.

Sources