How Often Should UK Businesses Patch Their Software?

Last updated: June 2026

Patching is the least glamorous and most reliably ignored control in security. It is also one of the most exploited gaps attackers use to get in. This guide sets out what "often enough" actually means for a UK business, what the standards require, and how a managed cybersecurity provider keeps the work from slipping. The figures here come from the NCSC and the UK Government's annual breaches survey — not vendor marketing.

How often should you patch software in practice?

Patch on a fixed cadence, not when someone remembers. Critical and high-severity vulnerabilities should be remediated within 24 hours where a fix exists; routine operating-system and application updates within 14 days of release. Anything that cannot meet those windows needs a documented exception and a compensating control.

The 14-day figure is not arbitrary. It is the maximum the Cyber Essentials scheme allows for applying patches that fix vulnerabilities rated high or critical (CVSS 7 and above). Miss it on an in-scope system and you fail certification — and certification is increasingly a condition of winning public-sector and enterprise contracts.

In practice, most breaches do not exploit zero-days. They exploit known flaws that had a patch available for weeks or months. The NCSC is blunt about this: keeping software up to date is one of its core vulnerability management recommendations precisely because the exploited bugs are usually old news.

What patching timeframe applies to each severity?

Treat severity as the dial that sets your deadline. A critical remote-code-execution flaw on an internet-facing server is not the same risk as a low-severity bug in an internal tool, and your patching SLA should reflect that. The table below is the cadence AMVIA runs for managed endpoints.

The point of formalising this is removing the judgement call from a busy Tuesday. When the cadence is written down and automated, "we'll get to it" stops being a security strategy.

Why does the 14-day patching window matter?

Because the gap between a patch being released and you applying it is the exact window attackers race to exploit. Once a vendor publishes a fix, they also publish — implicitly — what was broken. Within days, working exploits for that flaw circulate. Every unpatched day after that is borrowed time.

The scale of the problem is well documented. "43% of UK businesses experienced a breach or attack" in the last year (DSIT Cyber Security Breaches Survey 2025). Unpatched and out-of-date software remains one of the most common entry points behind those incidents, alongside phishing. Closing the patch gap removes a whole category of opportunistic attack.

For regulated firms — and anyone carrying cyber insurance — timely patching is also a contractual expectation. Insurers increasingly ask for evidence of a patch-management process before they will pay out. "We meant to" is not evidence.

What should you do when you can't patch in time?

When a patch cannot be applied — usually because it breaks a line-of-business application — isolate the system from the wider network or wrap it in additional compensating controls until you can. Software that has reached end-of-life and no longer receives patches at all must be removed from scope entirely, not nursed along.

This is where most patch programmes quietly fail. A single legacy application that "can't be touched" becomes a permanent hole, and over time more systems get pinned to it. The disciplined approach is to treat every unpatchable system as a tracked, time-boxed risk with an owner and an exit plan — not a fixture.

Compensating controls worth deploying around a system you cannot patch include:

• Network segmentation so a compromise can't move laterally
• Restricting inbound and outbound traffic to the bare minimum
• Endpoint detection and response to catch exploitation attempts in real time
• Removing the system from internet exposure entirely where possible
• 24/7 monitoring so any anomaly is seen immediately

None of these replace patching. They buy you time and visibility while you engineer the legacy dependency out.

Should you automate patching or do it manually?

Automate the routine, supervise the sensitive. Automated patching is strongly recommended for operating systems and standard applications — it removes human delay and keeps you inside the 14-day window without anyone tracking it on a spreadsheet. Critical line-of-business applications keep manual oversight, with patches tested before deployment.

A good managed IT and security provider runs both lanes at once: automated rollout for the bulk of your estate, scheduled and tested deployment for the handful of systems where an untested update could halt operations. That split is the practical answer to the false choice of "automate everything and risk an outage" versus "do it by hand and fall behind".

Automation also reinforces other controls. "Only 40% of UK businesses have two-factor authentication enabled" (DSIT Cyber Security Breaches Survey 2025) — the same management gap that leaves software unpatched usually leaves MFA unconfigured. Automating security baselines closes both consistently, instead of relying on someone remembering.

How does patching fit into a wider security strategy?

Patching is one layer, not a strategy. It belongs inside a broader vulnerability management programme that continuously scans your estate, prioritises what to fix, and feeds detections to a monitoring team. Patching alone tells you nothing about what slipped through before the fix landed.

That is why AMVIA wraps patch management inside a single accountable service. Continuous scanning finds the gaps, automated patching closes the routine ones, and our in-house SOC monitors for exploitation of anything still open. When a critical flaw is actively exploited in the wild, our managed detection and response team is watching for it on your endpoints while the patch is being deployed — not after.

One provider. Security-first. Microsoft-certified. The reason to consolidate patching, monitoring and response under one roof is simple: gaps live in the handoffs between vendors, and a single accountable team has nowhere to pass the blame.