Your deployment tool installs the updates. It does not decide which ones matter this month, prove they were tested, record who approved the rollout or chase the servers that were switched off on the night. This free patch management checklist runs the monthly cycle around the tool for IT operations teams, MSPs and security leads. It covers release intake, risk-based prioritisation, a test and pilot ring, change approval, staged deployment and independent verification, and ends with a signed report and an exception register with expiry dates. When an actively exploited vulnerability cannot wait, one answer switches the checklist to an emergency out-of-band path.
NIST SP 800-40 Rev. 4 treats patching as preventive maintenance and asks organisations to plan for four situations: routine patching, emergency patching, emergency mitigation when no patch exists yet, and assets that cannot be patched at all. It also recommends grouping assets with similar needs into maintenance groups, each with its own plan and deadlines. That is the backbone of this checklist: a patch’s deadline comes from its group’s plan, not from whoever is on shift. The emergency path exists so that a critical fix released on a Thursday does not wait three weeks for the next window, and so that speed does not cost you the record of what changed.
Trigger: Microsoft’s security release on the second Tuesday of each month, plus the distribution, application and firmware updates published since the last cycle.
Testing: a test ring, then a pilot ring that soaks for days before production.
Approval: usually a pre-approved standard change with booked windows.
Output: a verified compliance report and a reviewed exception register.
Trigger: a CVE added to CISA’s Known Exploited Vulnerabilities catalog that affects your systems, a vendor out-of-band release or evidence of exploitation.
Testing: a canary group for hours rather than days, as NIST suggests.
Approval: an emergency change, recorded even when approval is retrospective.
Output: exposed systems patched or mitigated and checked for compromise.
Six phases take a routine cycle from release intake to a signed report. Marking the cycle as an emergency swaps the test and approval phases for a compressed out-of-band path.
The cycle type chosen here drives the rest of the checklist. Emergency hides Phases 3 and 4 and shows Phase 7.
Hidden for emergency cycles. If the pilot result is recorded as Fail, the last two tasks appear.
Hidden for emergency cycles, which use the emergency change task in Phase 7.
If any asset missed its deadline, the exception task appears. The cycle is not signed off until every exception has an owner.
Shown only when the cycle type is Emergency. It replaces Phases 3 and 4; intake, prioritisation, deployment and verification still run, on a compressed timetable.
Phase 2 only works if deadlines are agreed before the cycle starts. The targets below are illustrative: set your own from your risk appetite and any scheme you are certified against, and write them into the plan so nobody negotiates them patch by patch.
| Trigger | Example target | Path in the checklist | Reference point |
|---|---|---|---|
| KEV-listed CVE on an internet-facing system | Patch or mitigate within 72 hours | Emergency, Phase 7 | BOD 26-04 sets 3 days plus forensic triage for the highest-risk federal cases |
| KEV-listed CVE on an internal system | Within 14 days | Routine, or emergency if exploitation spreads | Active exploitation is the strongest signal CISA publishes |
| Vendor critical or high, or CVSS v3 7.0 and above | Within 14 days of release | Routine, first production ring | Cyber Essentials requirement for in-scope software |
| Medium and low severity updates | Within the monthly cycle | Routine, all rings | CIS Controls v8.1 Safeguards 7.3 and 7.4: monthly or more often |
| Firmware, BIOS and hypervisor updates | Next planned window, unless a security bulletin raises the priority | Routine, normal change | Plan around host evacuation and vendor support matrices |
| No patch available, or asset cannot be patched | Compensating control in place, reviewed every cycle | Exception, Phase 6 | NIST SP 800-40 Rev. 4: track and regularly review all exceptions |
For US federal agencies the rules changed in 2026. CISA’s Binding Operational Directive 22-01, which gave agencies two weeks to fix most newly listed KEV vulnerabilities, was revoked on 10 June 2026 by BOD 26-04. The new directive sets timelines of 3, 14 or 60 calendar days, or a fix at the next major upgrade, depending on four factors: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation can be automated and how much control an attacker gains. Private organisations are not bound by it, but the four questions make a sound triage rule.
For the rest of the queue, FIRST’s Exploit Prediction Scoring System (EPSS) publishes a daily estimate of the probability that each CVE will be exploited in the next 30 days. For ISO/IEC 27001:2022, the evidence from Phases 2 and 6 supports Annex A control 8.8, management of technical vulnerabilities.
A recurring schedule opens the cycle the day after the monthly release, and dynamic due dates count each phase forward from that start. The pilot, each production ring and the report carry a date before anyone touches a server, so a slipping cycle shows up as overdue tasks.
Conditional logic reads the cycle type and the pilot result. An emergency hides the multi-day soak and the standard change tasks and shows the out-of-band path. A failed pilot adds the hold and mitigation tasks.
Each unpatched asset is a row in a table inside the exception task, with owner, reason, compensating control and expiry date. Scan reports and change approvals attach to the task they prove, and the activity trail records who signed off each cycle and when, ready for the auditor.
CheckFlow does not install patches, and it does not replace your deployment or RMM tool. It runs the decisions, approvals and evidence around that tool. Our guide to recurring compliance checklists for IT teams explains why monthly patch verification is the check auditors ask about most, and how it sits alongside access reviews and backup checks in one compliance calendar.
The Server Maintenance Checklist covers the routine health of running servers and simply confirms that this cycle was signed off. Firmware upgrades that need a normal change can go through the IT Change Management Checklist, and new servers should join a maintenance group at build time through the Server Setup & Provisioning Checklist.
It should follow the life of a patch cycle: collecting releases and reconciling them against the asset inventory, prioritising by exploitation and exposure, testing on a small ring, approving the change, deploying in stages, then verifying independently and recording exceptions. It also needs an emergency path for fixes that cannot wait. A checklist that stops at “deploy updates” misses the part auditors and attackers both care about: the servers left behind.
At least monthly, with faster deadlines for the fixes that matter most. CIS Controls v8.1 Safeguards 7.3 and 7.4 call for operating system and application updates through automated patch management monthly or more often. The UK Cyber Essentials scheme requires updates that fix critical or high-risk vulnerabilities to be installed within 14 days of release. An exploited flaw on an internet-facing server justifies an emergency change within days.
Start with evidence of exploitation, then exposure, then severity. A CVE in CISA’s Known Exploited Vulnerabilities catalog is being used by attackers now, so it outranks a higher CVSS score that nobody is exploiting. Internet-facing services, remote access and identity systems come before internal file servers. Vendor severity, CVSS and EPSS scores then order the rest.
Vulnerability management is the wider programme: finding weaknesses, assessing the risk and deciding a response. Patch management is the most common response: acquiring, testing, deploying and verifying vendor updates. Some vulnerabilities are handled without a patch, through configuration changes, isolation or an accepted risk, which is why this checklist records a response for every item.
Pause or decline the patch in the deployment tool so later rings do not receive it, and tell the owners of the pilot servers. Then put an interim mitigation in place for the vulnerability it fixes, open a vendor case and record a date to try again. The worst outcome is a failed patch that quietly drops out of every future cycle.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
