In this piece
- 01
What the audit coversThe eight-area template, and how to fill each section.
- 02
What it actually checks and missesWhat a reviewer or auditor looks for beyond the automated scan.
- 03
Where the gaps areWhat this does not cover, and where teams get the cadence question wrong.
The template
The eight areas below are the whole audit. Copy the table, work through it top to bottom, and mark each row pass or fail rather than writing a paragraph. For a longer view of how a WordPress-specific security pass gets scoped as ongoing work rather than a one-time list, see how the security work is scoped.
| Area | What to check | Result |
|---|---|---|
|
Software inventory and patching
|
Every core, plugin, theme and custom component, version recorded and checked against the vendor’s current release |
PassFail
|
|
Access control
|
Every admin-level account, least-privilege confirmed, MFA on privileged accounts |
PassFail
|
|
Transport security
|
Certificate validity and expiry date, modern TLS only, no mixed content |
PassFail
|
|
HTTP response headers
|
HSTS, X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, Referrer-Policy set |
PassFail
|
|
File and server configuration
|
File permissions, debug output off in production, no directory listing, database credentials unreachable |
PassFail
|
|
Malware and code-level scanning
|
Automated signature scan plus a manual review of theme and plugin files for unexplained external calls |
PassFail
|
|
Backup coverage and restore testing
|
Frequency, offsite storage, a restore actually performed against a non-production copy |
PassFail
|
|
Monitoring and logging
|
File changes, new user creation and plugin or theme installs logged, uptime monitoring in place |
PassFail
|
How to fill each section
Software inventory and patching
List every core, plugin, theme and custom component with its exact version number. Check each one against the vendor’s current release and any public vulnerability advisory for that version.
Confirm the version number shown in the dashboard matches what the vendor lists as current.
Access control
List every admin-level account and what it is actually used for, not what it was set up for originally. Confirm least-privilege on each one, and multi-factor authentication on every privileged account.
Log in as a non-admin test account and confirm it cannot reach admin functions.
Transport security
Check the certificate’s validity and expiry date, confirm only modern TLS versions are accepted, and confirm no page loads mixed content over an insecure connection. For the fastest way to spot the common failures here without the full template, see the five-minute checks to run first.
Load every template page and confirm no browser warning for mixed content.
HTTP response headers
Five headers do most of the work here, and each one closes a specific gap.
| Header | What it stops | Recommended value |
|---|---|---|
| Strict-Transport-Security | Downgrade to an insecure connection |
max-age=31536000; includeSubDomains
|
| X-Frame-Options | The page being framed by another site |
deny
|
| X-Content-Type-Options | The browser guessing a file’s type |
nosniff
|
| Content-Security-Policy | Scripts loading from an unapproved source | set per site |
| Referrer-Policy | Full URL data leaking to a third-party site | set per site |
Check the live response headers with a header-inspection tool after making a change.
File and server configuration
Check permissions on sensitive files, confirm debug output is disabled in production, confirm directory listing is off, and confirm database credentials are not reachable from a public path.
Request a known config path directly and confirm it returns a not-found response.
Malware and code-level scanning
Run an automated scan for known malware signatures, then do a manual review of theme and plugin files for calls to external domains nothing on the site should be talking to. The manual step exists because a scanner matches known signatures. A backdoor written to look like ordinary custom code will not match anything, and it will still get through.
Compare the current file list against the last known-clean state.
Backup coverage and restore testing
Record the backup frequency and whether storage is offsite, then actually restore a copy to a non-production environment. Neither the NCSC’s small business guidance nor any other primary source gives a numeric backup cadence, so there is no fixed number to check against here. What there is a fixed test for is whether the restore works at all.
Restore to staging and confirm the site functions with both files and database present.
Monitoring and logging
Confirm file changes, new user creation and plugin or theme installs are logged, and that uptime monitoring is running.
Make a small test change and confirm it appears in the log the same day.
An audit finds the current state. Turning that state into something that stays current is a different piece of work, covered in what an audit turns into as ongoing care.
What reviewers or auditors actually check
The eight areas above map onto the OWASP Top 10:2021 failure categories: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, authentication failures, software and data integrity failures, logging and monitoring failures, and server-side request forgery. That is the underlying structure a reviewer is working from, not a checklist unique to any one vendor.
The difference that matters is between an automated scan and a full audit.
Automated scan
Matches known malware signatures and known vulnerable software versions against a database.
Full audit
Does that too, then also checks configuration, access and process, which is where the manual review and the restore test come in.
Neither one is a substitute for the other.
For a sense of what’s covered as ongoing service rather than a one-time check, see the three plans and what each covers.
What this does not cover
This checklist is not a penetration test. A pentest probes for a chain of exploitable weaknesses an attacker could actually use, rather than checking each item against a known list, and it needs a tester actively trying to break in.
It also does not cover any sign-off a specific regulated industry needs from its own legal or compliance function. A completed checklist is evidence of a maintenance pass, not a substitute for whatever a regulator or an assessor requires in that industry.
Where teams get this wrong
A scheduled backup is not a working one until it has actually been restored. Plenty of sites have a backup running on a timer that nobody has ever pointed at a restore.
Managed hosting, a CDN and premium plugins are purchases, not an operator. None of them run this checklist for you, and treating them as if they had is the most common way a gap goes unnoticed.
The cadence question stops too early when the answer is “we did one once.” A single completed pass tells you the state on the day it ran, nothing about the weeks after.
How often to run this
No primary source gives a fixed cadence for this, so the honest answer is a test rather than a number: does the site take a password, a payment or a file from a visitor.
Brochure site
Can run a lighter pass on a longer interval.
Password, payment or file
Needs access, transport security and headers checked on a recurring schedule, not once and filed away.
Get a second pass on it.
NoDrama’s free website audit runs the same checklist against your site and tells you what it finds, no pitch attached.
Conclusion
A complete website security audit is eight areas checked in order: software inventory and patching, access control, transport security, HTTP headers, server configuration, malware and vulnerability scanning, backup and restore testing, and monitoring. How deep each one needs to go is set by a single test, whether the site takes a password, a payment or a file from a visitor, and a backup that has never been restored or a scan that never gets a manual follow-up are the two most common ways a checklist looks complete without being one.