Patch management is a cycle, not a button

The work is not simply about approving an update: you need to decide, deploy, observe and repeat. NIST presents patch management as preventive maintenance at enterprise scale. This approach brings security and reliability together rather than treating them as opposing priorities.

A complete cycle links inventory, vendor advisories, risk analysis, testing, deployment and verification. It also specifies who approves an emergency, represents the business application, informs users and temporarily accepts an exception.

A monthly cadence is appropriate for routine updates, without becoming an automatic waiting period. An actively exploited vulnerability or exposed service may require action outside the normal cycle; a critical system may sometimes require enhanced validation. In a multi-site organisation, the maintenance window should reflect usage patterns, night teams and support availability.

Start with an actionable inventory

A useful inventory links each asset to a version, owner, exposure and business function. A list of serial numbers is not enough.

Catalogue workstations, servers, browsers, office suites, PDF tools, video conferencing, agents, business applications and background components. Add hypervisors, firewalls, switches, Wi-Fi, printers, VoIP and firmware. For the cloud, record what the vendor updates and what remains your responsibility: connectors, agents, extensions, images or libraries.

Record product, version, device, location, technical and business owners, criticality, exposure, update method, maintenance window and last contact. “Unknown” must be addressed: a laptop absent for forty days and a server without an owner enter the exception queue.

Choose a source of record when the endpoint tool, directory, CMDB and procurement records conflict. Reconcile replaced devices or devices that were never enrolled. To outsource this monitoring, GVISION’sIT managed services and support page describes the ongoing service; this guide remains focused on the methodology.

Prioritise according to actual risk

The most severe patch is not automatically the most urgent. Combine observed exploitation, exposure, privileges, business impact, mitigations and confidence in the patch.

Start with known exploited vulnerabilities. CISA’s KEV catalogue complements vendor and national advisories. Then check whether the asset is Internet-accessible, manages identities, has elevated privileges or accesses sensitive data. A medium-severity vulnerability on a perimeter device may take priority over a critical vulnerability in an isolated laboratory.

Add operational criticality. Billing, clinical, education or production environments require owners who can test essential functions. Agree on a deadline, a temporary reduction in exposure and a reassessment date.

Keep it simple: out-of-cycle emergency, high priority, normal cycle or monitoring. Associate a deadline, approver, test and communication requirements according to the sector and recovery capability.

Comparing four deployment approaches

No approach is superior in every situation: the right choice depends on urgency and the cost of an interruption. The same organisation can use several approaches simultaneously.

Build genuinely representative rings

A good pilot represents risky dependencies; it does not simply bring together the most tolerant technicians. Test on the hardware, software and user profiles that represent the next wave.

A first ring may include the IT team and a few laboratory machines. The second brings together voluntary pilot users: finance, management, reception, mobile teams, people using business applications, scanners, specialised printers, VPNs or smart cards. The third covers a larger proportion of the estate; the final ring receives sensitive systems after explicit validation.

Avoid placing all executives, all members of one department or all backup machines in the same ring. Distribute critical roles. For a cluster, do not patch all nodes simultaneously. For an isolated site, ensure that local assistance or a procedure is available if the restart fails.

Define progression criteria: installation rate, absence of blocking alerts, validation of authentication, applications, printing, VPN and important peripherals. Specify who gives the go-ahead and how long the signal is monitored. User silence is not automatically validation; a short functional test is more reliable.

Microsoft states that Intune update rings control, among other things, deferrals, deadlines, restart behaviour and the user experience. Its documentation on Windows update management, updated on 1 April 2026, also notes that Intune stores policy assignments while devices download approved content from Windows Update.

Plan for powered-off laptops and remote teams

A night-time maintenance window is useless if devices are switched off; the policy must define what happens at the next connection. Catch-up is part of the design, not end-of-month clean-up.

Decide whether downloads can run in the background, whether installation starts at the next contact and how the user chooses when to restart before the deadline. Windows policies allow you to configure a deadline and grace period. Microsoft specifies that, on recent versions of Windows 11, the grace period begins once installation is complete and a restart is required; after the effective deadline, the restart may be enforced. Test these behaviours with your versions and policies rather than assuming them.

Communicate in useful terms: deadline, estimated duration, whether the device needs to be plugged in, how to defer the restart and who to contact for support. A succession of vague notifications teaches users to ignore them. For teams in consultations, classrooms, on construction sites or in continuous service, agree realistic periods with managers.

Create a queue for devices not seen for a defined number of days. Distinguish leave, stock, failure, disposal, backup device and shadow IT. After a long absence, avoid a forced restart immediately after sign-in where possible: the grace period and communication should allow work to be saved while closing the gap quickly.

Treat servers as dependent services

A server is not patched in isolation: you maintain a chain of applications, databases, identities, networks and backups. The plan should start with the service being delivered.

Map the shutdown and startup order, service accounts, certificates, available storage, pending queues and scheduled tasks. Verify the appropriate backup and, above all, the recovery procedure. A snapshot may help in some environments, but it is neither a universal backup nor always compatible with a transactional application. Follow the vendor’s recommendations.

