Website Security Checklist for Small Business Owners

A website security checklist is the shortest path from "I hope we're fine" to "I know what's exposed." If you run a small business website and do not have a security team, you do not need an enterprise security program — you need a repeatable list of the things attackers actually exploit, worked through top to bottom, and revisited on a schedule.

This guide is that list. Ten items, in priority order, written for a business owner rather than an engineer. Each one explains what to check, why it matters, and what "done" looks like. You can hand most of this to whoever maintains your site.

The short version

If you only do the first four items on this list, you will have closed the majority of the openings that automated attacks rely on:

1. Enforce strong, unique credentials and multi-factor authentication on every admin account
2. Patch your platform, plugins, themes, and dependencies on a schedule
3. Force HTTPS everywhere and configure your security headers
4. Remove what you no longer use — old plugins, stale subdomains, forgotten admin accounts
5. Protect the customer data you collect
6. Keep secrets out of your source code
7. Map your full attack surface, including subdomains
8. Back up your site and test that the restore actually works
9. Monitor continuously and route alerts to somewhere a human reads
10. Write down what happens when something goes wrong

1. Lock down access and authentication

Credential attacks remain one of the most common ways into a small business website, and they are almost entirely automated. Bots try leaked username and password pairs against login forms at scale, which is why a password reused from a breached service is a live risk even if your site itself has never been attacked.

Check:

• Every administrative account uses a unique password stored in a password manager, never reused anywhere else
• Multi-factor authentication (MFA) is enabled on the site admin panel, the hosting control panel, the domain registrar, and the DNS provider — the registrar and DNS accounts are frequently forgotten and are the most damaging to lose
• Accounts are scoped by role: content editors do not need administrator rights
• Former employees, ex-contractors, and old agency accounts have been removed, not just deactivated
• The default admin username (admin, administrator) has been changed where the platform allows it
• Login attempts are rate-limited or lockout-protected

Done looks like: a current list of every account with access to your site, hosting, domain, and DNS, with a named owner for each.

2. Keep every piece of software patched

The overwhelming majority of successful attacks against small business sites exploit a vulnerability that already had a fix available. Verizon's Data Breach Investigations Report has repeatedly found that exploitation of known vulnerabilities is a leading initial access vector, and the window between a vulnerability becoming public and mass automated exploitation is now measured in days.

Check:

• Your content management system core is on a supported, current version
• Every plugin, theme, extension, and module is updated — and anything you are not actively using is deleted, not just disabled
• Your server software, runtime (PHP, Node, Python), and database are within support
• Third-party libraries in your codebase are checked against vulnerability databases
• You have a defined patching cadence: critical fixes within days, everything else monthly

Done looks like: a monthly recurring calendar entry with a named owner, plus a way to be told about critical issues in between.

3. Encrypt traffic properly

HTTPS is the baseline, not the finish line. A valid certificate proves traffic between the visitor and your server is encrypted. It says nothing about whether your application has SQL injection, whether your admin password is Summer2026, or whether your database is publicly reachable.

Check:

• HTTPS is enforced site-wide with HTTP requests redirected, not merely available
• Your certificate is valid, not self-signed, and set to auto-renew — expired certificates cause outages and erode trust
• Old TLS versions (1.0 and 1.1) are disabled
• No mixed content: every image, script, and stylesheet loads over HTTPS
• Cookies carrying sessions are marked Secure and HttpOnly

4. Configure your server and headers correctly

Security misconfiguration is one of the OWASP Top 10 categories and one of the most common findings on small business sites, precisely because it is invisible from the front end. The site looks perfect while a configuration file sits publicly readable.

Check:

• Directory listing is disabled
• Backup files, .env files, .git directories, and database dumps are not reachable from the web — this is a routine finding and a routine breach cause
• Admin panels are not exposed on predictable public paths without additional protection
• Security response headers are set: Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy, and a frame-protection policy
• Verbose error messages are turned off in production — stack traces tell attackers what you are running
• Default credentials on any installed software have been changed

5. Protect the data you collect

Every field you collect is a liability you now have to defend. The cheapest way to protect customer data is to not hold data you do not need.

Check:

• You can list what personal data you collect, where it is stored, and who can reach it
• Data you no longer need is deleted on a defined retention schedule
• Payment card data is handled by a payment processor, never stored on your own server
• Database access is restricted to the application, not open to the public internet
• Backups containing personal data are encrypted
• File uploads are validated by type and size, and stored outside the web root

6. Keep secrets out of your source code

