A Vulnerability Management Program That Works

A vulnerability management program is the routine an organization follows to find weaknesses in its software and devices, pick the ones to deal with first, fix them, and check that the fix held. A vulnerability is a weakness an attacker can use, and a patch is the update a vendor releases to close it. NIST observes that many organizations cannot keep up with patching, so it ends up mostly reactive, and it says that keeping up is not possible without automation. This article describes a program you can start now, based on NIST SP 800-40 Rev. 4, CIS Controls and CISA guidance.

What a program covers, and how it differs from patching

Patching is only one way to respond to a vulnerability. NIST SP 800-40 Rev. 4 lists four risk responses, and a program should choose among them on purpose:

• Accept: do nothing more, because existing controls already block exploitation or the impact is low enough
• Mitigate: remove the weakness by patching, or add other controls, such as isolating the vulnerable system from the main network
• Transfer: share the consequences with someone else, such as buying cyber insurance or moving to a SaaS (cloud-delivered software) service where the provider does the patching
• Avoid: remove what the attacker can reach, such as uninstalling the software or retiring the machine

By default, an organization accepts the risk of the software it runs, and the risk usually rises once a vulnerability becomes public, because attackers are more likely to build exploits for it. Patching or upgrading is the only response that removes a vulnerability completely without removing a feature, but it cannot always be done at once. For example, the patch may not exist yet, the software may be out of vendor support, or the system may have to wait for a scheduled outage window.

The cycle in six steps

NIST describes the vulnerability life cycle in three parts: know which vulnerabilities affect your assets, plan the response, and carry it out, which breaks down into prepare, implement, verify and keep monitoring. An asset here means the devices, software and systems the organization uses. This article splits the cycle into six steps that are easier to put into practice:

• 1. Inventory: know what the organization has, which software versions run on it, and who looks after it
• 2. Find: scan systems regularly and follow vendor advisories
• 3. Rank: decide what must be fixed first
• 4. Respond: patch, or use another response, following plans prepared in advance
• 5. Verify: confirm that the patch is installed and has taken effect
• 6. Measure and report: see whether fixes met their deadlines, then improve the program

Verification should not be skipped, and it should not be a one-time check. NIST explains why monitoring must continue: a patch can be uninstalled, an old version can return from a backup restore, or a device can be reset to a vulnerable factory default.

Step 1: Know what you run (the asset inventory)

An inventory is the list of the assets in use and the software on them. NIST recommends keeping it up to date at all times, covering physical and virtual machines, including OT (operational technology), IoT (internet-connected devices) and containers (self-contained packages of software that run in isolation). A realistic goal is a nearly complete inventory kept current through automated discovery of new assets. Updating the inventory monthly or quarterly with a scan used to be considered acceptable, but NIST says that model should no longer be used.

Decisions improve when the inventory describes each asset, not just the software and its version. NIST suggests recording both technical and business details. Examples include:

• Platform type: general IT, OT, IoT, mobile, or cloud
• Who administers it: the IT department, a third party, or the device vendor
• Controls already in place: for example a firewall, or protection software installed on that machine
• Importance to the organization: how much the business loses if this asset is compromised
• Legal and contractual limits: for example a law or policy that sets how soon a fix is due, or a machine that can only be rebooted during a monthly outage window

Step 2: Find vulnerabilities

Scanning is the use of an automated tool to check assets for known vulnerabilities. NIST says that if scan results are also used for the software inventory, the scans must be authenticated (the tool logs in to each machine with a privileged account) so that they can detect changes to the software on it.

Scanning is not the only source. NIST also mentions advisories from software vendors, security researchers and the NVD (National Vulnerability Database, the US government database of publicly disclosed vulnerabilities). A publicly known vulnerability usually has a CVE ID (a unique public identifier), so that everyone refers to it the same way.

CIS Control 7 (Continuous Vulnerability Management) sets minimum rhythms for this work. According to the CIS Controls v8 assessment specification, the frequencies below are minimums, and doing it more often is fine:

• Scan internal assets (7.5): automated, at least quarterly
• Scan externally exposed assets (7.6): at least monthly
• Patch operating systems and applications (7.3 and 7.4): automated, at least monthly
• Remediate the vulnerabilities found (7.7): at least monthly, following the defined remediation process

Step 3: Decide what to fix first

A scan can return a large number of findings, and no team can fix them all at once. NIST says assessing every new vulnerability one by one is not feasible, so the rules should be set in advance and a decision can then be made quickly. The program therefore needs a rule that turns a list of findings into an order of work. Factors that are commonly combined are:

• Severity: how bad a successful attack would be on technical grounds, shown by the CVSS score (Common Vulnerability Scoring System)
• Likelihood of attack: the probability of exploitation in the next 30 days, shown by the EPSS score (Exploit Prediction Scoring System)
• Confirmed exploitation: whether the vulnerability is in CISA's KEV (Known Exploited Vulnerabilities) catalog
• Exposure: whether the machine can be reached from the internet
• Asset importance: how much the business depends on that machine

These factors measure different things, and none of them is a risk score on its own. The companion article CVSS vs EPSS vs KEV: Prioritizing Vulnerability Fixes explains each one. A real example of such a rule is CISA's BOD 26-04 (a BOD, or Binding Operational Directive, is a compulsory direction to US federal agencies, issued in June 2026). It looks at four factors: public exposure, KEV status, whether exploitation can be automated, and technical impact. It does not bind other organizations, but FIRST (the global Forum of Incident Response and Security Teams) says others can use or adapt it as a model.

Step 4: Respond with plans prepared in advance

