Practical website security

Website Security Checklist for Business Owners

A website security checklist is useful when it turns a broad topic into clear ownership and repeatable checks. The goal is not to tick boxes once and forget them; it is to know what must stay current as the website and business change.

Use this checklist with whoever manages your website, hosting and domain. Some items may be handled by a web developer or managed provider, but the business should still know who owns each responsibility.

1. Administrator accounts and access

Start with the accounts that can change the website or the infrastructure around it.

  • Enable multi-factor authentication for administrator, hosting, domain, DNS and email accounts wherever supported.
  • Use individual accounts instead of shared administrator credentials where practical.
  • Remove users and supplier access that are no longer required.
  • Limit administrative privileges to people who genuinely need them.
  • Use strong, unique passwords and a reputable password manager.

2. Updates and supported software

Security updates fix known weaknesses. Make update ownership explicit rather than assuming a provider is doing it.

  • Keep the CMS, plugins, themes, frameworks and server software current.
  • Remove unused plugins, themes, extensions and integrations.
  • Replace components that no longer receive security updates.
  • Confirm critical security updates have a defined owner and response process.

3. Backups and recovery

Backups support recovery after accidental deletion, failed updates, compromise or other disruption. A backup process should include restore testing.

  • Back up website files, databases and important configuration regularly.
  • Protect backup accounts and storage from unauthorised access.
  • Keep an appropriate recovery copy separate from the live website environment.
  • Test restoration periodically so the business knows the backup is usable.

4. Public website and domain configuration

Review the security signals that are intentionally visible to browsers and other systems on the internet.

  • Serve the website over HTTPS and maintain valid certificate configuration.
  • Review security headers such as HSTS, Content-Security-Policy, X-Frame-Options and X-Content-Type-Options where appropriate.
  • Keep domain and DNS ownership details controlled and remove obsolete records.
  • Publish and maintain SPF, DKIM and DMARC records for business email where applicable.

5. Exposed services and attack surface

Everything your business exposes to the internet — the website, admin login pages, mail services, remote access, forgotten subdomains and old test sites — forms part of its attack surface. Items that are exposed but no longer used are still reachable by anyone who finds them.

  • Keep a list of the domains, subdomains and services the business exposes publicly, and remove or decommission anything no longer needed.
  • Avoid exposing administration panels, databases or remote-access services to the public internet where a private or restricted path is available.
  • Review exposed services after hosting, DNS or provider changes, when old configuration can be left behind.
  • An external scan can help confirm what is actually visible from the internet rather than what you expect to be visible.

6. Website changes and third parties

Every new plugin, script, analytics tag, form, payment integration or external service can change the website's attack surface and data flows.

  • Know which third parties can access or change the website.
  • Review new integrations before adding them and remove those no longer needed.
  • Keep a simple record of who manages hosting, domain, DNS, website code and critical services.
  • Recheck security after major website, hosting or DNS changes.

7. External assessment and ongoing visibility

An external scan can help reveal configuration and exposure that may not be obvious from a website dashboard. Deeper testing may be appropriate for websites with sensitive data, authentication, payments or other higher-risk functions.

  • Run an external security check after meaningful changes and on a regular basis.
  • Investigate findings rather than treating a score as proof of security.
  • Use scheduled monitoring when the business needs visibility into external changes over time.
  • Escalate to deeper assessment or professional support when the risk or findings justify it.

What this checklist and automated external checks cannot prove

This checklist is an owner-focused review, not an organisation-wide compliance audit. It does not assess your policies, staff processes or legal obligations, and it does not certify compliance with any standard or framework.

Automated external checks look at publicly visible signals only. They are not a manual penetration test, they do not log in to your systems, and they cannot prove the absence of malware or whether a website appears on a security blacklist at any given moment. No checklist or scan can guarantee security; the goal is to reduce obvious weaknesses and know what needs attention next.

Check your website's external security signals

ThreatScout reviews publicly visible website and domain security signals from the outside. It can help identify configuration issues to investigate, but it does not replace secure development, patching, access control, backups or a manual penetration test.

Run the free website security check

Frequently asked questions

How often should I use a website security checklist?

Use it during website launches and major changes, and review it regularly afterward. Access, plugins, hosting, DNS and external exposure can all change over time, so the checklist is most useful as a recurring control rather than a one-off exercise.

Should website backups be tested?

Yes. A backup should support recovery, so periodically test that the website data and configuration you rely on can actually be restored. Testing also helps reveal missing data or dependencies before an incident occurs.

Should every website use the same security controls?

No. A simple information site and a website handling logins, payments or sensitive information have different risk profiles. Core controls such as updates, access protection and backups are broadly useful, while deeper testing and controls should reflect the website's functions and exposure.

Is a website security checklist the same as a vulnerability assessment?

No. A checklist helps confirm that important practices and responsibilities are covered. A vulnerability assessment examines technical signals and potential weaknesses. They complement each other but are not interchangeable.

Security references

Website security is layered. External checks can surface useful public signals, but secure development, patching, access control, backups and appropriate testing remain separate responsibilities.