How to prioritise software patches

When several software updates need attention, first check which affected products and versions you use and whether attackers can reach them. Give priority to vulnerabilities attackers are known to be exploiting and to patches required by urgent security directives. For other patches, compare the chance of an attack with the harm it could cause in your environment.

Scores help organize patching, but no single score sets the priority. A vulnerability in an internet-facing system that holds sensitive data may need faster attention than a higher-scoring flaw on an isolated, low-impact device.

Confirm which systems are exposed

Before ranking a vulnerability, check whether you use the affected product and version. Count the instances, then determine whether an attacker can reach the vulnerable feature. Look for answers in asset records and software inventories. Check vulnerability scans and network diagrams too. Compare scan findings with current asset information: outdated inventories can waste effort on systems you no longer run or cause you to miss systems you still use.

Exposure and importance both matter. Pay closer attention to an internet-facing server, a system that stores sensitive data, or software that supports a critical service than to an isolated device with limited access. Also consider whether an attacker could read or change data, interrupt a service, or reach other systems.

FIRST, which maintains the Common Vulnerability Scoring System (CVSS), recommends adding asset details to vulnerability findings. CVSS scores describe a vulnerability’s technical severity. They do not account on their own for your network, safeguards, or the consequences of an incident.

Prioritize actively exploited vulnerabilities

Evidence that attackers are exploiting a vulnerability should raise its priority. CISA’s Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities attackers have used in real attacks. If you use an affected product and attackers can reach it, treat a KEV listing as urgent even if another measure estimates a low chance of future exploitation.

If attackers have exploited the vulnerability in your environment, involve your incident-response process as well as patching. Installing an update alone does not confirm that the attacker is gone or that affected accounts and systems are safe.

Urgent vendor instructions or government directives also affect the queue. Check whether a direction applies to your organization and the specific product you operate. Federal remediation requirements, for example, do not automatically set deadlines for private organizations.

Read CVSS and EPSS separately

CVSS helps describe how severe a vulnerability is from a technical perspective. A high score signals greater technical severity, but it does not tell you how exposed your systems are or what an attacker could do in your environment. A lower-scoring flaw can still deserve fast action when it affects a widely exposed or business-critical system.

The Exploit Prediction Scoring System (EPSS), maintained by FIRST, estimates the chance that someone will observe an attempt to exploit a publicly disclosed vulnerability in the next 30 days. It updates daily and can help compare vulnerabilities when there is no confirmed exploitation evidence. EPSS does not know your asset inventory, safeguards, or the harm a successful attack would cause.

For example, an EPSS score of 0.05 represents an estimated 5% probability of observed exploitation in the next 30 days. It does not mean a 5% chance of damage to your organization, and it does not show that the vulnerability is harmless.

Use KEV and EPSS for different purposes. KEV records known exploitation; EPSS forecasts the chance of observed exploitation. A low EPSS score does not cancel out a KEV listing. CVSS and EPSS also use different scales, so multiplying them does not produce a meaningful risk score.

Assess the impact of a successful attack

Once you know whether a vulnerability is present and reachable, assess what a successful attack could cost. Consider whether the affected system handles sensitive information, supports a critical service, or provides a path to other systems. Then count the affected instances. Assess how effective safeguards are, including network restrictions and disabled features.

The same flaw may warrant different patch priorities depending on where it appears. A vulnerability on one tightly restricted internal server may rank below the same flaw across many internet-facing systems. Conversely, an internal system can still be a high priority if it holds sensitive data or supports an essential service.

Record why a patch moved up or down the queue, including exploitation evidence, exposure, asset importance, and any safeguards. That makes it easier to revisit the decision when threat information or system context changes.

Plan a safe patch deployment

Patch availability and deployment risk affect how you act, but they do not make the vulnerability disappear. NIST’s enterprise patch-management guidance covers the full patching cycle: identify and prioritize updates, obtain and install them, and check that they worked. It also recognizes practical constraints such as testing, dependencies, outage windows, end-of-life software, and patches that are not yet available.

For an urgent vulnerability, test and roll out the patch in ways that match the risk. A staged deployment can reveal problems before an update reaches every affected system. Prepare a plan to undo the update if a failed installation could interrupt an important service. The amount of testing should reflect both the threat of delay and the consequences of a faulty deployment.

If you cannot patch promptly, reduce exposure while you work toward a fix. Depending on the product and vendor guidance, that could mean disabling the vulnerable feature, isolating the affected system, or removing the software. Record the mitigation and name the person responsible for revisiting it. Note the conditions that will trigger another review. Temporary mitigation needs follow-up because it does not remove the underlying flaw.

Set targets and verify fixes

Use remediation targets that reflect your organization’s risk tolerance, operational needs, and any rules that apply to you. General guidance does not establish one deadline that fits every vulnerability and every organization. A confirmed exploit on a reachable critical system warrants faster action than a flaw on a low-impact asset with strong restrictions, but each decision still needs an owner and a clear next step.

After deployment, confirm that the intended systems received the update and that the vulnerability is no longer present. Recheck scan findings or version records, and investigate failed or incomplete installations. If you used a workaround instead, verify that it remains in place and has not made the service unusable.