Patch management gets less attention than it deserves. It's not exciting — there's no incident to respond to, no attack to defend against in the moment. It's maintenance work that prevents problems rather than fixing them. In the hierarchy of things IT teams get credit for, it sits well below incident response and new system deployments.
Yet the data on cyberattacks consistently shows that a large proportion of successful intrusions exploit vulnerabilities for which patches have been available for months or years. The WannaCry ransomware attack in 2017 exploited a Windows vulnerability that Microsoft had patched two months earlier. Thousands of organisations that had delayed applying the patch were compromised.
What Patch Management Actually Involves
Patching isn't just running Windows Update. A comprehensive patch management programme covers:
Operating system patches — Windows and macOS release security updates on a regular cycle (Microsoft's Patch Tuesday is the second Tuesday of each month). High-priority security patches should be deployed within 14 days of release — this is a Cyber Essentials requirement.
Third-party application patches — browsers, Office applications, PDF readers, Java, and other commonly installed software are frequent attack vectors. These require separate management, as Windows Update doesn't cover most third-party applications.
Server and infrastructure patches — servers, network devices, firewalls and switches all need regular patching. Network device firmware is often left unpatched for years in small business environments.
End-of-life management — software and operating systems that have reached end-of-life no longer receive patches, regardless of how many vulnerabilities are discovered. Identifying and replacing or isolating end-of-life systems is part of patch management.
The Testing Problem
In enterprise environments, patches are tested in a staging environment before broad deployment to avoid the small but real risk of a patch causing application compatibility issues. In small business environments, this level of process usually isn't practical.
The pragmatic approach: apply high-risk security patches quickly, test in a small pilot group first if possible, and maintain good backup so you can recover quickly if a patch causes a problem. The risk of not patching a critical vulnerability is higher than the risk of a patch causing an issue in the vast majority of cases.
Measuring Compliance
Patch compliance — the percentage of devices that are fully patched against known critical vulnerabilities — should be a metric your IT provider reports to you regularly. "We have patching enabled" is not a useful answer. "92% of devices are fully patched within 14 days of release, with the remaining 8% being tracked" is.
Remote and home-working devices are often poorly patched because they're not regularly connected to the corporate network. If you have staff who work primarily from home on company devices, ensure your patching solution works for them when they're off the office network.
The Resourcing Reality
Proper patch management requires time — testing, scheduling deployment windows, monitoring compliance, handling exceptions. In many small businesses, this is the first thing to get deprioritised when the IT team (or IT support provider) is busy.
If your current IT arrangement doesn't include explicit patch management commitments — specific timescales and regular compliance reporting — it's worth asking directly how patching is handled. The answer tells you a lot about the quality of the overall service.