NIST recommends placing each asset in a maintenance group: a set of assets with similar traits that share the same software maintenance needs, such as patch schedule, testing needs, outage limits, and the impact if the asset is compromised. Assets that cannot be patched should not be labeled as exceptions and left alone. They get a group of their own, because they still need maintenance.

For each group, define a plan in advance for four scenarios:

• Routine patching: for patches on a regular release cycle that have not been raised to emergency status
• Emergency patching: for a severe or already exploited vulnerability, done as fast as possible
• Emergency mitigation: for when there is no patch yet or the patch has a problem, such as turning off the vulnerable feature or isolating the machine, with a set date to remove the measure once the patch is ready
• Unpatchable assets: long-term isolation or other methods, reviewed periodically to see whether they still work

For routine patching, NIST suggests patching a small group of assets first, called canaries (pilot machines), to see whether the patch causes problems, and then widening the rollout. It also suggests giving users a grace period to install on their own before installation is forced. NIST warns that putting routine patching off makes emergency patching harder, because the earlier patches that a new patch depends on must be installed first.

How fast to fix is each organization's own decision, based on its risk, its laws and its contracts. Outside examples are guidance only. BOD 26-04 sets deadlines for US federal agencies according to the factors above, and CISA's implementation guidance gives one example: a KEV vulnerability on a publicly exposed asset, with total technical impact (the attacker gains total control of the software or total access to its data) and automatable exploitation, gets a 3-day deadline. The earlier directive, BOD 22-01, which gave two weeks for newly added KEV entries, was revoked on 10 June 2026. Documents written before that, such as NIST SP 800-40 Rev. 4 (April 2022), still refer to BOD 22-01, so check a document's date before reusing an old number.

Systems that cannot be patched are usually protected by isolating them from the rest of the network; see Network Segmentation and Micro-segmentation: Start Safely. For plants and OT systems, see Zero Trust for OT: Adapting It Without Disrupting the Plant. For the details of getting patches installed on time, see Patch Management Best Practice: Fast, Without Outages.

Steps 5 and 6: Verify and measure

A simple number such as the percentage of vulnerabilities patched does not help decisions. NIST gives an example: being told that 10% of assets are unpatched says nothing about risk, because those assets could be the most important ones or the least important ones. NIST therefore recommends splitting the numbers by asset importance and vulnerability importance, and tracking the percentage fixed by the deadline, the average time to fix, and the median time (the middle value: half of the fixes are faster, half are slower). NIST's table is a notional example, and its numbers only show the format.

Different readers need different views, for example executives and system administrators. Metrics worth tracking are:

• Share fixed by the deadline: split by priority level
• Time to fix: both the average and the median, split by priority level
• Open exceptions: how many, how long they have been open, and who approved them
• Scan coverage: the share of inventoried assets scanned in the latest cycle

CIS also asks that the documented vulnerability management process (7.1) be reviewed at least annually or after significant changes in the organization, and that the risk-based remediation process (7.2) be reviewed monthly or more often.

Common mistakes

• Treating the scan report as the program: scanning only finds problems; without owners, deadlines and verification, nothing gets fixed
• Ranking by CVSS score alone: FIRST says Base scores are not risk and should not be used alone to prioritize patching
• Scanning only the assets that are on the list: machines nobody knows about are never scanned or patched
• Calling hard-to-patch systems exceptions and forgetting them: NIST recommends giving these systems their own maintenance group and plan
• Reporting only the percentage patched: a figure like that does not show where the risk is
• Borrowing another body's deadlines without checking the source: for example, the two-week deadline of BOD 22-01 was replaced by BOD 26-04 on 10 June 2026

Start today

• Start the inventory with internet-facing systems and OT systems: name an owner for each machine
• Compare the KEV catalog with your own inventory: CISA publishes it as a CSV (plain-text table) and JSON download; fix the matches first
• Write a one-page ranking rule: which factors are used and who decides
• Write plans for all four scenarios, starting with the most important asset group: routine patching, emergency patching, emergency mitigation and unpatchable assets
• Set deadlines by priority level: base them on your own risk, laws and contracts
• Start measuring two numbers: the share fixed by the deadline and the median time to fix, split by priority level

To see where your organization's vulnerability management stands today, try the self-assessment.

Weaknesses are not only in software; wrong cloud settings are also a risk to check. See What Is CSPM? Finding Cloud Misconfigurations.

Vulnerabilities in in-house code and libraries can be caught from the development pipeline onward; see DevSecOps: How to Use SAST, DAST and SCA.

Once scanning and fixing run on a cycle, see Pen Test vs Vulnerability Assessment vs Red Team to decide when to add penetration testing.

Before deciding which flaws to fix first, you can rank the wider risks with Simple Cyber Risk Assessment You Can Do Yourself.

References and further reading

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: the vulnerability life cycle, the four scenarios, maintenance groups and metrics (April 2022)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk: CISA's current directive, its four factors, and the revocation of BOD 22-01
• CISA BOD 26-04 Implementation Guidance: the 3-day due-date example and how asset exposure is determined
• CISA BOD 22-01 (revoked): the older directive that created the KEV catalog, useful as history only
• CISA Known Exploited Vulnerabilities Catalog: the KEV list, its criteria, and CSV and JSON downloads
• CIS Control 7: Continuous Vulnerability Management: the description of the control
• CIS Controls v8 Assessment Specification: Control 7: safeguards 7.1 to 7.7 with minimum frequencies
• FIRST CVSS v4.0 FAQ: Base scores are not risk, and FIRST's view of BOD 26-04