The 15-point website security checklist we run on every new client

Everything here is checkable from outside or from a single login, takes minutes to verify, and fixes a failure we have personally cleaned up after. Points 1 to 5 are the network and transport layer, 6 to 10 are the server and application, 11 to 15 are people and process. The last five are where most real breaches start.

Network and transport

1. TLS on every hostname, and only modern TLS

Every hostname, including www, staging and any subdomain that serves anything, must have a valid certificate that renews automatically. TLS 1.0 and 1.1 should be disabled. Add an HSTS header so browsers refuse to connect insecurely. Check: load the site over http://; it must redirect to https://, and an SSL test should grade it A or better.

2. Security headers

Five response headers close whole categories of attack: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options or a frame-ancestors policy, Referrer-Policy, and a Content-Security-Policy where the site can support one. They cost nothing. Check: any free header-scanning tool will list which ones are missing.

3. A web application firewall in front of the origin

A WAF at the CDN layer blocks known exploit patterns, credential-stuffing bots and volumetric attacks before they reach your server. Configure the origin to accept connections only from the CDN's address ranges; otherwise attackers simply bypass the firewall by hitting the server's IP directly. Check: try loading the site by its raw IP address. It should refuse.

4. DNS hygiene

DNSSEC enabled, registrar lock on, 2FA on the registrar account, auto-renew on with a card that will not expire, and expiry monitored independently. Remove stale records: a CNAME pointing at a service you cancelled is a subdomain-takeover waiting to happen. Check: list every DNS record and justify each one.

5. Email authentication: SPF, DKIM, DMARC

Without these, anyone can send email that appears to come from your domain, and your own legitimate email will increasingly land in spam. Publish SPF listing only the services that genuinely send for you, sign with DKIM, and set DMARC to p=quarantine and then p=reject once reports show nothing legitimate is failing. Check: send an email to a DMARC-checking tool; all three should pass.

Server and application

6. Patching on a schedule, tested on staging first

The majority of CMS compromises exploit vulnerabilities for which a patch already existed. Operating system security updates should apply automatically. CMS core, plugins and themes should update on a weekly cadence, on a staging copy first, with a rollback plan. Remove plugins you do not use; inactive code is still attackable. Check: count the plugins that have an update pending. The answer should be zero on any given week.

7. Hardened server access

SSH by key only, password authentication disabled, root login disabled, a non-standard port if you like but do not rely on it, a host firewall that allows only 80, 443 and SSH from known addresses, and automatic banning of repeated failed logins. Check: try to SSH with a password. It should not even ask.

8. Least-privilege database and file permissions

The application's database user should be able to read and write its own database and nothing else. Web-server-writable directories should be limited to uploads. Configuration files containing credentials must not be readable from the web. Check: request /wp-config.php.bak, /.env and /.git/config. All must return 404 or 403.

9. Malware and file-integrity scanning

If an attacker does get a file onto the server, you want to know within hours, not months. Schedule scans that compare the application's files against known-good checksums and alert on anything new or modified outside a deployment. Check: ask when the last scan ran and what it would have alerted on.

10. Backups that are off-site, encrypted and tested

A backup on the same server protects against nothing that matters. Backups should be encrypted, stored with a different provider or at least a different region, retained for weeks not days, and restored on a schedule to confirm they work. Ransomware specifically targets reachable backups; the storage should be append-only or otherwise unreachable from the production server's credentials. Check: ask for the date of the last successful test restore. "Never" is the usual answer, and it is the wrong one.

People and process

11. Two-factor authentication on every admin panel

CMS admin, hosting control panel, registrar, DNS, email admin, analytics, ad accounts. All of them. Passwords leak; a second factor turns a leaked password from a breach into a notification. Prefer an authenticator app or hardware key over SMS. Check: list every admin login the business has, and the ones without 2FA.

12. No shared accounts, and offboarding that actually happens

Each person gets their own login with the minimum role they need. When someone leaves, a contractor finishes or an agency is replaced, their access is removed the same day. Shared "admin / admin123" accounts make both impossible. Check: for each system, could you name who has access and remove one person without disrupting anyone else?

13. A password manager and a credential vault

Every credential the business owns should live in a password manager with shared vaults, so nothing is in a spreadsheet, a chat thread or someone's head. The vault is also your inventory of what exists. Check: where is the registrar password right now?

14. Monitoring that reaches a human

Uptime checks from more than one location, certificate and domain expiry alerts, disk and memory thresholds, and login-anomaly alerts from the CMS. Alerts must route to a person who will act, with a written response time, not to a mailbox nobody reads. Check: who was notified the last time the site was down, and how long after it happened?

15. You own every account

The domain is registered in your company's name. The hosting, DNS, CDN, email and analytics accounts are yours, with agencies and contractors holding delegated access you can revoke. This is a security control, not an administrative nicety: the most common way a small business loses its website is a dispute with whoever holds the keys. Check: run a WHOIS lookup on your domain and look at the registrant. If it is not you, fix that before anything else on this list.

Working through it

Done from scratch, the list takes a competent engineer one to two days for a typical business site, plus the ongoing cadence for points 6, 9, 10 and 14. Done as part of a managed plan, it is simply the onboarding checklist and the schedule afterwards; every AD-MEN plan runs all fifteen, and the security model on the hosting page shows how they are layered.

If you would like the audit done for you, the free infrastructure audit covers points 1 to 5 and 15 from public data alone, and tells you what we found in writing.