Audit My Site Get Started

Category: Compliance and accessibility

  • 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.

  • WordPress PCI Compliance: What Applies to Your Payment Page

    WordPress PCI Compliance: What Applies to Your Payment Page

    What this guide covers

    1. 01Work out what actually applies to you
    2. 02Understand the two requirements that reach your page
    3. 03Decide what to do next

    The short answer, and who it applies to

    PCI DSS certifies a payment environment, not a CMS, and cares about how the payment page is built and operated, not which software renders it. WooCommerce’s own documentation puts it plainly: “PCI DSS compliance is ultimately the responsibility of the store owner.”

    A checkout sits in one of three architectures: a full redirect to the processor’s hosted page, an embedded field on your own page, or self-hosted fields touching the card number directly. Most WooCommerce stores using Stripe Elements, the Stripe Payment Element, or WooPayments sit in the middle case. WooCommerce’s Stripe documentation confirms that “most merchants can use Self-Assessment Questionnaire (SAQ) A for validation,” though the processor or acquirer can still require a different SAQ. PCI DSS is a card brand standard, not a national law, so a UK store and a US store answer the same requirements; only the acquirer relationship and questionnaire differ.

    Who operates the checkout day to day is a separate question, and it is what ongoing WordPress security work covers.

    Verification step

    Check which payment method your store renders, an embedded field from the processor’s domain or a redirect that sends the shopper off-site, before assuming the questionnaire.

    How PCI scope is decided on a WordPress checkout

    Where the card number goes, and why that reduces your scope

    With an embedded field, the card input is rendered inside an iframe served from the processor’s own domain, though it sits inside your checkout page. Your JavaScript receives a token, not a card number, and your server never stores card details.

    The SAQ A e-commerce channel requirement states this directly: “all elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.” Meeting it keeps a merchant on the reduced SAQ A path rather than a longer questionnaire.

    Three checkout architectures
    Where PCI scope falls in each

    Full redirect

    Card enteredOn the processor’s own hosted page, off your site
    Your server seesNothing card-related
    Typical SAQOften SAQ A, lower-touch category

    Embedded processor field

    Card enteredIn an iframe from the processor’s domain, inside your page
    Your server seesA token only, never the card number
    Typical SAQSAQ A, with the 2025 script-attack criterion

    Self-hosted fields

    Card enteredDirectly in your own form fields
    Your server seesThe card number touches your code
    Typical SAQA longer questionnaire, outside this guide’s scope
    Shaded across all three: the scripts running on this page are yours, regardless of architecture.

    SAQ labels are typical indications, not guarantees. The acquirer makes the final call on which questionnaire applies, and no NoDrama service is claimed to satisfy any of these requirements.

    Diagram comparing three WordPress checkout architectures and where PCI scope falls in each.

    What changed for SAQ A in 2025

    SAQ A now carries an added eligibility criterion: the merchant has to confirm “that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s),” alongside the existing criteria rather than replacing them. The future-dated requirements in PCI DSS v4.x, including this criterion, took effect on 31 March 2025, per the PCI Security Standards Council.

    There are two ways to satisfy it: implement 6.4.3 and 11.6.1 yourself, or rely on written confirmation that the processor’s embedded solution already includes those protections, implemented per its instructions. The PCI SSC’s FAQ and the SAQ A form set out both routes. Neither 6.4.3 nor 11.6.1 has published clause text available outside the standard itself, so this guide describes what each asks for rather than quoting it.

    Verification step

    Ask your processor, in writing, whether it provides the script-attack confirmation for your integration. A written answer is the artefact worth keeping, not a support chat note.

    What requirements 6.4.3 and 11.6.1 ask of the page around the card fields

    What it asks for What it is watching What satisfies it in practice
    6.4.3Script inventory An inventory of every authorised script on the payment page, a justification for each What executes in the browser, not the card data itself A maintained list, and a way to confirm each script’s integrity
    11.6.1Change detection A mechanism that checks the page’s HTTP headers and content against a baseline Unauthorised changes to the served page, at least weekly or per a targeted risk analysis A scheduled diff against the baseline, with an alert someone actually reads
    Table comparing the script inventory requirement and the change detection requirement for a payment page. Description only, since no verbatim clause text of either requirement was sourced.

    6.4.3, the script inventory

    This requirement governs what executes in the browser on the payment page, not the card data. It asks for an inventory of every authorised script, a justification for each, and a way to confirm its integrity. In WordPress terms, every plugin, theme change, or tag manager snippet on the checkout template has to be on a list somebody maintains.

    11.6.1, the change and tamper detection

    This requirement asks for a mechanism that checks the payment page’s HTTP headers and content against a baseline and alerts someone to unauthorised changes, at least weekly or at the frequency a targeted risk analysis sets. Stated plainly, something has to diff the served page on a schedule, and somebody has to receive the alert.

    Why rollback and a CDN are not the same control

    Rollback with tested updates answers whether a change broke the page. Tamper detection answers whether an unauthorised script was added at all, between updates. A CDN serves cached assets and filters some injection at the edge, but it does not inventory checkout scripts, and neither control satisfies 6.4.3 or 11.6.1 alone. A record of authorised changes looks closer to the record NoDrama hands over for other maintenance work. That record is not a claim of 6.4.3 or 11.6.1 coverage.

    Verification step

    Open your checkout page in a browser, view the network requests, and list every domain a script loads from. That is the starting point of the 6.4.3 inventory.

    What good looks like on a WooCommerce checkout

    A few markers separate a checkout page that could answer the new SAQ A criterion from one that could not.


    What a change record on the payment page contains

    • A named list of scripts on the checkout template, with a reason for each and a reviewer for plugin changes.
    • A baseline of the page’s headers and content, checked on a schedule, with an alert someone reads.
    • A change record: what changed, when, and who approved it.
    • Written confirmation from the processor, kept on file, if you rely on that route instead of implementing the requirements yourself.

    Backups and off-site copies fit into that record, at how restores and off-site copies are handled.

    Verification step

    Pick the last plugin update that touched checkout, then answer from a record rather than memory: what changed, who tested it, and when the page was checked.

    What to do about it

    • Confirm which payment architecture your checkout uses: a redirect, an embedded field, or self-hosted fields.
    • Ask your acquirer or processor which SAQ applies, and get the answer in writing.
    • Build the script list for the checkout template from the browser, not the plugin screen.
    • Decide what watches the page between releases and who receives the alert.
    • Decide who tests a plugin update against that page before it goes live.
    Verification step

    Write down the person’s name for each action above. An action with no name is not yet in place.

    Rather not own the update testing yourself? NoDrama tests every update on a staging copy first and sends you a dated monthly record. See the three plans and what each one covers.

    Not sure what is loading on your checkout page?

    Start with NoDrama’s free WordPress audit, no pitch attached.

    Audit My Site

    Common misconceptions

    “Stripe is PCI compliant, so my store is.”

    The processor’s compliance covers its own iframe and infrastructure. Your plugins and theme stay in your scope.

    “A security plugin covers it.”

    A general purpose plugin is not, out of the box, a script inventory or change detection mechanism for the checkout template.

    “Wix would be safer for PCI than WordPress.”

    No primary source compares the platforms on PCI grounds, so this is reasoning from how scope works, not a sourced comparison; scope tracks architecture, not CMS.

    “The site runs fine, so nothing has changed on the page.”

    Fine decays by default, and a script can be added without anything visibly breaking.

    What this does not cover

    This guide is written for merchants using an embedded field or a redirect, self-assessing rather than an external audit. It does not cover merchants whose own code renders card fields, a longer questionnaire, or merchants large enough to need external assessment. It does not carry the verbatim text of requirements 6.4.3 or 11.6.1, linked above rather than quoted. And it cannot tell you which questionnaire your acquirer will accept; that is their call, not something a guide can settle.

    Where this leaves your payment page

    PCI compliance on a WordPress checkout depends on how the payment page is built and whether its scripts are inventoried and watched, not which CMS renders the site. Once you know your architecture and SAQ, the question worth answering is who operates that page between releases.