Patch Management Process: Evidence at Every Step

Short answer: A patch management process is a repeatable sequence for finding affected systems, deciding which updates matter, preparing and deploying changes, and verifying the result. Give every step an owner and an output. A rollout is incomplete while targeted devices are unreachable, restarts are pending, or the intended software state has not been observed. NIST SP 800-40 Rev. 4 describes this lifecycle.

A patch management process with six handoffs

The process below is a suggested operating worksheet based on NIST's enterprise patch guidance. It is not a required set of job titles or a product's feature list. Put names, systems and evidence sources into each row before running a campaign.

A small team may assign several rows to one person. Keep the outputs distinct anyway. If a report only shows that a job was created, it cannot answer whether a returning laptop or a server outside the target group reached the intended state.

Step 1: start with the systems and software in scope

A patch campaign needs a denominator. Export the assets and installed software you believe are in scope, then compare that list with service ownership and other inventories. NIST SP 800-40 Rev. 4, section 3.2 recommends up-to-date software and asset inventories, including technologies beyond ordinary desktops.

At minimum, record the system identity, software and version, source of the observation, observation time, business role and person responsible for maintenance. Add the deployment group and network reachability needed to deliver an update. These fields are an editorial checklist, not an assertion that any particular tool collects them all.

Mark unknowns explicitly. A device absent from a recent inventory may be offline, unmanaged, retired or duplicated under another ID. Resolve the identity before deciding it is already covered. Keep exceptional systems such as appliances, shared workstations and business-critical servers visible even if another team administers them.

A simple scope check is to reconcile the target list against the affected-software list from the update notice. If they differ, either record why a system is not applicable or send it to the owner for investigation. The measured patch rate should always state which systems were eligible and when that list was observed.

Step 2: decide applicability and priority

Before deploying an update, determine whether it applies to the installed version, edition and configuration. Read the software vendor's advisory or release note and match its requirements to the asset inventory. For urgent security work, involve the owner of the related vulnerability finding so the approved response is clear.

Priority should reflect both the exposure and the operational cost of change. NIST's guidance discusses risk-based decisions and the need to account for enterprise constraints. Document the decision and the approver; do not convert a scanner score directly into an installation order without checking whether the finding applies.

Use these disposition labels in your own tracker:

• Deploy: a suitable update exists and the system is in scope.
• Investigate: software or applicability evidence is incomplete.
• Defer: the update is relevant but needs an approved later path.
• Use another response: no applicable patch exists or another action is approved.

Each label needs an owner and next review date. The labels are a suggested process, not a universal standard. A device that cannot take an update should still appear in the report with the risk decision attached.

Step 3: prepare a pilot and recovery decision

Choose pilot systems that represent the configurations and business workflows in the wider target group. Name what will be checked after installation: service start, application sign-in, a representative task and any dependency that could fail. Define who can stop the expansion if the pilot does not pass.

A pilot plan should answer what happens after a failed update. NIST SP 800-40 Rev. 4 notes that an update may require uninstalling, reverting software or restoring from backup after an operational problem. Whether one of those options works depends on the actual product and recovery design. Verify that path before relying on it.

The approval record should include target group, package source, change window, user communication, restart behavior and a named service owner. If a product supports rollout rings, record the rule that permits moving from one group to the next. Avoid an automatic expansion based only on elapsed time when the acceptance check has not been performed.

Step 4: deploy and separate the states

Run the approved deployment and follow the actual devices, not just the campaign summary. Update tools can report policy assignment, download, installation and failure as distinct states. For example, Microsoft's Intune feature update reports expose device-level update states and operational alerts; they also explain that different data sources refresh on different schedules. Do not apply its timing or state names to another product without checking that product's documentation.

For your own status report, distinguish:

These distinctions prevent a pending restart from being counted as complete. If the update software uses different labels, translate them into the evidence shown rather than forcing the table onto the product. Keep raw device results available for a reviewer who needs to inspect an exception.

Step 5: verify the software and the service

Verification answers two questions: did the target reach the intended software state, and does the service still perform its required work? Ask the deployment owner to capture a fresh version or patch observation. Ask the service owner to run the agreed acceptance check. NIST includes installation verification in the definition of enterprise patch management.

A tool may receive client reports later than a deployment action. Microsoft's Intune documentation makes this distinction explicit for its reports. Record the observation time and data source alongside a success count; a stale dashboard should not close an incident by itself.

Use one representative failed installation to test the workflow. Can an operator identify its device, error, last contact, business owner and next action without searching several unrelated consoles? If not, the process needs a stronger handoff or report export.

Step 6: close exceptions without losing targets

Move failures, unreachable systems, deferred changes and unsupported installations into an exception queue with a named owner. Record why each remains incomplete, its present risk decision, next action and next review date. A campaign can close administratively while its exceptions stay open and visible to the right owners.

Two later events deserve a fresh check. A device may reconnect after missing a rollout; compare its current software with the approved target before assuming it caught up. A system restored from an older backup may return to an earlier version. NIST's continued monitoring discussion supports verifying such changes after the original deployment.

Track the count of in-scope devices beside verified, failed, deferred and unobserved counts. These are suggested reporting buckets. The numbers should add up to the declared scope at a particular observation time, with duplicates and exclusions explained.

Bottom line

Take the next real update through this worksheet and inspect every device that did not reach verification. Assign those exceptions before beginning another campaign. Compare tools against the evidence and owner handoffs you actually need in the patch management category, then save candidates in your software shortlist.