Cyber Essentials 4: support and patching within the real deadline

Count software, not just computers

Bring the reconciled inventory and configuration groups. Add installed operating systems, browsers, office applications, remote-support tools, network-device firmware and other in-scope software. Record exact versions and support arrangements. “Windows” or “the latest available on this laptop” is not precise enough to establish vendor support.

The v3.3 requirements call for licensed, supported software. An unsupported item must be removed or meet the scheme's isolation conditions, including preventing traffic to and from the internet for the relevant isolated subset. An accepted business risk is not a replacement for that requirement. Verify the particular support entitlement and edition rather than relying on a product-family date.

Use the scheme's update clock

Required security fixes must be applied within 14 days of release when the vendor rates them critical or high, when the CVSS v3 base score is at least 7, or when severity information is not provided. A bundle containing a qualifying fix needs the same treatment. The clock starts at release, not when IT notices the update or opens a ticket.

Applying every update within 14 days is a useful recommendation in the requirements, but do not describe that broader recommendation as the mandatory severity rule. Conversely, an update with no severity information is not automatically low priority. Capture the advisory or release note you used to decide its treatment.

An illustrative release on 2 September gives a 14-day target of 16 September. Set your internal completion target earlier to leave room for offline devices and failed installations. This is a planning example, not advice to wait until the last day. Confirm the precise release timing for the actual update when a boundary is close.

Make monthly maintenance compatible with short deadlines

A monthly window alone cannot guarantee a 14-day deadline. Keep the normal window for predictable work, but provide an exception route for fixes that cannot wait. The business owner should agree how an urgent change is approved, tested and communicated before an urgent release arrives.

Use staged deployment: a small relevant pilot, checks of critical workflows, then wider rollout with monitored failures. Keep pilot duration proportionate to the remaining deadline. A two-week pilot consumes the whole allowance. If the pilot finds a serious issue, escalate promptly with replacement, mitigation and assessor advice; do not quietly reset the release date.

Automatic updating where possible reduces handling, but verify its effect. Some installers require a reboot, some applications update only when opened, and offline devices may never receive the job. Track installation and effective version, not just “deployment sent”. A device pending reboot may still be running vulnerable code.

Work the denominator

Merefield's fictional console reports 45 of 48 computers updated. That is 93.75%, which may sound reassuring while three devices remain unresolved. One is offline, one failed installation and one missed the application deployment group. Each needs its own action. Do not round the dashboard to “compliant” or remove the offline device from the denominator because it is inconvenient.

A device returning from long leave needs a controlled path to regain normal access. Agree how it receives updates and how compliance is checked before it resumes ordinary work. Where technical access restrictions are used, test the intended recovery path so you do not create an unrecoverable remote device.

Give the MSP an outcome to deliver

Ask for a report covering the actual scope, vendor release dates, qualifying severity, installation status and failures. An invoice saying “patch management” does not show that a particular application was included. Clarify whether the contract covers third-party applications, firmware, Macs and cloud workloads as well as Windows updates.

Update record template — suggested fields:
Asset / software / installed version
Vendor advisory and release date
Severity basis and required completion date
Deployment group and change reference
Installation result / reboot status / effective version
Unresolved reason / named owner / escalation date
Verification method and timestamp

Use the record to spot a process failure across the population. If an old browser survives because it was installed per user, updating one sampled computer leaves the mechanism unchanged. Look for every instance and correct the deployment method. This is especially important before Plus, where missing updates can lead to further sampling.

Readiness exercise

Select one recent qualifying update and reconstruct its journey from vendor release to every applicable device. Explain exclusions, failures and the last verification time. Then select an application outside the operating-system updater and repeat the exercise. Keep unsupported software as a separate blocker rather than hiding it in update percentages.

Finish with a support register, a working urgent-update route and evidence that the process reaches the entire population. Part 5 addresses accounts and MFA, including the cloud services that endpoint patching cannot protect on its own.

Check your understanding