Website Security Checklist for UK Small Businesses (2026)

How to use this checklist

Work through each item and mark it as done, in progress, or not applicable. Most items take under an hour to address. A few require ongoing maintenance rather than a one-time fix — those are noted.

This checklist covers the most common security gaps we find on UK small business domains. It is not exhaustive, but completing it puts you ahead of the vast majority of businesses your size.

1. SSL certificate is valid and not expiring soon

What to check: Visit your website and confirm the padlock icon appears in the browser address bar. Click it to see the certificate expiry date. Anything expiring within 30 days needs immediate attention.

Why it matters: An expired SSL certificate breaks HTTPS, triggers browser warnings that drive visitors away, and is flagged by search engines. It is also a basic Cyber Essentials failure.

How to fix it: Most hosting providers handle SSL renewal automatically via Let's Encrypt. If yours does not, renew manually through your hosting control panel or switch to a host that automates it.

2. DMARC record is configured

What to check: Look up your DMARC DNS record at _dmarc.yourdomain.com. It should exist and have a policy of at least p=quarantine.

Why it matters: Without DMARC, attackers can send emails that appear to come from your domain. Your customers receive convincing phishing emails that look like they are from you.

How to fix it: Add a TXT record to your DNS. Start with v=DMARC1; p=none; rua=mailto:you@yourdomain.com to monitor, then move to p=quarantine once you have confirmed all legitimate email is passing authentication.

3. SPF record is configured

What to check: Look up TXT records on your root domain. You should see a record starting with v=spf1.

Why it matters: SPF tells receiving mail servers which servers are authorised to send email from your domain. Without it, spoofing your email address is trivial.

How to fix it: Your mail provider (Google Workspace, Microsoft 365, etc.) will have specific SPF record values in their documentation. Add the TXT record to your DNS.

4. DKIM is enabled

What to check: Your mail provider's admin panel should show DKIM as active. You can also check by sending an email to a Gmail address and clicking "Show original" — look for dkim=pass.

Why it matters: DKIM adds a cryptographic signature to every email you send, allowing receiving servers to verify it is genuine.

How to fix it: Enable DKIM in your mail provider's admin panel (Google Workspace Admin or Microsoft 365 Defender portal), then publish the public key in your DNS as instructed.

5. No unnecessary ports are open

What to check: Run an external port scan on your domain. Ports 80 and 443 should be open. Everything else warrants investigation.

Why it matters: Open ports are entry points. Database ports (3306, 5432), remote desktop (3389), and old FTP (21) or Telnet (23) services are frequent attack targets.

How to fix it: For each unexpected open port, identify the service running on it and either shut it down or firewall it so it is only accessible from specific trusted IP addresses.

6. HTTP security headers are configured

What to check: Use a tool like securityheaders.com to scan your domain. Look for: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Referrer-Policy.

Why it matters: Security headers protect your visitors from a range of attacks including clickjacking, content injection, and data leakage. They take minutes to add and are frequently missing.

How to fix it: Add the headers in your web server configuration (nginx, Apache) or via your hosting platform. Most can be added in a single configuration block.

7. No sensitive files are publicly accessible

What to check: Try accessing common sensitive paths on your domain: yourdomain.com/.env, /config.json, /backup.sql, /.git/config. None of these should return content.

Why it matters: Exposed .env files contain database credentials and API keys. Exposed .git directories can leak your entire source code. These are found by automated scanners within hours of going live.

How to fix it: Configure your web server to deny access to dotfiles and backup files. Move sensitive files outside the web root entirely.

8. Software and plugins are up to date

What to check: If you run WordPress, Shopify, or any CMS, check the admin panel for available updates. Check your hosting control panel for PHP version — anything below 8.1 is end-of-life.

Why it matters: Outdated software is the most common attack vector for small business websites. Known vulnerabilities are published publicly, and automated scanners probe for them constantly.

How to fix it: Enable automatic updates where possible. For WordPress, enable automatic minor updates and review major updates promptly. Remove plugins and themes you are not using.

9. Admin panel is not on a guessable URL

What to check: Try accessing yourdomain.com/admin, /wp-admin, /administrator, /login. If these reach a login page, the URL is predictable and brute-force attempts are likely.

Why it matters: Automated bots scan for common admin URLs and attempt credential stuffing attacks continuously.

How to fix it: Move your admin panel to a non-standard URL, or restrict access to specific IP addresses via your web server configuration. Enable two-factor authentication on all admin accounts.

10. Strong passwords and 2FA on all admin accounts

What to check: Verify that all admin accounts use unique passwords of at least 16 characters, and that two-factor authentication is enabled.

Why it matters: Credential stuffing attacks use leaked username/password combinations from other breaches. Unique passwords and 2FA make these attacks ineffective.

How to fix it: Use a password manager (1Password, Bitwarden) to generate and store unique passwords. Enable 2FA via an authenticator app on every account that offers it.

11. No default credentials on any service

What to check: Review any routers, network devices, servers, or software deployed with default usernames and passwords. Common defaults: admin/admin, admin/password, root/root.

Why it matters: Default credentials are the first thing automated scanners try. Services left on defaults are typically compromised within hours of being internet-exposed.

How to fix it: Change credentials on every device and service during initial setup. Document what you changed them to in a password manager.

12. Backups exist and have been tested

What to check: Confirm you have recent backups of your website, database, and any critical files. Confirm you have actually tested restoring from a backup in the last 6 months.

Why it matters: Ransomware, accidental deletion, or hosting failures can destroy your data. A backup you have never tested may not work when you need it.

How to fix it: Most hosting providers offer automated backups — verify they are enabled and storing at least 14 days of history. Store a copy off-site (a separate cloud provider or local drive). Run a test restore at least twice a year.

13. No exposed API keys or secrets in public repositories

What to check: Search GitHub for your domain name and organisation name. Review any public repositories for .env files, hardcoded credentials, or configuration files with live API keys.

Why it matters: Exposed API keys are discovered by automated bots within minutes. AWS keys, Stripe keys, and database credentials in public repositories are a direct path to data breach or significant financial loss.

How to fix it: Revoke any exposed keys immediately, generate replacements, and ensure .env is in .gitignore on every project. Use Olimpio's secrets scanner to check your repositories automatically.

14. HTTPS is enforced — HTTP redirects to HTTPS

What to check: Try visiting http://yourdomain.com (without the S). It should automatically redirect to https://yourdomain.com.

Why it matters: If HTTP is not redirected, visitors who type your URL without https:// may browse your site unencrypted, exposing any data they submit.

How to fix it: Add an HTTP-to-HTTPS redirect in your web server configuration or hosting control panel. Most modern hosting platforms have a one-click option for this.

15. You have a process for responding to security incidents

What to check: If your website was compromised today, do you know what you would do? Who would you call? Where are your credentials stored?

Why it matters: The difference between a minor incident and a major breach often comes down to how quickly you respond. Having a plan before you need it is the defining factor.

How to fix it: Write a one-page incident response plan. It should cover: who to notify (hosting provider, customers if data was accessed, ICO if personal data was breached), how to take your site offline quickly, where credentials are stored, and who has the access needed to respond.

Automate this checklist

Running through this manually is valuable, but it is a point-in-time snapshot. Your infrastructure changes, new vulnerabilities are discovered, and certificates expire. An Olimpio scan checks the technical items on this list automatically — open ports, DNS records, SSL status, security headers, exposed secrets, and Cyber Essentials alignment — and alerts you when something new appears.