IT explained · 7 min read
What is patch management? Process, rings and why it fails
Written for: IT managers and small teams building or fixing a patching routine, especially where devices are remote and rarely on the office network.
The patch cycle
In short
Patch management is the repeatable process of knowing what software you run, learning which updates matter, testing them on a small group, deploying them in waves, and confirming they actually applied. The last step is the one teams skip, which is why so many estates believe they are patched while a meaningful share of devices quietly are not.
Key takeaways
- Patch management is a cycle: inventory, assess, pilot, deploy in rings, verify. Not a monthly button press.
- Verification is the step that fails. Devices that were asleep, offline or mid-reboot silently miss the wave.
- Deployment rings let you catch a bad update on ten machines instead of four hundred.
- Internet-facing systems deserve a separate, faster track than staff laptops.
- Roaming devices need patching that works away from the corporate network, or they become the least patched machines you own.
The definition, and why it is a process
Patch management is the practice of keeping software current in a controlled way. The controlled part is what makes it a process rather than a task: applying every update immediately breaks things, and applying nothing leaves known vulnerabilities open for anyone who scans for them.
It covers more than the operating system. Browsers, runtimes, PDF readers, conferencing clients, database engines, firmware and network appliances all ship updates, and the vulnerabilities attackers exploit most often are in the widely installed third-party applications rather than in Windows itself.
The five stages
Every workable patching routine has the same shape, whether it runs from a full platform or a spreadsheet and a scheduled script.
- Inventory: what you actually run, including the software nobody remembers installing.
- Assess: which updates matter to you, based on severity, exposure and whether the flaw is being exploited now.
- Pilot: apply to a small, representative ring first and let it sit long enough for problems to show.
- Deploy: roll out in waves, with a maintenance window and a known rollback route.
- Verify: confirm the patch is present on each device and chase the ones that missed it.
Deployment rings, in practice
A ring is a group of devices that receives an update at a particular stage. Three rings are usually enough: a pilot of IT's own machines and a few tolerant volunteers, a broad ring of general staff, then a final ring of the machines that cannot be interrupted, such as servers, tills and clinical workstations.
The value is arithmetic. A bad update caught in a ten-machine pilot costs an afternoon. The same update pushed to four hundred machines at once costs a week and your credibility. Rings buy the time to notice, at the price of a slightly longer rollout.
Realistic timescales
Perfect currency is not the goal; a defensible and consistent schedule is. A common shape is 48 hours for critical patches on internet-facing systems, 7 to 14 days for critical patches on workstations, and monthly for everything else, with an emergency path for anything being actively exploited.
Write the targets down and report against them. A team that patches 95 per cent of workstations within fourteen days and can prove it is in a far stronger position than one that patches faster on average but cannot say what its coverage is.
Why patching programmes fail
Rarely because the deployment tool failed. Usually because of the gap between sent and applied. A laptop was closed during the window. A device needed a reboot the user kept deferring. A machine has not been on the corporate network for six weeks. An update installed but a dependent component did not, so the vulnerable file is still on disk.
That is why the verification step deserves its own attention and its own report. The useful question is not whether the patch was deployed but what percentage of devices now report the fixed version, and which specific devices do not.
Setting up a patching routine that holds
1. Build the inventory first
You cannot patch what you do not know about. Include third-party applications, firmware and network appliances, not just operating systems.
2. Split internet-facing from internal
Anything reachable from the internet gets a faster track with a shorter target, because exposure changes the risk entirely.
3. Define three rings
Pilot, broad and sensitive. Put IT's own machines in the pilot ring so problems land on people who can diagnose them.
4. Set written targets
For example: 48 hours critical on exposed systems, 14 days critical on workstations, monthly for the rest. Agree them with the business.
5. Handle the roaming devices explicitly
Patching that only works on the office network guarantees your remote laptops are the worst-patched machines you own.
6. Report coverage, not activity
Publish the percentage of devices confirmed on the fixed version, plus the named list of stragglers. Chase the list.
Common mistakes
- Measuring patches deployed rather than devices verified as patched.
- Patching operating systems while ignoring browsers, runtimes and PDF readers, where much of the real risk sits.
- Letting users defer reboots indefinitely, so the update is installed but not effective.
- Relying on a patching route that only works when the device is on the corporate network.
Frequently asked questions
- What is patch management in simple terms?
- The routine of finding out which software updates you need, testing them on a few machines, rolling them out in waves, and then confirming they actually applied everywhere.
- How often should you patch?
- A common and defensible schedule is 48 hours for critical patches on internet-facing systems, 7 to 14 days for critical patches on workstations, and monthly for everything else, with an emergency path for actively exploited flaws.
- What is the difference between patch management and vulnerability management?
- Vulnerability management finds and prioritises weaknesses, including ones with no patch available. Patch management is the delivery process that closes the subset fixed by an update.
- What are patch rings?
- Groups of devices that receive updates at different stages: a small pilot first, then general staff, then sensitive systems. Rings limit the damage of a bad update to a manageable number of machines.
- Why do patches fail to apply?
- Usually because the device was off, asleep, off-network or awaiting a reboot the user kept deferring. Sometimes because a dependency did not update, leaving the vulnerable component in place.
How this works in 247connect
Patching remote machines depends on being able to reach them reliably. 247connect gives operators managed access to devices wherever they are, so a deferred reboot or a straggler on the coverage report can be dealt with directly rather than waiting for the device to come back to the office.
More IT explainers
What is RDP?
RDP is Microsoft's Remote Desktop Protocol, built into Windows for remote sessions. How it works, what it is genuinely good at, why exposing it to the internet is dangerous, and where brokered remote support tools fit instead.
What is an endpoint?
An endpoint is any device that terminates a network connection and can be managed, monitored and attacked: laptops, desktops, servers, tablets, phones, tills and kiosks. What counts, what does not, and why the count matters commercially.
What is bandwidth?
Bandwidth is how much data a connection can carry at once, measured in megabits per second. It is not speed, and it is not the reason most remote sessions feel slow. What bandwidth is, how it differs from latency, and how much a remote session actually needs.