What this guide covers
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.
- WordPress core
- Commercially distributed plugins
- Commercially distributed themes
- 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.
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.
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. |
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.
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.
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.
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.
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.