Website Security Checklist for Small Businesses

Most small business websites are not attacked by a person who chose them specifically. They are found by automated scanners looking for a known weakness: an outdated plugin, a weak admin password, an exposed backup, a form that accepts anything.

That is good news. It means most incidents are preventable with basic hygiene.

This checklist is organized by priority. You do not need to do everything in one week. You need to close the doors that are easiest to find.

The 10-minute baseline

If you only have ten minutes, do these five things:

1. Confirm HTTPS works and redirects from HTTP.
2. Turn on automatic updates for the CMS, plugins, and server.
3. Check that admin accounts use unique passwords and MFA.
4. Confirm a backup exists and can be restored.
5. Remove accounts and plugins you no longer use.

These five actions prevent a large share of common compromises.

Hosting and server

Use a reputable host

A cheap host is not automatically insecure, but the cheapest tier often lacks isolation, backups, and timely patching.

Look for:

• Regular security updates
• Isolated environments
• Automated backups
• A clear incident policy
• A supported stack

Keep the server patched

If you manage a VPS, you own the updates. Enable unattended security updates where possible, and reboot when the kernel requires it.

Close unused ports

Only expose what the application needs. A database should not be reachable from the public internet. An admin panel should be restricted by IP or a private network when possible.

Use a firewall or WAF

A web application firewall filters common attacks and can rate-limit abusive traffic. It is not a substitute for secure code, but it raises the cost of automated scanning.

Accounts and access

Unique passwords and MFA

Every admin account needs a unique password and multi-factor authentication. Use a password manager so this is practical.

If you are choosing one for a team, the business password manager guide covers shared vaults and offboarding.

Least privilege

Not everyone needs administrator access.

Define roles:

• Owner: billing and account recovery
• Administrator: site configuration
• Editor: content only
• Analyst: read-only reporting

Remove access when a role changes. Review the list quarterly.

No shared admin accounts

A shared login makes an audit impossible. Every person should have their own account, even if two people do the same job.

Protect the login page

• Use a strong password policy.
• Enable MFA.
• Limit login attempts.
• Consider restricting access by IP for the admin area.
• Do not use "admin" as the username.

Software and dependencies

Update the CMS and plugins

Outdated plugins are one of the most common entry points. Remove plugins you do not use. Update the rest.

Before updating, take a backup. After updating, test the critical flows: login, forms, checkout, and the homepage.

Update dependencies

If you run a custom application, keep the framework and libraries current. A dependency scanner in CI can catch known vulnerabilities before deploy.

Do not ignore a critical advisory because the upgrade is inconvenient. Schedule it.

Remove what you do not need

Every plugin, theme, and package is code you did not write and must trust. Fewer moving parts means a smaller attack surface.

Data and backups

Back up automatically

A backup should be:

• Automatic
• Encrypted
• Stored separately from the server
• Tested by restoring

A backup you have never restored is a hope, not a backup.

Define retention

Keep daily backups for a short window, weekly backups for a longer one, and a monthly archive if the business needs it. Balance storage cost against recovery needs.

Protect sensitive files

Do not store passwords, API keys, or private documents in a public directory. If a file does not need to be public, put it outside the web root or behind authentication.

Secrets belong in environment variables or a secrets manager, not in the repository.

Forms and user input

Validate on the server

Client-side validation improves the experience. It does not provide security. Validate every input again on the server.

Protect against spam

Use a honeypot, rate limiting, and a challenge only when needed. A CAPTCHA on every form hurts conversion.

Escape output

Any data rendered into HTML must be escaped. If you use a framework, use its safe rendering APIs and avoid injecting raw HTML from user input.

Limit file uploads

If the site accepts uploads, restrict file types, size, and storage location. Never execute uploaded files.

HTTPS and headers

Use HTTPS everywhere

Redirect HTTP to HTTPS. Use a valid certificate and renew it automatically.

Add security headers

Useful headers include:

• Strict-Transport-Security
• X-Content-Type-Options: nosniff
• Referrer-Policy
• Permissions-Policy
• Content-Security-Policy where feasible

A Content Security Policy takes effort to configure, but it reduces the impact of injected scripts.

Keep TLS current

Disable old protocols and weak ciphers. Most managed hosts handle this, but verify.

Monitoring and response

Log what matters

Keep logs for:

• Login attempts
• Admin actions
• Errors
• Deploys

Review them after an incident, and set alerts for repeated failures.

Monitor uptime and changes

An uptime monitor tells you the site is down. A file-integrity monitor tells you something changed. Both are useful.

Write a one-page incident plan

It does not need to be elaborate. It needs to answer:

1. Who do I call?
2. How do I take the site offline safely?
3. Where is the backup?
4. How do I rotate credentials?
5. How do I tell customers?

Practice it once. An incident is not the time to discover that nobody knows the hosting password.

A quarterly review

Once every three months:

• Update everything.
• Review admin accounts and permissions.
• Restore a backup to a staging environment.
• Check certificate expiry.
• Review form spam and blocked traffic.
• Read the host's security notices.
• Remove unused plugins and accounts.

One hour, four times a year, is enough for most small sites.

Common mistakes

• Assuming the host handles everything. Shared responsibility is real.
• Never testing backups. The restore is the product.
• Too many admins. Access accumulates quietly.
• Ignoring plugin updates. The most common door is the oldest one.
• Storing secrets in code. Repositories get copied.
• No incident plan. Panic is not a process.
• Security without privacy. Protecting the site is not the same as respecting user data. Read the digital privacy guide for that side.

Final thoughts

Website security is maintenance, not a one-time installation.

Close the obvious doors: updates, passwords, backups, access, and input validation. Then review quarterly.

You will not make the site invulnerable. You will make it a less attractive target than the thousands of sites that never did the basics.

If you want to review your account security first, start with why your business probably has a password problem. If you are building a new site, the secure-by-default templates in the store can save configuration time.

Keep reading

• Business password managers: how to protect your team
• Digital privacy: why protecting your data matters
• Your business probably has a password problem

---

Follow The Medamine for more insights on web development, AI, productivity, and digital business.