The 14-Day Patching Rule: What It Actually Says and How to Stay Compliant

When I review a failed Cyber Essentials submission, patching is nearly always in the top three reasons. Applicants read the 14-day rule, assume they are comfortably inside it because "Windows Update is on", and then discover during feedback that the rule covers a lot more than Windows, and the clock starts earlier than most people expect.

This guide is what I wish every applicant had read the day before they submitted. It explains what the NCSC actually requires under the current Cyber Essentials v3.3 question set, answers the questions that come up most often in the IASME portal clarifications, and shows you the evidence posture that passes an assessor review on the first pass.

The NCSC requirement, paraphrased in the language the questionnaire uses, is this: vulnerability fixes must be applied within 14 days of release when the vendor rates the issue critical/high risk, its CVSS v3 base score is at least 7, or the vendor supplies no vulnerability-severity details. These are independent triggers. The NCSC requirements, pages 17-18, include vendor-approved configuration changes and other fixes as well as patches.

Three things about that sentence catch people out.

First, it covers every in-scope device. Not just servers. Not just workstations. The scope includes laptops used by remote workers, office-based desktops, BYOD phones that access organisational email, routers and firewalls, network switches, printers that handle corporate documents, and any IoT device that touches the corporate network. If it is in your declared scope, it is inside the 14-day rule.

Second, the rule covers all software on those devices. Operating systems, applications, browsers, browser extensions, PDF readers, office productivity suites, runtimes like .NET and Java, and firmware. The question set specifically asks about third-party applications because assessors see repeated failures here.

Third, the triggers are independent. A lower vendor label does not override CVSS v3 7+, and absent vendor severity details also brings a vulnerability update into the window. Applying all updates within fourteen days is recommended, but not universally mandatory.

The clock starts on the date the vendor publishes the patch, not the date your vulnerability scanner flags it.

This is the single most common misunderstanding I see during feedback rounds. An applicant writes in the questionnaire that their scanner runs weekly and they patch "within 14 days of detection". The assessor then works back from the patch release date and the submission fails because the applicant gave themselves a second 14-day window on top of the one they were meant to be inside.

If a vendor ships a critical patch on the 1st of the month, your organisation needs the patch applied by the 15th - regardless of when you scanned, when your change control committee met, or whether the person who owns the patch cycle was on leave that week. The 14-day window is from release, full stop.

That has two practical implications. You need patch monitoring that tells you when vendors release, not just when scanners find. And you need a patch cadence quick enough to turn around critical updates within two weeks of vendor release, consistently, across every device class in your scope.

Not every update is inside the window. The question set asks specifically about critical and high-risk security updates. The way to map that to what vendors actually publish:

When in doubt, use the CVSS v3 base score as the source of truth. NIST publishes these in the NVD. If any CVE addressed by the patch is 7.0 or higher, the whole patch is inside the 14-day rule.

This is the second most common failure. Organisations have Windows Update running and assume that covers everything. It does not. Chrome, Firefox, Edge, Zoom, Teams, Slack, Adobe Reader, 7-Zip, Notepad++, TeamViewer, WinSCP, PuTTY - every one of them ships independent security updates, and every one of them is inside scope if it is installed on an in-scope device.

There are three workable positions an assessor will accept:

What does not work is "we rely on users to keep their own apps updated". Check the effective controls and deployed updates. User involvement alone is not an automatic failure regardless of actual compliance; automatic updates must be enabled where possible and required fixes applied on time.

A pattern I see often: an organisation has Chrome set to auto-update but has disabled auto-update on Firefox "because of an old extension compatibility issue" and forgotten to remediate. During the assessment that comes up as an explicit control failure because the browser exposed to the public internet is now outside the 14-day window.

The fourteen-day clock follows release of a qualifying vulnerability fix, including a vendor-approved configuration change, script or workaround. It is not limited to a conventional patch file.

Monitor vendor advisories and address exposed vulnerabilities promptly. Generic mitigations or a local fourteen-day-from-disclosure policy do not automatically satisfy the scheme; check whether the vendor approves the mechanism as a fix. Plus has separate vulnerability test criteria, so absence of a conventional patch is not a blanket assurance that an exploitable finding will pass.

This one is mostly a change management problem, not a technical one. The rule does not care where your users are. If a critical patch ships on 20 December and your organisation shuts down until 3 January, the patch still needs to be applied by 3 January - the 14-day window includes the break.

Practical patterns that work:

