On this page
Short answer: A patch management checklist should start with the systems and applications your team owns, then test how a tool finds applicable updates, controls rollout and proves the result on each device. Give every requirement a priority and a pass test. A vendor's supported-product list alone cannot prove that your installed editions, offline endpoints and exceptions are handled.
Key takeaways
- Count eligible, unreachable, failed and verified systems separately.
- Match third-party applications by installed edition and version, not product name alone.
- Test pilot approval, restarts and recovery before enabling broad automation.
- Require current device-level evidence and an export your team can use after a trial.
How we built this checklist
The worksheet follows the ten editorial criteria for the Patch Management category and the stages in NIST SP 800-40 Rev. 4: identify, prioritize, acquire, install and verify updates. It also reflects CIS Controls v8 Control 7, which distinguishes operating system patching from application patching. These sources guide the questions. They do not endorse a particular product.
Use "Not published" when a vendor does not document a feature or limit. Use "Not tested" when the documentation exists but your environment has not demonstrated it. Keep these labels separate from "No" so the final comparison makes uncertainty visible.
The priority labels in the table are suggestions. An MSP may require tenant separation; a single-site team may give it lower priority. Agree on the required operating systems, application catalog, sites and approval process before asking a vendor for a demonstration.
Define your patching scope first
List the operating system versions, device types and business applications you maintain. Include servers, laptops that often go offline, devices outside the usual management path and software installed by users. Record who approves interruption for each service. NIST's planning guidance emphasizes current asset and software inventories for patch decisions.
Your trial should include at least one representative of each important installation pattern. A clean demonstration device can conceal problems with user-scoped applications, old versions, unusual architecture or a device that missed a previous rollout.
| Scope field | Record before the trial |
|---|---|
| Device group | Business role, owner, site and platform version |
| Application installation | Publisher, edition, branch, architecture and install location |
| Existing update path | Native updater, managed package, manual owner or unknown |
| Change authority | Person who approves rollout, restart and exception |
| Evidence requirement | Current version, update result and service acceptance |
| Reporting boundary | Managed, unmanaged, unreachable and retired systems |
An inventory is only as current as its last observation. Set a freshness rule for your organization and show the last contact time next to device status. A device absent from the report may be unobserved rather than fully patched.
Patch management requirements matrix
Copy these rows into a vendor evaluation sheet. Ask the vendor to cite current documentation, then record the result of your own test. A passing answer should name the device, update and observation time rather than only a dashboard count.
| Requirement | Suggested priority | Question to ask | Trial proof |
|---|---|---|---|
| Operating system support | Must | Are our exact OS versions and device roles supported? | Update an eligible workstation and server if both matter |
| Third-party app coverage | Must | Which editions, branches and architectures match? | Detect and update an existing application copy |
| Inventory and applicability | Must | How are unknown and stale devices shown? | Compare product inventory with known installed software |
| Approval and priority | Must | Who can approve an update or exception? | Record one routine and one urgent decision |
| Staged rollout | Must | Can a pilot gate wider deployment? | Stop or pause after a failed pilot check |
| Restart control | Must | How are pending and completed restarts separated? | Show device status before and after a required restart |
| Version verification | Must | Does the report prove the resulting version? | Export a fresh device-level observation |
| Failure and exception | Must | Who owns failures and deferred targets? | Show an offline device and a failed installation |
| Roles and audit | Should | Which permissions and actions are logged? | Demonstrate separate operator and approver accounts |
| Integration and export | Should | Can evidence be exported with stable device IDs? | Open a usable export outside the console |
| Pricing and exit | Must | What is billable and what happens to history on exit? | Written quote basis and tested export |
These are buying requirements, not assumed capabilities. If a tool cannot meet a Must row, document whether a separate approved workflow covers it. Do not convert an untested sales claim into a passed requirement.
Test a rollout that includes real exceptions
A useful pilot exercises the states that produce follow-up work. Assign an update to a small group with a documented acceptance check. Include a device that is offline, one with a pending restart and one application installation that did not originate from your normal deployment system. Use an approved test environment for any deliberate failure.
Track a device through these states: targeted, contacted, update attempted, installed, activated and verified. Those labels are a suggested reporting model, not the terms used by every vendor. Microsoft's Intune update reports illustrate why a device's service-side and client-side update states may differ and why report freshness needs attention.
| Trial event | Pass criterion | Evidence to retain |
|---|---|---|
| Device offline at assignment | Remains visible and is followed after reconnection | Target list, last contact and later result |
| Application not in catalog | Shows as unmatched, not falsely covered | Inventory and exception owner |
| Pilot fails acceptance | Wider rollout can be stopped by the approved owner | Stop decision and target changes |
| Restart required | Pending state is separate from verified | Device state before and after restart |
| Update installs | Intended version is observed on the device | Version, time and collection method |
| Recovery needed | Supported path is documented for that software | Recovery procedure and service check |
A patch status alone does not prove the application still works. Ask the service owner to perform the agreed business workflow after a representative update. Keep both the deployment result and that acceptance check in the change record.
Ask for evidence you can audit and export
Request a device-level export with stable IDs, software, old and target version, assignment, action time, last contact, installation result, restart state and verification time. The exact fields depend on the tool, but the export must let an administrator explain an unresolved device without reconstructing events from memory.
Separate four counts in every campaign report: verified, failed, deferred and not observed. State the total eligible device count beside them, with the time that inventory was taken. A clean percentage with no denominator can hide unmanaged devices and stale data.
For security-related updates, connect the patch evidence to the finding owner. The finding may require a fresh scan or configuration check before closure. NIST SP 800-40 Rev. 4 makes verification part of patch management, while the broader risk decision remains with the people accountable for the affected service.
Exceptions should stay visible after the deployment campaign ends. Give each failure or deferment a reason, owner, interim action and review date. Recheck systems after a restore or a long period offline; previously recorded success does not prove the present state.
Questions to put in an RFP or trial request
Send the vendor a short list of real device and application examples. Ask for documentation where a response can be verified before the meeting. Use the same questions for each candidate:
- Which exact OS releases and application editions in our inventory are supported today?
- How does the product detect an existing installation and distinguish user-scoped from device-wide copies?
- What happens when a target is offline, a package fails or an update requires a restart?
- Can an approver stop a wider rollout after a pilot fails?
- How are separate tenants, sites or device owners represented?
- Which audit events and device-level results can be exported?
- What is the billable unit, minimum commitment and feature gating on the quoted plan?
- Which data and configuration can be exported when the contract ends?
Document the answer, source date and trial result for each question. If an answer is unpublished, record it as such and ask for written confirmation before making a decision that depends on it.
FAQ
What belongs in a patch management checklist?
Include platform and application coverage, inventory, applicability, rollout approval, restart behavior, verification, failure handling, access control, pricing and exit. Pair every requirement with a test and evidence field so it can be assessed consistently.
How do I test third-party application patching?
Choose installed applications that represent your actual editions, architectures and installation paths. Confirm the tool detects the existing copy, applies the intended update and records the resulting version. Include at least one unmatched or user-installed copy.
Is a successful deployment status enough evidence?
It proves the deployment tool reported an action. Check whether activation, a current version observation and service acceptance are still pending. Keep failed and unreachable targets outside the verified count.
How many tools should be on a shortlist?
Use as many as your team can test against the same requirements and representative devices. A small shortlist with repeatable evidence is more useful than a long feature grid built from sales claims.
Bottom line
Choose representative devices and applications, then run each candidate through the same exception-heavy pilot. Record what was verified, what failed and what remains unknown. Start with the patch management category and keep finalists in your software shortlist.
Sources (4)
- Guide to Enterprise Patch Management Planning, SP 800-40 Rev. 4, NIST, April 2022. Accessed September 26, 2026.
- SP 800-40 Rev. 4 full publication, NIST. Accessed September 26, 2026.
- CIS Controls v8, Control 7, CIS. Accessed September 26, 2026.
- Windows feature update reports, Microsoft Learn. Accessed September 26, 2026.