Tag: UK

  • Cyber Essentials Security Update Management: Does the 14-Day Rule Cover Your WordPress Site

    Cyber Essentials Security Update Management: Does the 14-Day Rule Cover Your WordPress Site

    Contents

    1. 01Work out whether this control reaches your site
    2. 02Meet the requirement
    3. 03Confirm it holds at renewal

    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.

    Update triage and evidenceFrom a vendor release to a record an assessor can check
    1. 01
      Vendor releases updateCore, theme or plugin author publishes a new version.
    2. 02
      Check vendor advisory for severity label or CVSS v3 scoreThe advisory or changelog entry, not a general impression.
    3. 03
      If critical or high risk (score 7+), 14-day clock startsCounted from the vendor’s release date. Routine releases carry no clock.
    4. 04
      Tested, dated update recordWhat was updated, when, and whether it held.
    Diagram of the Cyber Essentials update triage and evidence process.
    Verification step

    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:

    Auto-update toggled on

    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.

    A developer’s verbal confirmation

    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.

    Verification step

    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.

    Table comparing NoDrama’s Standard, Higher Standard and Highest Standard plan backup frequency, response commitment, job capacity and restore-testing cadence.

    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.

    See Maintenance Work

    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.

  • Cyber Essentials Malware Protection for Your Website

    Cyber Essentials Malware Protection for Your Website

    What this guide covers

    1. 01Work out whether the website is in scope
    2. 02Confirm what covers it
    3. 03Keep it holding

    What “in scope” actually means for a website

    The current requirements document, NCSC’s Cyber Essentials: Requirements for IT Infrastructure v3.3, states the position this way: publicly available commercial web applications are in scope by default, and bespoke and custom components of web applications are out of scope. That is our summary of the document’s position rather than a confirmed word for word quotation. The exact sentence and question number need checking against the current PDF before anyone relies on it at assessment.

    WordPress core is commercial, publicly available software. A plugin or theme distributed commercially, whether paid or free, is the same kind of thing. A feature built in-house for that specific site, a bespoke booking form or a custom integration nobody else runs, is what the exclusion actually covers.

    In scope or excluded, at a glance
    In scope

    • WordPress core
    • Commercially distributed plugins
    • Commercially distributed themes
    Excluded

    • A custom-built feature or integration developed in-house for that site

    This illustrates a reading of the scope rule, not a ruling from a certification body. The assessor decides at assessment time.

    A diagram showing that commercial WordPress software is in scope for Cyber Essentials by default while bespoke, custom-built components are excluded.

    Some suppliers hear the scope question and conclude the marketing site is not in scope, because it does not look like a laptop or a server. The line above does not support that reading for a site built on commercial software. Whether a specific installation falls inside the boundary is our reading of that line, not a ruling from a certification body, and the assessor decides at assessment time.

    Verification step

    List every plugin and theme running on the site and confirm which, if any, were custom-built for that install rather than commercially distributed. Anything on the commercial list sits inside the default scope position above.

    The malware protection control itself

    The control requires an active malware protection mechanism on every device in scope. That requirement is met through one of the technical options the current requirements document defines.

    Two options are confirmed from the current text:

    Option What it requires
    Anti-malware software Kept updated in line with vendor recommendations. Prevents malware from running, prevents execution of malicious code, prevents connections to known malicious websites.
    Application allow listing Only approved applications, restricted by code signing, are allowed to execute on the device. Active approval is required before deployment.
    A table comparing the anti-malware software and application allow listing options under the Cyber Essentials malware protection control.

    Some secondary commentary on the scheme references a third option, application sandboxing. We could not confirm that option from the current requirements text this session, so we are not asserting a count either way. Treat “two options” as the confirmed position pending a direct read of the source document, and check the live text before ruling sandboxing in or out for a specific assessment.

    What a WordPress site needs to meet this

    What satisfies the control depends on how the site is hosted, and the two hosting models point at different evidence.

    A self-administered server, a VPS or a dedicated box the applicant manages directly, is itself an in-scope device. It needs a mechanism suited to a web server rather than desktop antivirus: file-integrity or malicious-code scanning that can detect injected or altered PHP, a web application firewall that blocks known malicious payloads, and the update discipline covered in the next section.

    A fully managed SaaS or PaaS platform shifts the server-level obligation to the hosting provider. The applicant’s own scope then becomes the devices used to log in and administer the site, not the server behind it.

    Verification step

    Identify which hosting model applies before deciding what evidence to gather. The two models point at different device lists and different proof.

    What a security plugin does and does not cover

    A scanning or malware-detection plugin can contribute evidence toward this control. It is not automatically equivalent to either defined option, and whether it counts is the assessor’s call, not the plugin vendor’s marketing copy.

    Verification step

    Check the plugin’s own stated capabilities against the anti-malware software option’s actual wording above, rather than assuming any plugin that markets itself as security software qualifies on that basis alone.

    The fourteen-day patching clock

    Version 3.3 introduces two auto-fail questions, one covering operating systems and firmware and one covering applications and their associated files. Each carries a fourteen-day-from-release update requirement. Missing it on either question causes automatic assessment failure, stated here as a fact of how the control works rather than a warning.

    For a WordPress site, the applications and associated files question reaches core, every plugin and the active theme. NoDrama’s website security work covers the update-testing side of keeping that clock met, which is the piece most suppliers describe finding out about only when someone asks who last patched the site.

    Verification step

    Confirm there is a standing, dated record of when core, every plugin and the theme were last updated. A memory of “recently” is not a record an assessor can check.

    What this guide does not settle

    This guide does not certify that any specific setup passes assessment. That decision belongs to the assessor reviewing the actual installation, not to a guide written in advance of it.

    It also does not resolve whether the scheme currently defines two or three technical options for malware protection. That needs a direct read of the current requirements document rather than a guess from secondary commentary.

    NoDrama’s security handling covers the scanning, tested updates and monitoring side of this control. See how NoDrama covers the website side of this control.

    See how NoDrama covers the website side of this control.

    Scanning, tested updates and monitoring, built into the WordPress security retainer.

    See Security Work

    Conclusion

    A commercial WordPress site is in scope for Cyber Essentials by default, because the scope rule excludes bespoke and custom components rather than commercial software as a class. Meeting the malware protection control on that site means matching the hosting model to the right evidence: self-administered servers need server-appropriate scanning and a WAF, managed platforms shift the server-level obligation to the provider, and keeping a dated record of the fourteen-day patching clock across core, plugins and theme. None of that is a guarantee of a pass; the assessor makes that call. For the wider picture of what a maintenance plan covers month to month, see the three plans and what each covers.