NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. Each verb corresponds to a stage you can time, so the definition doubles as a measurement plan. If you time all five, you can see where an exposure window is really spent.
The definition
The abstract of NIST SP 800-40 Rev. 4, published April 2022, says enterprise patch management is the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization. It frames patching as preventive maintenance, a cost of doing business, and recommends an enterprise strategy that simplifies and operationalizes patching while reducing risk.
This guide is written for patching broadly. The same five verbs fit application dependencies, container images and operating systems.
The mapping
| NIST verb | Exposure stage | What to timestamp |
|---|---|---|
| Identify | Detection | Advisory published, alert raised |
| Prioritize | Triage | Decision recorded, owner assigned |
| Acquire | Fix preparation | Fixed version available, PR or build created |
| Install | Merge and deploy | Merge, deploy start, deploy complete |
| Verify | Confirmation | Running version checked, finding closed |
Notice that verification is a stage with a clock. Many teams stop timing at merge. A fix that is merged but not running is not a fix, and the verification stage is where you catch the services that never got the new build.
What each stage tends to reveal
- Identify. Long gaps usually mean missing inventory or alerts not enabled on some repositories.
- Prioritize. Long gaps mean unclear ownership or no agreed criteria.
- Acquire. Long gaps mean no fixed version exists or the fix needs a parent upgrade.
- Install. Long gaps mean approvals, release trains or fragile pipelines.
- Verify. Long gaps mean nobody checks, or you cannot tell which version is deployed.
A one page worksheet
For each high priority finding, fill in five times and four gaps.
- Advisory published (or first seen).
- Triage decision made.
- Fix PR or build ready.
- Deployed.
- Verified.
Gaps: identify to prioritize, prioritize to acquire, acquire to install, install to verify. Sum them for the whole window, and note the largest.
Using it with a policy
When you write a remediation policy, state a target per verb as well as a total. A total target of a given number of days tells a team nothing about where to improve. A set of five stage targets tells them which handoff to fix. Choose the numbers from your own history rather than copying another organization.
NIST's framing also helps with leadership. Preventive maintenance is a familiar idea in other fields, and it explains why patching time is an operating cost, not an optional extra.
Avoid these traps
- Counting identify as zero because a tool reported instantly. The advisory may have existed earlier.
- Skipping prioritize because "everything is urgent". That stage exists to protect people's time.
- Treating install as done at merge.
- Not verifying across all environments. A staging deploy is not production.
Try it yourself
Open the vulnerability management demo and map each screen to one of the five verbs.
Click through it at your own pace, or open it full screen.
Safeguard supports compliance and evidence automation alongside dependency scanning and remediation tracking. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does NIST set a time limit for patching?
The abstract describes the process and strategy. Check the full publication and your own obligations before quoting any deadline.
Which stage do teams forget to time?
Verification. Confirm the fix is running, not just merged.
Sources
Last reviewed: 19 October 2026.
