Cyber Essentials gives you 14 days to apply updates. Most businesses take much longer
Cyber Essentials requires software and security updates to be applied within 14 days of release — here is why that deadline exists and how to actually meet it.
Here's a scenario that plays out often enough to be a pattern, not a one-off: a software vendor releases a security patch on a Tuesday, fixing a vulnerability that's already being actively exploited. The patch notes are public, which means the details of the vulnerability are public too, including what it affects and how an attacker might use it. A business running the unpatched version has a window to fix it before someone decides to try. That window is short. Attackers read patch notes too, and the gap between a patch releasing and exploitation attempts against unpatched systems is often measured in days, sometimes hours.
Cyber Essentials sets a specific, concrete requirement under CE5 Patch Management: do you apply software and security updates within 14 days of release? The 14-day figure isn't arbitrary. It reflects the realistic window between a patch becoming available and the point at which running unpatched software becomes genuinely indefensible.
Why 14 days is the standard
When a security patch releases, it typically comes with enough information for security researchers, and by extension attackers, to understand what the underlying vulnerability is and how it might be exploited. The longer a business takes to apply the patch, the longer they're running software with a publicly documented weakness. Fourteen days is Cyber Essentials' line in the sand: within that window, running unpatched software is an accepted short-term risk while updates are tested and deployed. Beyond it, the risk becomes something closer to a deliberate choice.
For critical vulnerabilities, the same 14-day rule applies, though in practice a genuinely critical patch to widely-used software warrants moving faster than the maximum window allows.
Why patching within 14 days is harder than it sounds
The difficulty isn't usually awareness. Most businesses know updates exist. The problem is that applying updates consistently, to every device, within a defined window, across every piece of software in use, requires more deliberate infrastructure than most small businesses have set up.
Updates interrupt things. Staff postpone restarts. Some software requires manual updating rather than automatic. A piece of software nobody uses much sits quietly on two laptops and doesn't get updated because it's not on anyone's radar. A month later those two laptops are running a version with a known vulnerability, and nobody noticed because the software wasn't important enough to track carefully.
The 14-day clock runs from when the update is released, not from when someone in the business happens to notice it exists.
What a practical patch management process looks like
For a small business without a dedicated IT team, the most realistic approach is enabling automatic updates wherever the software allows it, and building a short, regular check into someone's routine for anything that doesn't update itself. Once a week, someone opens the systems that need manual attention and confirms they're current. That's often enough to stay inside 14 days without needing specialist tooling.
For businesses with more devices or more software to manage, a centralised device management platform makes this significantly easier, providing visibility into what's running on every device and flagging anything that's fallen behind. Without that visibility, it's difficult to confirm compliance rather than just assuming it.
The scope here is broader than most people initially assume: operating systems, browsers, office software, plugins, server software if applicable, and any third-party tools installed on company devices all fall within the patching requirement. If it runs on a device and it has an update, it counts.
Frequently asked questions
Does the 14-day rule apply to every update, or just security patches? Cyber Essentials focuses specifically on security updates and patches fixing known vulnerabilities; general feature updates without a security component are less directly in scope, though keeping software generally current is good practice regardless.
What if an update breaks something important in our business software? Testing in a non-production environment first is sensible where possible; if a patch genuinely can't be applied without breaking critical functionality, document why and have a plan for the affected system, as assessors may ask about exceptions.
Does this apply to software on personal devices used for work? Yes, if a personal device accesses company data under a bring-your-own-device arrangement, keeping its software patched within the same window is part of what that arrangement should require.
How do we track which updates have been applied across multiple devices? Centralised endpoint management tools provide this visibility automatically; for smaller setups without those tools, a short manual checklist run weekly is the most straightforward alternative.
What counts as the release date for the 14-day clock? It runs from when the vendor publicly releases the update, not from when you become aware of it, so staying current with update releases for the software you use is itself part of the requirement.
Run a free scan of your domain and your CE Readiness checklist will walk through this and the final CE5 Patch Management question, ready before your assessor asks: olimpio.io/free-scan