Skip to main content
Practical guideCyber Essentials5 min read

Cyber Essentials Patching: A Workflow for the 14-Day Deadline

Build a Cyber Essentials patching routine that covers new fixes, failed updates, restarts and laptops you can't reach before the deadline.

AI-assisted guidance from RightCyber. Sources checked on 16 September 2026.

BylineWritten by RightCyber · Published by RightCyber

PublicationPublished · Updated

Source statusReviewed 16 September 2026 · Review due 16 December 2026

At a glance

Count from the vendor's release date and check that each update finished. Leave time to fix failures and catch up with devices that are offline.

On this pageArticle contents

Share this article

LinkedInEmail

A report saying most devices are up to date can hide the one that needs attention. Imagine a small engineering consultancy with twelve laptops. Eleven report a successful update. The twelfth has been switched off in a cupboard for three weeks. Before someone takes it out and starts work, you need to know which fixes it's missing.

Your patching routine needs to cover every relevant device and application, including failed updates, restarts and machines you can't reach. The steps below are a suggested way to manage that work. The internal checkpoints are recommendations, not extra Cyber Essentials rules.

Know when the fourteen-day deadline applies

Under the NCSC's current requirements, you must apply fixes within fourteen days of release when the vendor rates the vulnerability critical or high risk, the CVSS v3 base score is at least seven, or the vendor gives no severity details. Applying every released update within fourteen days is recommended. It isn't mandatory for every update regardless of severity.

IASME's April 2026 announcement explains that the Danzell questions about timely fixes to operating systems, router and firewall firmware, and applications are automatic-fail questions. A strong answer elsewhere won't make up for missing this requirement.

The clock starts when the vendor releases the fix. Finding it late, raising a support ticket or waiting for the next maintenance meeting doesn't restart the fourteen days.

Work out who updates what

IASME's security update guidance covers operating systems, firmware, browsers and extensions, applications, anti-virus and virtualisation software. Check that your inventory covers all of these. Knowing that a laptop's operating system is current tells you nothing about its separate PDF editor.

For each product, write down who maintains it, how they hear about updates, how they install them and how they check the result. If you need a subscription to receive fixes, include the support entitlement in that record.

In our fictional consultancy, the IT provider might look after the laptops, the office manager might receive router notices and an engineering supplier might support a specialist application. Put those responsibilities in one place. Agree who covers each person before they go on holiday.

Check for new fixes each working day

Checking relevant vendor notices and management reports each working day is a useful routine. Give the person doing it a named backup. Enable automatic updates where possible, as the scheme requires, and keep checking that they work. IASME warns that some installations aren't complete until the device restarts.

For each relevant release, record:

  • the vendor notice and release date
  • the affected product and installed versions
  • the stated severity and required action
  • the affected devices or systems
  • the person responsible and the completion deadline

Follow the vendor's instructions for fixing the vulnerability. You may need to change a setting or take another specified action as well as install an update. IASME explains this in its guidance on vulnerability fixes.

Leave time to find and correct failures

Aim to finish routine updates well before day fourteen. For example, a team might assess a release on the first working day, run a short compatibility check soon afterwards and finish the main rollout during the first week. That leaves time to investigate failures, contact people who are away and check that everything finished.

This timetable is only an example. You may need to act faster if a vendor says attackers are already exploiting the vulnerability, or if a service is particularly exposed.

Where you need to test an update, choose a specific task. Can the updated laptop still open the engineering application and print a drawing? Record what you checked, what happened and the decision you made. An instruction to “test thoroughly” can use up the whole window if nobody agrees what a successful test looks like.

Before making changes that could interrupt work, agree how the team will restore service if something goes wrong. Tell people when the work will happen and whether they'll need to restart their devices.

Follow up every missing or failed update

Keep separate lists for “installed and checked”, “restart required”, “failed” and “not reporting”. A missing result needs investigating. Don't count it as a success.

For the laptop in the cupboard, agree how you'll check and update it before someone starts using it again. For a travelling colleague, find a time when they can connect and restart. If an application update keeps failing, ask someone to work with the vendor. Decide when to seek more help, leaving time before the final deadline.

If you miss the deadline, keep an accurate record of the dates, fix the problem and find out what went wrong. Accepting the risk internally doesn't change a scheme requirement. Take any unresolved technical or assessment questions to the relevant support provider and your Certification Body.

Record what actually finished

A short completion record should identify the system, the vendor reference, the installed version or confirmed setting, when the work finished and any remaining problems. Use a fresh device report or a recorded check to confirm the result. Sending an installer isn't enough to close the job.

Look for delays that keep coming back. If every round of updates stalls at the same unavailable laptop or unanswered supplier email, change that arrangement before the next release. You can find more preparation advice in our guide to how businesses run into Cyber Essentials problems.

Provenance

Sources reviewed

Reviewed 16 September 2026

Sources reviewed by RightCyber on 16 September 2026. A source’s classification describes where it came from; it is not a blanket claim about every source.

Disclaimer

Prepared with AI assistance using the primary sources linked here. RightCyber is independent and is not affiliated with or endorsed by IASME or the NCSC. This article offers general help with preparation. Follow the official scheme documents and your Certification Body's guidance when making assessment decisions. Certification isn't guaranteed.

Clarifications

Frequently asked questions

When does the fourteen-day update period start?
It starts when the vendor releases the relevant fix. Finding it later or opening a support ticket doesn't give you another fourteen days.
Is turning on automatic updates enough?
No. Check that the installation succeeded and whether the device still needs a restart. If a device has stopped reporting, find out why. A missing result doesn't tell you that the update worked.
What should an internal patching record contain?
Record the vendor release, affected systems, person responsible and deadline. Then add the checked result. Keep failed installations and missing devices on separate lists so someone follows them up.

Continue reading

Continue with a related article

Check for other common problems while you're preparing for Cyber Essentials.

Keep exploring

Browse the RightCyber Blog