Vulnerability scans routinely return thousands of findings, while the team that has to fix them is a handful of people. NIST reports that CVE submissions grew 263% between 2020 and 2025[1], so the pile will only get bigger. "Fix everything" is not a realistic goal. The realistic goal is to make sure the vulnerabilities most likely to be attacked and most damaging if exploited are dealt with before attackers get to them, and that everything else is handled on a plan with deadlines.

This article lays out a process you can adopt directly: start with an asset inventory, look at exposure first, rank with KEV, EPSS and CVSS together, set tiers and deadlines, use compensating controls when you cannot patch, and verify that fixes actually took effect. For what each score means, read Reading vulnerability IDs and scores: CVE, CVSS, EPSS and KEV first.

Step 1: Asset inventory, because no list means no priorities

If you do not know what you have, you cannot tell which vulnerabilities matter to you. NIST SP 800-40 Rev. 4 recommends continuously maintaining software inventories for physical and virtual assets, including OT, IoT and containers. A fully comprehensive inventory may be impossible, but automation that constantly discovers new assets can keep it close to complete. NIST also says plainly that the old model of refreshing the inventory monthly or quarterly with a vulnerability scan should no longer be used[2].

NIST recommends thinking about patching per asset, tracking each asset's technical and business characteristics alongside its software and versions[2]. In practice, the inventory should at least record:

  • the asset owner and purpose, meaning which business process it supports;
  • whether it can be reached from the internet;
  • operating system, firmware and key software versions, and the vendor's end-of-support date;
  • the sensitivity of the data it holds, such as personal data, trade secrets or financial data;
  • maintenance windows when it can go down, and any contractual or regulatory limits on patching.

NIST further suggests grouping assets with similar characteristics into maintenance groups, each with its own approach and schedule for routine patching, emergency patching and emergency mitigation. Assets that cannot or should not be patched still need a maintenance group of their own, rather than being labeled an "exception" and forgotten[2].

Step 2: Look at exposure first

The same vulnerability is far more urgent on an internet-facing VPN than on an internal test server. CISA's Binding Operational Directive BOD 26-04, issued in June 2026, sets remediation deadlines from four variables: whether the asset is publicly exposed, whether the vulnerability is on the KEV catalog, whether an adversary can automate every step of exploitation, and whether exploitation gives partial or total control of the asset[3]. "Publicly exposed" means accessible to unauthenticated or untrusted entities over public networks[3].

The directive replaced BOD 22-01 from 2021, which used fixed deadlines: two weeks for KEV vulnerabilities with CVE IDs assigned from 2021 onward, and six months for older ones[4]. Moving to tiers based on exposure and impact amounts to the regulator acknowledging that one deadline for every vulnerability no longer works. BOD 26-04 only binds US federal civilian agencies, but its four variables make a good skeleton for a company's own tiers.

Step 3: Rank with KEV, EPSS and CVSS together

Once you know whether you have the affected asset and whether attackers can reach it, rank with three external signals:

  • KEV first. CISA strongly recommends that all organizations include a requirement to immediately address KEV vulnerabilities in their vulnerability management plans[5]. FIRST likewise advises treating anything on KEV as actively exploited and prioritizing it regardless of its EPSS score[6].
  • EPSS for prediction. EPSS estimates the probability of exploitation within the next 30 days. FIRST notes that if you used to filter on CVSS "Critical", roughly the 90th EPSS percentile (a probability of 0.04 or more) selects a similar number of vulnerabilities, and that the equivalent of CVSS "High" and above is a threshold of about 0.008. These are starting points for the transition; set your actual thresholds based on how much your team can remediate[6].
  • CVSS for impact. CVSS Base scores measure severity and should not be used alone to assess risk. Supplement them with environmental and threat information, such as how important the asset is and what protections are already in place[7].

If you want a ready-made decision framework, look at SSVC (Stakeholder-Specific Vulnerability Categorization), developed by CISA and Carnegie Mellon University's Software Engineering Institute (SEI). CISA's decision tree weighs five factors: exploitation status, technical impact, automatability, mission prevalence and public well-being impact. It produces four outcomes: Track (remediate within standard timelines and keep monitoring), Track* (standard timelines, but watch more closely for changes), Attend (supervisory attention and remediation sooner than standard timelines) and Act (supervisors and leadership respond together and remediate as soon as possible)[8].

Step 4: Set tiers and deadlines