• Remote deployment via MDM (Intune, Kandji, Jamf, etc.) so devices pick up patches when they next come online, regardless of whether the user is present
• Forced restart schedules on power-on, so the device applies a pending patch the moment the user re-opens the laptop
• A designated on-call patch responder over holiday periods (it does not have to be a senior engineer - someone who can trigger a pre-approved deployment and read the rollout report is enough)
• Staggered shutdown policies so critical infrastructure (mail servers, VPN gateways, identity providers) has no scheduled downtime across holiday periods

The failure I see is organisations that interpret the 14-day rule as "14 working days". It is not. It is 14 calendar days, including weekends, bank holidays, and the break between Christmas and New Year.

If software is unsupported, remove it from in-scope devices or exclude it through a defined subset preventing all traffic to or from the internet. An ordinary VLAN, jump host, absence of personal data or documented business need is not that exclusion.

For supported software, apply a vendor-approved fix within the applicable window. A prescribed registry/configuration change can qualify; general firewall restrictions, monitoring or risk acceptance do not create a universal waiver.

Agree the actual scope and evidence with the certification body. Ordinary subsets may allow controlled communication, but unsupported-software exclusion has the stricter internet-disconnection condition.

The NCSC requirements expressly allow evidence to be required before certification. Your self-assessment answers must also be specific and internally consistent; prepare evidence of the actual controls rather than assuming it cannot be requested. The answers that pass first time tend to include:

• A named patch management tool - not "we use automation" but "Microsoft Intune with update rings configured as follows…"
• A stated patch cadence - weekly, bi-weekly, with a named owner
• A third-party application policy - either a named allow-list, a tool that handles third-party patching explicitly, or both
• A firmware patching approach - routers, switches and firewalls receive qualifying vendor-approved fixes within 14 days of release: vendor-rated high or critical, CVSS v3 score 7 or above, or unspecified severity
• A documented workaround process - for CVEs without patches
• An exception register - for devices that cannot be patched

For Cyber Essentials Plus, the assessor will sample devices during the technical audit and verify observed patch levels against what you claimed in the questionnaire. Inconsistencies here are a fail. If your questionnaire says all laptops are within 14 days of current Windows cumulative and the sample shows three laptops two cumulatives behind, that is the end of that audit.

If you are a small or mid-sized UK organisation without a dedicated patch team, this is the posture I most often see pass cleanly:

1. Operating systems. Intune or Microsoft Update for Business on all Windows devices, Apple MDM (Jamf, Kandji, or Intune) on all Macs, Ubuntu Landscape or equivalent on Linux. Deployment rings set so critical patches hit all devices within 7 days of release, giving you a 7-day buffer before the 14-day limit.

2. Browsers. Chrome and Edge allowed to auto-update, extensions explicitly allow-listed in the management console. Firefox either allowed to auto-update or removed from the allow-list. IE11 removed entirely.

3. Third-party applications. A defined allow-list. Every application on the allow-list is either (a) auto-updating, (b) managed via a tool that covers third-party patching, or (c) subject to a vendor-approved vulnerability fix applied within the window. Generic compensating controls are not a waiver.

4. Firmware. Router, firewall, and switch firmware reviewed monthly against vendor advisories, with any critical advisory applied within 14 days.

5. Evidence. A single document that lists the above, references the specific tools, names the owner of each area, and includes the last three dates critical patches were deployed.

That document supports preparation; certification depends on the actual controls, required fixes and assessor review.

Before you click submit, run five quick checks:

1. Pull a version audit on a sample of three devices. Are their versions supported and all qualifying vulnerability fixes applied within fourteen days of release?

2. Check your firewall or router's firmware version against the vendor's current release. Check actual support and qualifying fixes; firmware age or a quarterly cadence alone does not determine compliance.

3. Confirm your allow-list genuinely reflects what is installed. Run a discovery scan if you have to. Submissions fail when the policy says Chrome only and half the devices have Firefox.

4. Identify any legacy system you meant to exclude and write the exclusion down formally before the assessor asks.

5. Draft your patch management paragraph in the questionnaire with the tool name, cadence, owner, and exception process. Generic answers get feedback; specific answers get passes.

If you want me to look at your posture before you submit, Fig Group's free readiness checker runs through this section explicitly.

The 14-day rule is strict but it is not unreasonable. The failures I see are almost always specificity failures - applicants who know they patch but cannot describe the mechanism in a way an assessor can verify. Pick a tool, document the cadence, deal with third-party applications explicitly, and write down your legacy exceptions. Preparation helps identify gaps, but a one-hour exercise does not guarantee a pass or remove the need for feedback.

Check your readiness | View pricing | Talk to an assessor