Server Patching Checklist
A patch management checklist for monthly server patching on Linux and Windows: triage, snapshots, staged rollout, reboots, verification and reporting.
- Typical schedule monthly
- The checklist 4 sections, 19 items
- Variables
{{month}}
Use this checklist for your regular patch cycle, usually once a month. Many teams align it with Microsoft's monthly security release on the second Tuesday. It works for Linux and Windows servers and for small fleets that are patched by hand or with simple tooling (e.g. unattended-upgrades, WSUS, Ansible, Azure Update Manager). Out-of-band patches for actively exploited vulnerabilities should still follow it, just faster.
Who owns it
One person owns each monthly run. They triage the available updates, schedule the maintenance windows and confirm that every server in scope is patched or has a documented exception. Service owners confirm that their applications work after the reboot.
Common pitfalls
- Patched but not rebooted. A kernel or system library update is not active until the server or the service restarts. Check for pending reboots, not only for installed packages.
- Patching everything at once. Patch a test or low-risk group first and wait a day. A bad update then hits one server, not all of them.
- The forgotten servers. Appliances, old VMs and that one box under a desk drift out of scope. Compare the patch report against your inventory every month.
- Silent exceptions. A server that "cannot be patched" needs an owner, a reason and a review date, or it stays unpatched forever.
Schedule the run in Runbook for the same day each month, so the checklist is waiting for you and the history shows which months were completed.
The checklist: Server patching {{month}}
Prepare
-
Available updates reviewed and security updates prioritised
Check vendor advisories and known-exploited vulnerability lists for anything that needs patching first.
-
Known issues for this month's updates checked in vendor release notes
-
Servers in scope listed from the inventory, grouped into pilot and main waves
-
Maintenance windows booked and service owners informed
-
Recent backups or snapshots confirmed for every server in scope
A VM snapshot is the fastest rollback; delete it again after a few days so it does not grow.
Pilot wave
-
Updates installed on the test or pilot group
-
Pilot servers rebooted and back online
-
Applications on pilot servers tested by their owners
-
Pilot left running for an agreed soak period without new errors
Main wave
-
Load-balanced or clustered servers patched one node at a time
Drain each node first, so users do not notice the reboot.
-
Remaining servers patched in their maintenance windows
-
All servers rebooted where required, with no pending reboot left
Linux: check /var/run/reboot-required or needs-restarting. Windows: check the pending-reboot state.
-
Services and scheduled tasks running again on every patched server
Verify and report
-
Monitoring shows all patched servers healthy with no new alerts
-
Patch level of every server in scope compared against the inventory
-
Failed updates investigated and re-run or ticketed
-
Exceptions recorded with owner, reason and review date
-
Old snapshots deleted after the agreed period optional
-
Patching summary for
{{month}}shared with the team
Checklist as Markdown
Frequently asked questions
How often should servers be patched?
Most teams run a regular monthly cycle and patch critical, actively exploited vulnerabilities out of band, as fast as they safely can. Your own risk, any contracts and any frameworks you follow (such as ISO 27001 or SOC 2) may set stricter timelines. Whatever you choose, write it down and stick to it.
What is the difference between patch management and vulnerability management?
Patch management is the routine process of installing vendor updates. Vulnerability management is wider: it finds weaknesses through scanning and advisories, rates them, and fixes them by patching, changing configuration or adding controls. Patching is the most common fix, but not the only one.
Should we automate patching instead of using a checklist?
Automate the installation wherever you can, for example with unattended-upgrades or your configuration management tool. The checklist then covers what automation misses: triage, pilot results, pending reboots, exceptions and a monthly record that the cycle actually happened.
Updated