Good patch management means knowing what you run, ranking updates by risk, testing them on a small group first, deploying on a set schedule with an emergency lane for exploited flaws, and verifying the result. NIST SP 800-40 Rev 4 frames this as an enterprise strategy, not an ad hoc chore.
Key takeaways
- Start with an inventory. You cannot patch what you have not listed.
- Rank by risk. Exploited and internet exposed flaws go first.
- Use two lanes: a routine cycle and a fast lane for emergencies.
- Verify. A patch that was deployed is not the same as a flaw that is gone.
What is patch management?
Patch management is the end-to-end handling of software updates, from identifying and prioritizing them to verifying they were installed. NIST SP 800-40 Rev 4, published in April 2022, calls patching "a critical component of preventive maintenance" and recommends creating an enterprise strategy to simplify and operationalize it.
What are the best practices?
- Keep an inventory. List hosts, containers, applications and dependencies with an owner for each.
- Watch for updates. Subscribe to vendor advisories and track CISA's KEV catalog.
- Prioritize by risk. CISA's BOD 26-04 weighs internet exposure, KEV status, automatability and technical impact. You can use the same questions.
- Test on a pilot group. Roll out to a small set of low risk systems first.
- Deploy in a schedule. Use a regular cycle for routine updates.
- Keep an emergency lane. Exploited flaws need a faster path with pre agreed approval.
- Plan rollback. Know how to undo a bad update before you ship it.
- Verify and report. Rescan to confirm the flaw is gone and track time to patch.
How fast should I patch?
Set a shorter clock for flaws attackers already use. Under the older BOD 22-01, CISA required KEV vulnerabilities to be fixed within two weeks, or six months for CVEs assigned before 2021. That directive is revoked. BOD 26-04 sets timelines in a table by risk factor, counted in calendar days, and a new KEV listing shortens the deadline. Read it for the model, then set your own numbers.
What about open source dependencies?
Treat them like any other software. Dependabot security updates open a pull request to the lowest version that contains a fix when an alert has an available patch, and merging closes the alert. For npm it may update a parent dependency. For other ecosystems it cannot update a transitive dependency when that needs a parent update, so some fixes stay manual.
Which mistakes slow patching down?
- No owner per asset, so tickets sit unassigned.
- Patching by severity alone, which buries the exploited items.
- No test group, so every patch feels risky.
- Never rescanning, so closed tickets hide open flaws.
Frequently asked questions
How often should I patch?
Run a regular cycle for routine updates and a separate fast lane for exploited vulnerabilities. Choose the intervals to fit your risk and change process.
What is the difference between patching and updating?
A patch fixes a specific flaw or bug. An update may add features too. In practice teams treat security fixes as patches whichever form they arrive in.
Should I automate patching?
Automate the safe, repeatable parts such as pull requests for dependency fixes, with tests as a gate. Keep human approval for high impact systems.
How do I know a patch worked?
Rescan the asset and confirm the vulnerable version is gone. Record the date for your time to patch metric.
Sources
- NIST SP 800-40 Rev 4: https://csrc.nist.gov/pubs/sp/800/40/r4/final
- CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- CISA BOD 22-01 (revoked): https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- GitHub, about Dependabot security updates: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
Last reviewed: 19 October 2026.
