Contents
Does the 14-day rule cover your website
Cyber Essentials: Requirements for IT Infrastructure v3.2 lists the software categories that fall under security update management as “operating systems, commercial off-the-shelf applications, extensions, interpreters, scripts, libraries, network software and firewall and router firmware.” Read plainly, WordPress core, an active theme and the plugins running on it are instances of that category. They are commercial or freely distributed off-the-shelf applications and extensions, installed on a server the way any other software is installed on a device.
That reading is a reading, not a ruling. IASME’s scope guidance places web applications inside the organisational services a supplier’s controls have to cover, which supports treating the site as in-scope software. But whether a specific install counts is the assessor’s call, the same answer this objection gets whenever it comes up: don’t argue the point, quote the scope line, and say plainly that a given install falls inside the assessor’s judgment rather than a fixed rule.
There is a real question about whether a bespoke, custom-built component sits differently under the requirement. The exact exclusion wording for bespoke software could not be verified against a primary source in the research behind this piece, so it is not quoted or restated here. Treat it as an open question to raise with your assessor, not an assumption to build a patching schedule on.
For a supplier who already runs a maintenance retainer built around this control, NoDrama’s WordPress maintenance retainer is one way that reading gets addressed in practice: it treats WordPress core, the theme and plugins as software that needs the same dated update discipline as the rest of the estate.
What counts as “critical or high risk”
The 14-day clock is not a general instruction to update software when convenient. NCSC’s requirement defines the trigger precisely: a “critical” or “high risk” vulnerability is one with a CVSS v3 base score of 7 or above, or one the vendor itself labels critical or high risk. Either test is sufficient on its own.
That means the clock is scoped to one severity tier, not every routine plugin release. A minor version bump that adds a feature or fixes a cosmetic bug carries no 14-day obligation. A release that patches a vulnerability the vendor rates critical or high risk does, and the 14 days start running from the date the vendor releases that fix, not from the date someone on your team happens to notice it.
-
01Vendor releases updateCore, theme or plugin author publishes a new version.
-
02Check vendor advisory for severity label or CVSS v3 scoreThe advisory or changelog entry, not a general impression.
-
03If critical or high risk (score 7+), 14-day clock startsCounted from the vendor’s release date. Routine releases carry no clock.
-
04Tested, dated update recordWhat was updated, when, and whether it held.
Before assuming the clock has started on any given release, check the vendor’s own advisory or changelog entry for the severity label. That label, not a general sense that “it looked important,” is what starts and stops the 14-day window.
How the update evidence has to work
Cyber Essentials assessment is evidence-based, not intention-based. What an assessor asks for is a dated record of what was updated and when, not a description of intentions or a general assurance that things get kept current.
That distinction matters because the two common answers to “is the website patched” fall short in different ways:
Shows a setting, not a result. It does not show whether an update actually installed, when, or whether it broke something and rolled back silently.
Not a standing, checkable record an assessor can review months later.
A dated, checkable log, by contrast, is exactly the artefact the requirement is written around. If you have not looked at what is currently installed and running, NoDrama’s free website audit is a way to see the current state of plugins and themes before building a patching record around them.
Confirm any update record shows an install date for the update itself, not just that the auto-update setting is switched on. A toggle is a configuration. A dated entry is evidence.
What a tested update process looks like
The general mechanism behind a defensible update process has three parts: pull the update into a staging environment that mirrors the live site, test it there, then apply it to the live site with a backup taken first. That sequence is what turns “we updated it” into “we updated it, checked it worked, and could have reversed it if it hadn’t.”
Plugin and theme updates are one of the features every NoDrama plan includes. NoDrama’s WordPress maintenance retainer describes how that update handling works in practice.
Restore testing is the artefact closest to the dated evidence the requirement asks for: a scheduled, dated confirmation that a backup actually restores, rather than a promise that backups exist. The three plans differ in backup frequency, response commitment, job capacity and restore-testing cadence, not in whether malware scanning, firewall protection or plugin and theme updates are included, since those are universal across every tier:
| Plan | Backup frequency | Response commitment | Job capacity | Restore testing |
|---|---|---|---|---|
| The Standard $129/month |
Daily automated | 4 hours | One small job at a time | Annual |
| The Higher Standard $249/month |
Automated, every 12 hours | 2 hours | Two small jobs at a time | Twice-yearly |
| The Highest Standard $479/month |
Real-time, on every change | 1 hour | Three small jobs at a time | Quarterly |
All three plans also include offsite backups with 90-day retention, uptime monitoring, a global CDN, and a staging environment, alongside malware scanning, firewall protection and plugin/theme updates.
NoDrama’s pricing page sets out the three plans and what each covers.
What an assessor actually checks
At self-assessment or during a Cyber Essentials Plus scan, an assessor checks whether a critical or high-risk fix is still open past 14 days from the vendor’s release date. That is the specific thing being tested, not a general impression of how well-maintained the site looks.
Passing the assessment is the priority a dated record serves. A verbal assurance that “we keep it updated” does not stand up to that check the way a log with install dates does. NoDrama’s pricing page shows the response commitment at each plan, which matters here because a faster response time shortens the gap between an advisory landing and a fix being applied.
See how the maintenance retainer covers this control.
NoDrama’s WordPress maintenance retainer covers plugin and theme updates on every plan.
What this does not solve
A maintenance retainer supports the security update management control. It does not itself decide whether a given install is in scope, and that decision stays with the assessor in every case. It is not a guarantee that every advisory gets met inside 14 days either; a tested update process shortens the gap between a critical or high-risk advisory and a dated fix, but no plan promises a fixed outcome on every release.
It also does not resolve the bespoke-component scope question. Where a component was custom-built rather than off-the-shelf, whether it falls under the same 14-day clock stays a question for the assessor, and this piece does not assert an answer to it.
Conclusion
WordPress core, a theme and a stack of plugins read as commercial off-the-shelf software under Cyber Essentials, which puts them inside the same software scope as the laptops and servers the requirement was written for, though the specific call on any one install belongs to the assessor. The 14-day clock only applies to updates the vendor rates critical or high risk, measured by a CVSS v3 base score of 7 or above, and it runs from the vendor’s release date. What clears that check at assessment is a dated, checkable record of what was updated and when, not an auto-update toggle or a verbal assurance, and a tested update process is what produces that record.