Patching fails in two directions. Patch too slowly and you carry known vulnerabilities for months. Patch everything the moment it ships and one bad driver update takes out a whole department on a Wednesday morning.
The answer is a policy, written down, that the client has agreed to. It says which devices get updates when, how long you wait before widening, when reboots are allowed, and what happens when an update breaks something. Here is what that policy looks like.
Rings: who gets it first
Split the fleet into rings by risk tolerance, not by department. Ring 0 is IT's own devices plus a couple of volunteers. Ring 1 is a representative slice of ordinary workstations, roughly one in ten. Ring 2 is the rest of the workstations. Servers get their own rings: non-production and secondary nodes first, then production, then anything that has to be patched by hand.
The delay between rings is where you catch problems. A few days between Ring 0 and Ring 1, then about a week to Ring 2, is a reasonable default for Windows quality updates. Feature updates and firmware need longer. Zero-day fixes flagged as actively exploited skip the delay after a quick Ring 0 check.
- Ring 0: IT devices and volunteers, updates on release
- Ring 1: pilot slice of workstations, a few days later
- Ring 2: all remaining workstations, about a week after Ring 1
- Servers A: test, dev, secondary cluster nodes
- Servers B: production, in a scheduled window with a snapshot first
- Exceptions: devices that cannot be auto-patched, listed by name with a reason and an owner
Maintenance windows and reboots
Users tolerate patching. They do not tolerate a surprise reboot mid-presentation. Set active hours on workstations so reboots happen outside them, and give a visible deadline with a grace period so people can save work. In Intune this is the Windows Update ring settings; with Group Policy it is Configure Automatic Updates and the active hours policy.
Servers get a written window per system. For a small business a single window on a weeknight or weekend morning is fine. For anything with a dependency chain (database, then application, then web front end) write the reboot order into the runbook and follow it. Notify the client before the window, and again when it closes, with what was applied.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, Description, InstalledOnApproval rules and what you do not auto-patch
Auto-approve OS security and quality updates for workstations after they clear Ring 0. Auto-approve browser and common application updates the same way. Manually approve feature updates, firmware and BIOS, driver packages, hypervisor updates, and anything for line-of-business software where the vendor has its own compatibility list.
Third-party patching matters as much as Windows updates. PDF readers, Java runtimes, remote access tools and browsers are where most workstation compromises start. Your RMM or a dedicated third-party patch tool should cover them on the same rings.
- Auto-approve: Windows quality and security updates, browsers, Office, common utilities
- Manual approve: feature updates, drivers, firmware, hypervisor, network device OS
- Never auto-patch: the line-of-business server until the vendor confirms support
- Review the pending and failed list weekly, not just on patch day
Rollback: assume something will break
A rollback plan is what lets you patch aggressively. For servers, take a snapshot or a backup checkpoint before the window and delete it after a few days of clean running. For workstations, know the uninstall command for a Windows update and keep the update's KB number in the change record so you can pause it in the deployment tool.
When an update does break something, the sequence is: pause the update for the remaining rings, uninstall it on the affected devices, document the KB and the symptom, and open a case with the vendor if it is their software. Then decide whether to wait for a fix or block the update permanently.
- Snapshot production servers before the window; note the snapshot name in the change ticket
- Verify the critical service after reboot, not just that the host is up
- If broken: pause the update in the deployment tool, then roll back affected devices
- Record the KB number, symptom and fix in the runbook so it is not rediscovered next month
wusa /uninstall /kb:5000000 /quiet /norestartFrequently asked questions
How fast should a critical vulnerability be patched?
Faster than the normal ring schedule. Do a short Ring 0 check, then push to everything internet-facing the same day and to the rest within the week. Write this fast-track path into the policy so nobody has to invent it under pressure.
Should users be able to defer updates?
A short deferral with a hard deadline is fine and reduces complaints. Unlimited deferral turns into unpatched devices.
Who signs off on the patch policy?
The client's owner or IT lead, in writing. It is a business decision about acceptable downtime and risk, and it protects you when a scheduled reboot is questioned.
Takeaway
Rings, windows, approval rules and a rollback path. Write those four things down, have the client sign them, and patching becomes routine. The delay between rings and the pre-window snapshot are what let you patch quickly without fear.