The vulnerability management lifecycle has five steps: know which vulnerabilities affect your assets, plan a risk response, execute it, verify that it worked, and keep monitoring that it stays in place. NIST SP 800-40 Revision 4 frames it this way, and every step depends on an accurate asset list.
What are the four ways to respond to a vulnerability?
NIST SP 800-40 Revision 4 names four risk responses, and patching is only part of one of them:
- Accept the risk, for example because other controls prevent exploitation or the impact is low.
- Mitigate it: patch, disable the vulnerable feature, upgrade, or add controls such as firewalls and network segmentation to isolate the asset.
- Transfer it, for example with insurance or by replacing a self-managed install with a software-as-a-service product where the provider patches.
- Avoid it, by removing the attack surface: uninstall the software, retire the asset, or disable the capability.
The lifecycle applies to all four.
What are the five stages?
1. Know. The publication says this means knowing what assets you use and which software and versions they run, down to the level of packages and libraries, and tracking new vulnerabilities in them. Feeds from vendors, researchers and the National Vulnerability Database are inputs. If your inventory stops at servers and ignores libraries, you will miss most application risk.
2. Plan. Assess the risk the vulnerability poses to you, choose the response, and decide how to carry it out. NIST gives an example: risk is higher when the flaw is present on many assets and is being exploited in the wild.
3. Execute. This has sub-steps: prepare (get and test the patch, schedule with change management), implement, verify, and continuously monitor.
4. Verify. For patching, confirm the patch is installed and took effect. For added controls, confirm they work. For avoidance, confirm the asset is gone.
5. Monitor. Make sure nobody uninstalls the patch, turns off the control, lets the insurance lapse, or restarts the retired asset.
Documentation, audit logging and reports run through all of it.
How should you rank what to fix first?
Severity scores alone give long lists. CISA gives two concrete helpers. First, the Known Exploited Vulnerabilities (KEV) catalog, which CISA describes as the authoritative source of vulnerabilities exploited in the wild, and advises organizations to use as an input to their prioritization framework. Second, Binding Operational Directive 26-04, which applies to US federal civilian agencies but shows a useful method. It ranks urgency using four variables: whether the asset is publicly exposed, whether the vulnerability is in the KEV catalog, whether an adversary can automate all steps to exploit it, and whether exploitation gives partial or total control of the asset.
Those four questions work for any organization. Public exposure and known exploitation matter far more than a high score on a system nobody can reach.
NIST SP 800-40 Revision 4 also recommends grouping assets into maintenance groups, each with a plan for routine patching, emergency patching, emergency mitigation, and assets that cannot be patched.
A constructed example
A company's scanner reports 4,200 findings across 300 systems. The team asks the four questions. Eleven findings are on internet-facing systems. Two of those are in the KEV catalog. One of the two lets an attacker take control without logging in. That one is fixed the same day, with a documented emergency change. The other is fixed within the week. A legacy lab server with 60 findings cannot be patched; it is moved to an isolated network segment and put on a retirement plan, which is the avoid and mitigate responses at work. The remaining findings go into the routine monthly cycle.
How to check or apply this
- Build the asset and software inventory first, down to packages and libraries.
- Pick your feeds: vendor advisories, the NVD, and the KEV catalog. Assign an owner to read them daily.
- For each new finding, answer the four prioritization questions and record the answer.
- Define maintenance groups with a routine plan and an emergency plan, and one for unpatchable assets.
- Verify every fix with a rescan or a version check, and close tickets only after verification.
- Review monthly: count of exposed and known-exploited findings open, and average time to fix them.
- Keep exceptions in a register with an owner and an expiry date.
Quick check
Is patching the same as vulnerability management?
No. Patching is one way to mitigate. NIST also lists accept, transfer and avoid, and the lifecycle includes planning, verifying and monitoring.
Should I fix everything with a high CVSS score first?
Not automatically. Exposure, known exploitation, how easily exploitation can be automated, and what an attacker gains are better guides to urgency than the score alone.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA, Known Exploited Vulnerabilities Catalog
- CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
Last reviewed: 18 October 2026.
