SMEs After PHP2Shell: Building a Patch Process That Beats the 14-Day Deadline

6 hours ago

3 min read

Most SMEs that hold Cyber Essentials have a patching policy. Fewer have a patching process that would have coped with PHP2Shell, the two critical PHP flaws fixed on 21 October 2026 and attacked almost straight away. The difference showed this week: some businesses had their websites and portals updated within hours, while others were still trying to work out who was responsible.

The story itself is covered in our main article, PHP2Shell and the Cyber Essentials 14-day patching rule. This piece is a blueprint for the process behind the policy.

Part 1: Know what you've got

You can't patch what you don't know about. Build, or refresh, a simple register with four columns: the system, what it runs on, who updates it and how you find out about updates.

Include the obvious (laptops, servers, Microsoft 365) and the easily forgotten: the website, customer portals, the NAS, firewalls and routers, phone systems and any appliance with a web interface. The NCSC points out that many products bundle PHP inside them, and highlights an NCSC-NL inventory of affected software. The "who updates it" column is the one that matters on the day.

Part 2: Make updating the default

The NCSC's advice for coping with the coming vulnerability patch wave is to update by default: switch on automatic updates wherever they exist, including on embedded devices, and keep manual patching for the systems that genuinely need it. Cyber Essentials v3.3 asks for the same thing: automatic updates enabled where possible.

For everything that can't update itself, set a weekly rhythm. A fixed slot each week, for example, means high and critical updates are never more than 7 days old, comfortably inside the scheme's 14-day maximum.

Part 3: Have an emergency lane

PHP2Shell is exactly the case that a weekly rhythm doesn't cover. When a critical flaw is under active attack on something internet-facing, the NCSC's guidance on responding to active exploitation says to update within 24 hours, and its advice for PHP2Shell was to consider taking systems offline if they couldn't be fixed quickly.

An emergency lane needs three things agreed in advance:

A trigger. For example: a vendor or NCSC alert describing a critical flaw being exploited in something you run.
An owner. One named person, plus a deputy, who can approve an out-of-hours change.
A fallback. Permission to take a website or portal offline, and a way to keep customers informed while it is.

Part 4: Hold your suppliers to the same standard

If an agency hosts your website or an MSP manages your servers, your process depends on theirs. Ask them what their emergency lane looks like and get their commitment in writing. The NCSC recommends making critical suppliers contractually responsible for fixing exploited, internet-facing vulnerabilities quickly.

Part 5: Keep the evidence

A short log with the update, the release date and the date you applied it turns a stressful week into an easy Cyber Essentials renewal. Our guide to meeting the 14-day patching rule covers what to check across devices and software.

The targets we recommend

14 days: the Cyber Essentials maximum for high and critical updates.
7 days: our recommended routine target.
Hours: for actively exploited flaws on internet-facing systems.

Those last two are our recommendations rather than scheme requirements, but PHP2Shell showed why we think they're the right ones.

Cyber Essentials as the framework

One of the biggest Cyber Essentials benefits for an SME is that it turns good intentions into a checkable standard, across patching, access control, firewalls, secure configuration and malware protection. If you're working out how to get Cyber Essentials, or renewing after a few changes to your setup, our Supported service includes a gap analysis so you know where you stand before you submit. More SME guidance is in our SME resources.