Patch management software: what to look for and how to run the process

Patch management software discovers the devices and applications an organisation runs, identifies missing security and functional updates, and deploys them in controlled waves. Every serious breach report contains at least one system that was missing a patch published months earlier — not because nobody had the tool, but because nobody owned the schedule, the exceptions, or the servers that could not be rebooted. Patch management software solves the mechanics; the process around it decides whether patching actually happens.

What patch management software should do

• Inventory every endpoint and server automatically, including machines that rarely connect.
• Detect missing patches for the operating system and for third-party applications, which is where most gaps sit.
• Group devices into rings — test, pilot, broad — so updates are validated before reaching everyone.
• Schedule deployment windows, with maintenance windows for servers and forced reboots where permitted.
• Report compliance: percentage patched within the target window, by group and by severity.
• Track exceptions with an owner, a reason and an expiry date.
• Roll back a bad update, or at least identify quickly which devices received it.

The process that makes the tool work

1. Set target timescales by severity — for example critical within 14 days, high within 30, others at the next cycle.
2. Assign an owner per platform: workstations, servers, network devices, mobile, and the applications nobody claims.
3. Patch a test ring first, then pilot, then the rest, with a defined pause if something breaks.
4. Review the exception list monthly, because exceptions are where risk accumulates quietly.
5. Report coverage to management as a percentage against target, not as a count of patches installed.
6. Handle the machines the tool never sees — long-absent laptops and isolated systems — as a named task, not a rounding error.

The devices missing from the report matter more than the ones failing in it. An agent that stopped reporting six weeks ago looks like compliance, because a device with no findings appears clean.

Why patching fails

Almost never because the software cannot deploy an update. It fails because a critical application is only certified on an old version, because a server cannot be rebooted without approval nobody wants to give, because third-party applications are not in scope, or because the exception granted for one quarter became permanent. Each of those is a decision, not a technical limit, which is why patch compliance belongs on the risk register with a named owner rather than in the IT team's private backlog.

Ettex Records can hold the parts the tooling does not: the exception register with owners and expiry dates, the list of systems with special handling, and a monthly compliance figure per platform. Keeping that alongside the asset inventory means the awkward question — which devices are not covered at all — has an answer.