Credential leakage — API keys, database passwords, and access tokens committed into a code repository — is one of the fastest-growing causes of breach, and it does not require your website to be vulnerable at all. Once a secret is committed, it lives in the repository history even after it is deleted from the current files.

Check:

• No API keys, tokens, private keys, or passwords appear anywhere in your repository, including old commits
• Configuration secrets are supplied through environment variables and never committed
• Repository access is limited to people who currently need it, with MFA enforced
• Any secret that was ever exposed has been rotated, not just removed

7. Map your full attack surface

Attackers do not restrict themselves to your homepage. A forgotten staging server, an old marketing microsite, or a subdomain pointing at a service you cancelled are all part of your attack surface, and they are typically the least maintained systems you own.

Check:

• You have an inventory of every domain and subdomain you own
• Nothing points at a decommissioned service (this enables subdomain takeover, where an attacker claims the abandoned resource and serves content from your brand)
• Staging and development environments are not publicly accessible, and do not contain production data
• Your domain registration and expiration dates are tracked — a lapsed domain is a total loss of control

8. Back up, and test the restore

An untested backup is a hypothesis. Ransomware and destructive attacks are specifically designed to reach connected backups, which is why isolation matters as much as frequency.

Check:

• Backups run automatically on a schedule that matches how often your content changes
• At least one copy is stored separately from the live environment
• Backups are encrypted
• You have actually performed a restore and know how long it takes

9. Monitor continuously and route the alerts

Point-in-time checks tell you the state of your site on the day you looked. Your site changes, plugins update, dependencies drift, and new vulnerabilities are published daily. IBM's Cost of a Data Breach research has consistently shown that the longer a breach goes undetected, the more it costs — detection speed is one of the few variables you directly control.

Check:

• Your site is scanned on an ongoing schedule, not once a year
• Uptime and availability are monitored, with alerts when the site goes down
• Alerts arrive somewhere a person actually reads — email, Slack, Discord — not a dashboard nobody opens
• Someone is named as responsible for triaging what comes in

10. Write down what happens when something goes wrong

You do not need a formal incident response program. You need one page that someone can follow at 2am without improvising.

Check: who to call, how to take the site offline, where the backups are and how to restore them, how to rotate every credential, which customers and regulators may need to be notified, and where the logs are.

Common mistakes to avoid

• Treating the certificate padlock as security. HTTPS encrypts the connection. It does not make the application safe.
• Assuming you are too small to be a target. Automated scanning is indiscriminate — bots find exposed systems, not brands.
• Running the checklist once. A clean scan in January says nothing about March.
• Leaving unused plugins installed but deactivated. Deactivated code is often still reachable and still vulnerable.
• Fixing findings without rotating exposed credentials. Removing a leaked key from a file does not invalidate the key.
• No named owner. A checklist that belongs to everyone belongs to no one.

How often should you work through this list

• Continuously (automated): vulnerability scanning, dependency checks, uptime monitoring
• Monthly: patching, plugin and dependency updates, review of new findings
• Quarterly: access review, subdomain and asset inventory, backup restore test
• Annually: the full checklist end to end, plus a review of your incident plan

How Volturion helps

Most of this checklist is work that should not be done by hand, and Volturion automates the parts that decay fastest between reviews.

Volturion scans your public-facing websites and applications for the full OWASP Top 10 — including the security misconfigurations in items 3 and 4, exposed files, missing headers, and injection flaws — and checks against known CVEs affecting the platform, plugins, and frameworks you are running, covering item 2. Every finding is scored by severity and mapped to CWE and OWASP categories, so you can work the list in priority order instead of guessing.

For item 6, Volturion scans your code repositories for hard-coded credentials, API keys, and private keys, and checks your dependency manifests against vulnerability databases so you know which third-party packages are putting you at risk, tied to specific files and line numbers.

For item 7, Volturion automatically discovers the subdomains attached to your domains and brings them into continuous monitoring, tracks domain registration and expiration data, flags unauthorized name server changes, and captures screenshots and technology fingerprints so you can see your real attack surface rather than the one you remember.

For items 9 and 10, Volturion probes your sites around the clock and sends real-time alerts by email, Slack, Discord, or webhook the moment something breaks or a new risk appears — and for every finding, its AI writes step-by-step remediation guidance for your specific stack in plain language, so the checklist item does not stall waiting for someone who speaks security.

You can start with a free plan covering one domain and two code repositories, and work through this checklist with the findings in front of you instead of a blank page.