Business Website Security Checklist

ContentsTap to jump to a section

01Know what you are protecting
02Lock down administrative access
03Patch and reduce the attack surface
04Make backups, logs and alerts usable
05Prepare for testing and incident response

Summary

The one-minute brief

Reduce attack surface by removing unused accounts, plugins and services.
Protect administrative access with MFA and least privilege.
Test the ability to restore, not merely whether a backup job ran.

Know what you are protecting

Create an inventory of domains, subdomains, administrative accounts, hosting providers, source repositories, databases and third-party services connected to the website. Many incidents begin with an old asset that nobody owns but that remains reachable from the internet.

For each asset, record an owner, the data it handles and the impact of disruption or disclosure. This lets the business prioritise protection instead of applying the same control to everything.

Remove unused staging sites, test accounts and DNS records.
Keep domain and hosting ownership in company-controlled accounts.
Record provider contacts and escalation routes before an incident.

Lock down administrative access

Enable multi-factor authentication for email, domain, hosting, CMS, source control and analytics platforms. Email deserves particular attention because it is often the recovery path for every other account.

Give each person an individual account and only the permissions required for the work. Do not share a common administrator login through chat or a spreadsheet. When an employee or supplier leaves, remove access through a checklist rather than memory.

Require MFA anywhere that can change code, DNS or data.
Use unique passwords stored in an organisational password manager.
Review the administrator list every quarter.

Patch and reduce the attack surface

Frameworks, content systems, plugins and libraries need a defined update rhythm. An important security patch should not wait for the next redesign. Replace or remove dependencies that are no longer maintained.

Every added component becomes another surface to monitor. Restrict public administration routes when practical, limit file uploads, disable production debug features and never place secrets in source code or browser-delivered JavaScript.

Subscribe to security notices from frameworks and providers.
Review dependencies and plugins at least monthly.
Remove an unused service instead of only hiding its interface.

Make backups, logs and alerts usable

A backup has value only if it can be restored. Perform a test restore into an isolated environment, measure the time and document who is authorised to do it. Keep at least one copy separate from the main system so it cannot be deleted by the same failure.

Capture logs for administrative sign-ins, permission changes, deployments, server errors and unusual behaviour. Every alert should lead to a named owner, not an unattended shared mailbox.

Set recovery-time and acceptable-data-loss targets.
Alert on repeated failed sign-ins and administrator changes.
Retain enough history for investigation without logging unnecessary sensitive data.

Prepare for testing and incident response

Automated scanning is useful for common configuration problems, but it does not replace contextual testing. Before a major launch or when the site handles important data, a security assessment or penetration test can reveal how separate weaknesses combine into business risk.

Prepare a short incident page covering who can take the service offline, which provider to contact, how to preserve logs, how to communicate internally and what must be true before recovery. During an incident, a simple process that has been rehearsed is more useful than a long document nobody has opened.

Retest after remediation to confirm that the issue is genuinely closed.
Run a small tabletop exercise at least once a year.
Refresh the checklist after major infrastructure or supplier changes.

FAQ

Frequently asked questions

How often should a business website be security tested?

Configuration and dependency checks should happen continuously or monthly. Consider deeper assessment after major changes, before important launches or on a risk-based cycle.

Is SSL enough to make a website secure?

SSL alone is not enough to make a website secure. HTTPS protects data in transit, but it does not address weak access, vulnerable code, outdated plugins, misconfiguration or missing monitoring.

References

Sources used in this guide

We prioritise official guidance and primary technical sources. Visit each source for full context and the latest updates.