Patch management: testing, rollout rings and emergency patches
In short: Patch management keeps software up to date in a controlled way. Good programmes know what they run, test patches on small groups first, roll out in rings, have a fast path for emergencies, and measure how many systems are actually patched.
Why patching is hard
Applying an update sounds simple, yet unpatched systems remain one of the most common ways attackers get in. The difficulty is scale and risk: hundreds of products, thousands of devices, business systems that cannot go down, and the fear that a patch will break something. Patch management is the process that makes patching routine, safe and measurable.
The core process
- Inventory: list operating systems, applications, firmware and cloud images, with owners. Do not forget network devices, hypervisors and third-party software.
- Monitor releases: follow vendor advisories. Microsoft releases most security updates on the second Tuesday of each month, often called Patch Tuesday; many other vendors publish on their own schedules.
- Assess: decide urgency using exploitation, exposure and asset value (see prioritisation).
- Test: install on representative systems and check key applications still work.
- Deploy in rings and verify with reports and rescans.
Examples of manual update commands you might use on single machines; at scale, use a management platform:
sudo apt update && sudo apt upgrade -y
sudo dnf upgrade --refresh -y
winget upgrade --all
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5Rollout rings and maintenance windows
Rings let you catch problems early while still moving quickly. Each ring waits a set time (for example, two or three days) before the next begins, and a problem in an early ring pauses the rollout. Servers usually patch in agreed maintenance windows, with clustered or load-balanced systems patched one node at a time to avoid downtime.
Emergencies and exceptions
When a flaw is being actively exploited, normal timelines are too slow. An emergency patch process should be agreed in advance: who can approve it, how much testing is acceptable, and how users are told. Internet-facing systems such as VPNs, firewalls and email gateways are often the first priority.
| Problem | Practical response |
|---|---|
| Vendor has no patch yet | Apply the vendor's workaround, restrict access, increase monitoring |
| Legacy system out of support | Isolate it, plan replacement, record a time-limited exception |
| Medical or industrial device | Follow the manufacturer's approved updates; segment and monitor |
| Patch broke an application | Roll back, report to vendor, add a temporary mitigation |
Measuring success
Measure patch compliance (the percentage of devices fully patched within the target time), mean time to patch by severity, and the number of devices not reporting at all. Some schemes set clear expectations; for example, the UK Cyber Essentials scheme expects high and critical security updates to be applied within 14 days of release.
Tip: a reboot is often part of the patch. Track "installed but pending restart" separately, because the vulnerability remains until the device restarts.
Practice
What is the purpose of deployment rings?
A VPN appliance flaw is being actively exploited and no patch exists yet. What should you do?
Why is "installed but pending restart" worth tracking separately?
Key takeaways
- Patching needs an inventory of all software, firmware and devices.
- Test patches, then deploy in rings with pauses between them.
- Agree an emergency process for actively exploited flaws.
- Isolate and record exceptions for systems that cannot be patched.
- Measure compliance, time to patch and pending reboots.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.