For redundant systems, remove one node, patch it, check its health and synchronisation, then move to the next. For a single server, agree on an interruption window, test essential functions after the restart and define a decision deadline for rollback. Keep the vendor’s contact details and the licences required for recovery.

Do not confuse successful installation with a healthy service. After patching, test authentication, ports, processing, exchanges, backup and monitoring. Ask the business owner to confirm a representative transaction. Technical verification and functional validation address two different risks.

Do not forget third-party software, drivers and firmware

A fully patched Windows estate can still be vulnerable through its browser, PDF reader, meeting tool, remote agent or network equipment. Measure coverage by product, not just operating system compliance.

Classify applications into three categories: reliably updated automatically, requiring centralised deployment and legacy products requiring a manual procedure. Check the update channel, package signatures, supported versions and dependencies. For browser extensions and integrated components, identify the owner; grey areas often last longer than difficult patches.

Treat drivers and firmware with caution. They fix vulnerabilities and hardware defects, but can alter networking, storage, display or peripherals. Test by device model and retain rollback packages when provided by the manufacturer. Microsoft Autopatch can manage the approval and progressive deployment of certain drivers and firmware, but its prerequisites and licence entitlements must be verified for the relevant tenant.

Equipment that connects rarely deserves a separate register: spare devices, meeting-room PCs, kiosks, shared tablets, printers, phones and appliances. Organise periodic reconnection or on-site maintenance. An inventory that shows “compliant” because it has forgotten the asset creates a false sense of assurance.

Prepare exceptions and rollback before deployment

An exception without an owner or deadline becomes a permanent vulnerability; an untested rollback remains merely an intention. Both must be decided before the maintenance window.

For each wave, record stop conditions: installation failure, loss of connectivity, essential application unavailable, increase in incidents or deterioration of an indicator. Specify who can suspend the wave, how to isolate affected devices and which version to restore. Keep the instructions outside the system that may become unavailable.

When a patch cannot be installed, document the reason, assets, risk, compensating measure, owner, approver and review date. A compensating measure may reduce exposure, disable a function, restrict access or strengthen monitoring. It does not eliminate the need to patch or replace the product.

Rollback is not always possible or desirable. Some updates modify data, schemas or components whose uninstallation does not restore the original state. This is why backup, recovery, vendor documentation and functional testing are linked. The decision must compare the risk of remaining patched with a regression against the risk of returning to a vulnerable version.

Apply an eight-step operational cycle

A short, repeatable procedure is better than a theoretical document that nobody follows. Use these eight steps as a baseline, then adapt them to the estate.

1. Discover: reconcile assets, versions, owners and last contact.
2. Monitor: collect vendor advisories, exploitation information and relevant national alerts.
3. Qualify: verify applicability, exposure, criticality and existing measures.
4. Decide: classify as emergency or normal cycle, define the deadline and approver.
5. Test: deploy to the laboratory and representative pilots with a functional scenario.
6. Deploy: roll out in waves, maintenance windows and documented catch-up rules.
7. Check: check the version, restart, service health and user feedback.
8. Improve: address failures, exceptions, unknown assets and lessons learned before the next cycle.

If your Microsoft environment is suitable, the Microsoft Intune and endpoint management services can support rings, deadlines and reporting. The process must nevertheless also cover servers, third-party software and equipment outside this scope.

Windows Autopatch automates several Microsoft workloads and uses ring sequences. The official documentation, updated on 13 July 2026, covers Windows, Microsoft 365 Apps, Edge and Teams depending on the applicable entitlements. Do not conclude that a “patch management” product covers everything: establish a product-tool-owner matrix.

Measure risk reduction, not activity volume

The number of patches sent measures effort; verified compliance and ageing exceptions are better measures of the outcome. A dashboard should drive action.

Track inventory coverage, the proportion of assets seen recently, the time between decision and installation, success by wave, pending restarts, exploited vulnerabilities still present, open exceptions and their age. Separate workstations, servers, third-party applications and network equipment. An overall average can hide a small highly exposed group.

Present failures by cause: device absent, insufficient storage, policy conflict, unsupported version, installation error, missing restart or business dependency. Each category should have an owner and a next action. Archive the timestamp, scope, approval, outcome and deviations so that a decision can be reconstructed.

A short monthly meeting can examine three questions: which assets are not under control, which exceptions have passed their deadline and which incidents require the rings or tests to be changed? The report for management should translate technical details into exposure and continuity, without promising zero risk.

Avoiding common mistakes

Failures often result from an incomplete process rather than the patch itself. The following mistakes are predictable.

• Deploying everything at once: a minor issue becomes a widespread incident.
• Piloting only with IT: business applications and peripherals are never tested.
• Waiting for the monthly window for every vulnerability: active exploitation may require an emergency procedure.
• Treating absent devices as compliant: the dashboard improves while exposure remains.
• Patching only Windows: browsers, third-party tools, firmware and appliances remain overlooked.
• Forcing a restart without communication: users work around the rules or lose work.
• Closing on “deployed”: installation, restart and service health are not verified.
• Accepting an undated exception: technical debt becomes permanent.

Start with a reconciled inventory, two representative rings, an emergency rule and a failure report. Then add applications, servers and equipment.