Attackers keep getting faster. Mandiant's M-Trends 2026 estimates that the mean time to exploit has fallen to minus seven days, meaning exploitation routinely begins before a patch is even released[9]. Under BOD 26-04, the most urgent tier must be remediated or mitigated within three days, together with a forensic triage of the affected asset; the lowest tier can wait until the asset's next scheduled major upgrade or rebuild[3]. The directive also states that timelines change as facts change: taking a system off the internet, for instance, flips "publicly exposed" from yes to no and shifts the required deadline accordingly[3].

Here is an example tier scheme to adapt to your organization (it is not a regulatory requirement):

  1. P1 Emergency: KEV vulnerabilities on internet-facing systems, or anything the vendor reports as actively exploited. Patch or mitigate within 3 days and check for compromise at the same time.
  2. P2 High: KEV vulnerabilities on internal systems, or vulnerabilities on internet-facing systems that are automatable, have elevated EPSS, or are rated CVSS Critical. Within 14 days.
  3. P3 Medium: Vulnerabilities on internal systems with elevated EPSS or a CVSS High rating. Within 30 days.
  4. P4 Low: Everything else. Include in the monthly patch cycle or the next system upgrade.

Have management approve the tiers and deadlines, write them into policy, and keep an emergency change process ready. Some Taiwanese organizations also face legal requirements. Under the Regulations Governing the Classification of Cyber Security Responsibility Levels, last amended in January 2026, Level A specific non-government agencies must remediate or mitigate cyber security vulnerabilities in a timely manner once they become aware of them; critical infrastructure providers must also implement vulnerability management as specified by the competent authority, and all core information systems must undergo vulnerability scanning twice a year[10]. For who is covered and what else applies, see Taiwan's Cyber Security Management Act: who must comply and what they must do.

Step 5: Compensating controls when you cannot patch yet

Not every vulnerability can be fixed right away: the vendor has no patch yet, the update would disrupt a critical business process, or the device is out of support. NIST describes four risk responses: accept (rely on existing controls, or judge the impact low enough), mitigate (patch, disable the vulnerable feature, or use firewalls and network segmentation to shrink the attack surface), transfer (for example cyber insurance, or moving to SaaS where the provider handles patching) and avoid (uninstall the vulnerable software or decommission the asset)[2].

Common compensating controls include:

  • Restrict access: turn off internet-facing services you do not need, and allow management interfaces only from specific sources.
  • Segment: move systems that cannot be patched into a separate network segment and allow only the connections they need.
  • Disable the affected feature, or apply the vendor's temporary mitigation settings.
  • Increase monitoring: create alerts for known attack patterns against the vulnerability and retain the relevant logs.

Every deferred patch needs a written record: the reason, the compensating controls in place, an owner, an expiry date and a review date. An exception with no expiry date eventually becomes a permanent vulnerability.

Step 6: Verify the fix and keep tracking

"Update deployed" is not the same as "vulnerability fixed". NIST treats verification as part of the patching process: confirm that the patch was installed successfully and has taken effect, which at scale requires automation. After that, keep monitoring to make sure the patch has not been removed by a user or an attacker, that an unpatched version has not been restored from backup, and that the device has not been reset to a vulnerable factory default[2]. The baseline controls in Taiwan's regulations likewise require that vulnerability patches be tested for effectiveness and potential impact, and applied periodically[10].

In practice:

  • Rescan after patching, or check the version directly. Pay extra attention to patches that only take effect after a reboot or an additional configuration change.
  • After fixing a P1 vulnerability, look for signs that the system was already compromised.
  • Report a few metrics to management every month: the share of each tier fixed within its deadline, the number of open KEV vulnerabilities on internet-facing systems, the number of overdue items and exceptions, and inventory coverage.

Action checklist

  • This week, inventory every system and device exposed to the internet and confirm its owner and version.
  • Link the asset inventory to your scan results and tag every finding with four fields: internet-facing, on KEV, EPSS and CVSS.
  • Compare new KEV entries with your inventory every day; anything that hits an internet-facing system goes straight to P1.
  • Agree tiers and deadlines with management, write them into policy, and set up an emergency change process.
  • Create maintenance groups and compensating controls for assets that cannot be patched, and give every exception an expiry date.
  • Rescan to verify fixes, and review overdue items and metrics every month.
  • Subscribe and follow vulnerability advisories to catch issues that need urgent action. For the difference between zero-days and n-days, see Zero-day and n-day vulnerabilities.