The Cyber Essentials 14 day patching rule: which updates count and how to prove it

The NCSC's Cyber Essentials requirements for IT infrastructure (v3.2, April 2025) set the deadline in the patching section. In-scope software must be updated within 14 days of the update being released when the update fixes a vulnerability that the vendor describes as critical or high risk, that has a CVSS v3 base score of 7 or above, or that has no published severity information at all.

The clock starts at the vendor's release date, not the day your team notices the update or the day your managed service provider schedules it. A bundled update counts as a whole: if one fix inside it meets any of those three tests, the entire update falls under the 14-day deadline.

Three tests decide whether an update is mandatory within 14 days: the vendor's own wording (critical or high risk), a CVSS v3 base score of 7.0 or above, or a missing severity rating. The third catches many small-business tools, because some suppliers publish release notes that say 'security fixes' without grading them. Treat an unrated security fix as qualifying rather than arguing it down.

The rule is not a requirement to install every update within 14 days. The NCSC says applying all updates in that time is strongly recommended for better security but is not mandatory. A feature update or a low-severity fix can wait for your normal patching cycle, though automatic updates should be switched on wherever the product offers them.

The requirement covers software on every in-scope device and service: laptops, desktops, servers, mobile phones and tablets, firewalls, routers and cloud services. That includes operating systems, browsers, office applications, PDF readers, VPN clients and router or firewall firmware, not just Windows and macOS updates.

Software must also be licensed and supported. Anything the vendor no longer patches must either be removed or kept out of scope using a defined subset that blocks all traffic to and from the internet. Leaving an out-of-support Windows version in scope is a compliance failure in its own right, whatever your patching speed on other devices.

The NCSC requirements do not prescribe a tool or a record format, so what you need is evidence that links a release date to an install date for each in-scope device. For managed devices, an export from Microsoft Intune, Jamf or your MSP's remote management platform showing installed update names and install dates is the usual starting point. For firewalls and routers, the firmware version and a note of when you upgraded it.

Pair that export with the vendor's release date, taken from the security bulletin or release notes, and keep both in a simple patch log. Record the update name, the vendor severity or CVSS score, the release date, the install date and who applied it. One spreadsheet reviewed monthly is enough for a small business, provided an assessor can pick any device and trace a qualifying update from release to installation.

Under Cyber Essentials Plus, an assessor samples devices and scans them. According to the NCSC illustrative test specification, a sampled device fails the patching sub-test if a qualifying vulnerability is still present and the vendor patch had been available for more than 14 days before testing. The test looks at the real state of the device, not your policy document.

This is why a log alone is not enough. Laptops that stay offline for weeks, servers waiting for a maintenance window and phones that never restart are the usual failures. Check these devices a few days before testing, and confirm that updates needing a restart have actually completed the restart.

The cited requirements give no general extension and no alternative timetable. If a patch breaks a line-of-business application, or a device is offline, you have a compliance gap. Prioritise getting the update installed, and write down what happened, which devices were affected, when the update was released and the date you resolved it.

Do not treat a workaround as a substitute. The Plus test specification states that virtual patching is not a long-term compliance mechanism for legacy unsupported operating systems. If the underlying software no longer receives vendor patches, the fix is replacement or isolation from the internet, not a compensating control.