The simplest security control, and the most neglected.
Every piece of software you use has vulnerabilities. That is not a criticism of the vendors who build it. It is the reality of modern software development, where millions of lines of code interact with hardware, networks, other applications, and the unpredictable behaviour of human users. Vulnerabilities are discovered continuously, and patches are the mechanism by which they are fixed. Patching is not optional maintenance. It is a fundamental security control.
And yet, of all the security controls available to an organisation, patch management is the one most likely to be neglected. Not because it is difficult, but because it is unglamorous. Nobody gets promoted for keeping Windows up to date. Nobody wins an award for applying firmware updates to a router. The work is repetitive, often invisible, and only noticed when it goes wrong. This is precisely why it is so dangerous to ignore. Attackers know that patching is the control most likely to have gaps, and they exploit those gaps relentlessly.
This guide is a practical, plain-language walkthrough of how to build a patching process that works. Not a theoretical framework, not a compliance checklist, but a real approach that balances security with the operational reality of running a business. Because the goal is not just to patch. It is to patch consistently, reliably, and without disrupting the people who depend on your systems every day.
The 14-day rule
The Cyber Essentials scheme sets a clear, non-negotiable standard for patch management. Understanding this requirement is the foundation for building a process that keeps you compliant and secure.
14 days from release
Under Cyber Essentials, all critical and high-risk security patches must be applied within 14 calendar days of release by the vendor. This applies to operating systems, applications, firmware, and any other software in scope. The clock starts when the vendor publishes the patch, not when your IT team becomes aware of it. Ignorance is not a defence. If Microsoft releases a critical patch on Patch Tuesday and you have not applied it within two weeks, you are non-compliant.
The exploitation window
When a vendor releases a patch, they publish details of what was fixed. Attackers reverse-engineer these patches to understand the vulnerability and build exploits. This process, known as patch diffing, can happen within hours. The 14-day window is not arbitrary. It reflects the reality that exploitation of newly disclosed vulnerabilities is measured in days, not weeks. Research consistently shows that the majority of exploits for patched vulnerabilities appear within the first week of disclosure. Every day beyond that window increases your exposure exponentially.
Understanding patch categories
Not all patches are created equal. Understanding the difference between patch types is essential for building a process that treats urgent fixes with the speed they deserve while managing less critical changes with appropriate caution. The categories below reflect how most major vendors classify their releases, and how your patching process should prioritise them.
Critical and security patches
These are the patches that address actively exploited vulnerabilities. When a vendor releases a critical patch, it means attackers are already using the flaw in the wild. Every day you delay is a day your systems are exposed to a known, documented attack vector. Under the Cyber Essentials scheme, critical and high-risk patches must be applied within 14 days of release. That is not a suggestion. It is a compliance requirement, and it is the single most common reason organisations fail their assessment. The good news is that most operating systems now handle these automatically if you let them.
Important patches
Important patches fix security vulnerabilities that are not yet being actively exploited but have been publicly disclosed. The window here is slightly wider, typically 30 days, but do not confuse ‘wider’ with ‘optional.’ Public disclosure means the vulnerability is documented. Exploit code may already exist on GitHub. Threat actors monitor patch releases precisely because they reveal what was broken, and they work backwards from the fix to build the attack. This is known as ‘patch diffing,’ and it happens faster than most organisations realise.
Feature updates
Feature updates introduce new functionality, interface changes, or platform improvements. They are not security-critical, which means you have more latitude in how and when you deploy them. This is where deferral policies earn their keep. Feature updates can introduce compatibility issues with line-of-business applications, change user workflows, or occasionally break things in unexpected ways. A measured rollout, starting with a pilot group before wider deployment, is standard practice. But ‘deferred’ should never mean ‘ignored.’ Falling too far behind on feature updates can leave you on an unsupported branch.
“Patching is not a project. It is a process. The organisations that get it right are the ones that treat it like payroll: it happens on schedule, it is verified, and nobody has to be reminded.”
A practical approach to patching
Theory is straightforward. Execution is where organisations struggle. The following steps represent a proven, practical approach to patch management that works for businesses of all sizes. Each step builds on the last, creating a process that is repeatable, verifiable, and sustainable over the long term.
Enable automatic updates everywhere
For the vast majority of SMEs, automatic updates are the right default. Windows Update, macOS Software Update, and ChromeOS all handle security patches automatically when configured correctly. The key is ensuring that updates are set to install outside business hours, that devices are left powered on overnight at least once a week, and that your MDM or Intune policies enforce this configuration rather than leaving it to individual users. A device that is always asleep when updates try to install is, for practical purposes, an unpatched device.
Use deferral policies for feature updates
Feature updates should be deferred by 30 to 90 days. This lets the early adopters across millions of organisations worldwide discover the bugs first. Microsoft, Apple, and Google all release follow-up patches in the weeks after a major feature update that address the issues discovered in broad deployment. By deferring, you benefit from this real-world testing without bearing the cost. Security patches, however, should never be deferred. The 14-day window already provides a buffer. Adding an artificial deferral on top of that pushes you outside compliance.
Establish a pilot group
Before rolling any significant update to your entire organisation, deploy it to a small pilot group first. This is typically the IT team plus a handful of volunteers from different departments who use different applications and workflows. Give the pilot group five to seven working days. If nothing breaks, if no line-of-business applications fail, if no printers stop working, then roll the update to everyone else. This approach catches the edge cases that lab testing misses, because real users do unpredictable things with real systems.
Patch third-party applications
Operating system updates get the headlines, but third-party applications are often the bigger risk. Browsers, PDF readers, Java, .NET runtimes, Zoom, Slack, Adobe Creative Cloud: all of these receive regular security patches, and all of them are in scope for Cyber Essentials. Tools like Microsoft Intune, Ninite Pro, Patch My PC, or PDQ Deploy can automate third-party patching and provide reporting to prove compliance. Without automation, third-party patching is a manual, error-prone process that inevitably falls behind.
Monitor and report on compliance
Deploying patches is only half the job. You also need to verify that they installed successfully. Updates fail silently more often than you would expect: insufficient disk space, a pending restart that never happens, a conflicting application that blocks the installer. Your MDM or endpoint management platform should give you a dashboard showing patch compliance across your entire fleet. If a device falls behind, you need to know about it before the assessor does. Weekly compliance checks are the minimum standard.
Tools and automation
Manual patching does not scale. Even a 20-person organisation with a mix of Windows and Mac devices, plus phones and tablets, has enough endpoints to make manual tracking impractical. Automation is not about convenience. It is about reliability.
The right tool depends on your environment, your existing technology stack, and whether you manage IT in-house or through a partner. Here are the main options worth evaluating.
Microsoft Intune
The natural choice for organisations already using Microsoft 365. Intune manages OS updates, enforces compliance policies, and provides detailed reporting across Windows, macOS, iOS, and Android. It handles both Microsoft and third-party application updates when paired with tools like Patch My PC or the Intune Win32 app deployment model. For most SMEs in the Microsoft ecosystem, Intune is the single pane of glass for device and patch management.
Windows Server Update Services (WSUS)
A free, on-premises solution for managing Windows updates across a network. WSUS gives you granular control over which updates are approved, which are deferred, and which are declined. It is more hands-on than Intune and requires a server to host it, but for organisations that want direct control over their update pipeline without a cloud dependency, it remains a solid option. It does not manage third-party applications natively.
Third-party patching platforms
Tools like Ninite Pro, Patch My PC, PDQ Deploy, and Automox specialise in patching the applications that operating system updaters miss. They maintain catalogues of hundreds of common applications and automate the download, testing, and deployment of updates. For organisations with a diverse software estate, a dedicated third-party patching tool is the difference between compliance and guesswork.
RMM platforms
Remote Monitoring and Management tools like ConnectWise Automate, Datto RMM, and NinjaOne combine patch management with broader endpoint monitoring. These are the tools that managed service providers use to keep client environments patched and compliant. They provide automated patching schedules, compliance dashboards, and alerting when devices fall out of compliance. If you work with an MSP, your patching is likely handled through one of these platforms.
Common mistakes to avoid
We have worked with hundreds of organisations on their security posture, and the same patching mistakes appear with remarkable consistency. None of them are inevitable. All of them are avoidable with the right process, the right tools, and a clear understanding of what ‘good’ looks like.
Deferring everything indefinitely
This is the most common and most dangerous mistake. Some IT teams, having been burned by a bad update in the past, set deferral policies on everything, including security patches. The logic is understandable: ‘we will test it first.’ But testing never happens. The deferral becomes permanent. Weeks turn into months. Devices fall behind by multiple patch cycles. When a critical vulnerability is announced, they are exposed not just to the new threat but to every unpatched vulnerability accumulated in the interim. Deferral is a tool for feature updates. It is not a substitute for a patching process.
Patching only when something breaks
Reactive patching is not patching. It is incident response. If you only update systems after a problem has already occurred, you are treating the symptoms rather than preventing the disease. The entire point of patch management is to close vulnerabilities before they are exploited. The organisations that get breached are rarely the ones who were one patch behind. They are the ones who had no process at all, where updates accumulated silently until the attack surface became indefensible.
Forgetting third-party software
Windows is patched. macOS is patched. Job done? Not remotely. The applications running on those operating systems are independent attack surfaces. An unpatched browser, a legacy version of Adobe Reader, an outdated Java runtime: these are all entry points. In fact, third-party application vulnerabilities are among the most commonly exploited in real-world attacks, precisely because organisations patch the OS and forget everything else. If it runs on your devices and it connects to a network, it needs to be in your patching scope.
Not monitoring for failed updates
You pushed the update. The policy says it should install. But did it? On every device? Without a reporting mechanism, you are relying on faith. Updates fail for dozens of reasons: disk space, network timeouts, conflicting software, user intervention, devices that were offline during the deployment window. An endpoint management platform with compliance reporting is not a luxury. It is the only way to know, with confidence, that your fleet is actually patched. The Cyber Essentials assessor will ask for evidence. ‘We pushed it out’ is not evidence. ‘Here is the compliance dashboard showing 100% deployment’ is.
Ignoring firmware and network devices
Routers, switches, firewalls, access points, printers, NAS devices: all of these run firmware, and all of it needs updating. Network equipment is a particularly attractive target for attackers because it sits at the boundary of your environment and is rarely monitored. A compromised router gives an attacker visibility into all traffic passing through it. Firmware updates are less frequent than software patches, but they are no less important. Include network devices in your asset inventory and check for firmware updates quarterly at minimum.
Running unsupported software
Software that no longer receives security updates cannot be patched, by definition. It will fail a Cyber Essentials assessment, and it presents a permanent, growing risk to your organisation. Windows 10 reached end of support in October 2025. Older versions of PHP, Java, and .NET Framework are well past their support dates. That legacy line-of-business application that only runs on Windows 8.1 needs to be replaced, virtualised, or isolated on a network segment with no internet access. There is no patching strategy for software the vendor has abandoned.
“The real cost of falling behind on patches is not the patch itself. It is the incident that follows: the forensic investigation, the regulatory notification, the lost client trust, the weeks of recovery. All of it avoidable.”
The real cost of falling behind
The financial argument for patching is overwhelming, yet it is often ignored because the cost of not patching is invisible until it materialises. A breach caused by an unpatched vulnerability triggers a cascade of expenses: incident response, forensic analysis, legal counsel, regulatory notification under UK GDPR, potential fines from the ICO, and the operational cost of rebuilding compromised systems. For an SME, the average cost of a cyber incident now exceeds £15,000, and that figure climbs rapidly when sensitive data is involved.
Beyond the direct financial impact, there is reputational damage that is harder to quantify but no less real. Clients expect their suppliers and partners to maintain basic security hygiene. A breach caused by a vulnerability that had a patch available for months sends a clear signal: this organisation does not take security seriously. Contract renewals become difficult. Tender responses require explaining the incident. Cyber insurance premiums increase, if coverage is renewed at all. Insurers are increasingly scrutinising patching practices, and a claim arising from an unpatched known vulnerability may be denied entirely.
Then there is the operational disruption. Recovering from a ransomware attack takes an average of three to four weeks for an SME. During that time, productivity drops, staff are diverted to recovery efforts, and clients experience service degradation. Compare that to the cost of patching: a few hours per month of IT time, a modest investment in tooling, and the occasional inconvenience of a system restart. The arithmetic is not complicated.
Why it matters
Patch management is one of the highest-return security investments an organisation can make. The numbers are clear, and they reinforce what every security professional already knows: the basics matter more than the advanced tooling.
of breaches involve a vulnerability for which a patch was available but not applied
the maximum window for critical patches under Cyber Essentials compliance
average SME recovery time after a ransomware incident from an unpatched system
Building a sustainable process
The organisations that excel at patch management are not the ones with the biggest IT budgets. They are the ones that have built patching into their operational rhythm. It is scheduled, automated where possible, monitored for exceptions, and reviewed regularly. It does not depend on a single person remembering to check for updates. It does not rely on users clicking “remind me later” and eventually accepting the update.
Start with your asset inventory. You cannot patch what you do not know about. List every device, every operating system, every application. Then assign ownership: who is responsible for ensuring each category of asset is patched? For most SMEs, this is the IT team or the managed service provider. But ownership must be explicit, documented, and accountable.
Define your patching schedule. Security patches should be applied automatically within the 14-day compliance window. Feature updates should follow a deferred schedule with pilot testing. Firmware updates should be reviewed quarterly. Third-party applications should be included in your automated patching scope or reviewed monthly at minimum. Document this schedule. Share it with your team. Review compliance against it weekly.
Finally, plan for exceptions. There will always be a device that cannot be restarted during business hours, a legacy application that breaks after an update, a remote worker whose laptop has not connected to the management platform in three weeks. Your process needs to account for these exceptions, flag them, and resolve them before they become permanent gaps. A patching process that works 95% of the time is not a patching process. It is a risk with a five percent probability.
Need help with patch management?
We manage patching for organisations across the UK as part of our managed IT service. That includes OS updates, third-party application patching, firmware management, compliance reporting, and the ongoing monitoring that ensures nothing falls through the cracks. If you are handling patching in-house and struggling to stay on top of it, we can help.
Whether you need a full managed service or a one-off review of your current patching process, a conversation with our team will give you clarity on where you stand and what needs to change.