Website security checklist for small businesses (2026)

Small business websites do not get hacked because someone targeted them. They get hacked because a bot scanned forty thousand IP addresses looking for one specific outdated plugin, and one of those addresses was yours. The attacker never heard of your company and never will.

That is genuinely good news, because opportunistic attacks are defeated by unglamorous, cheap, boring controls. You do not need an enterprise security programme. You need about twenty things done correctly and kept that way.

This is the checklist we work through on client sites, in the order the risk actually justifies.

How small business sites actually get compromised

Before the fixes, the honest distribution of causes. Across the sites we have been called in to clean up, the pattern is remarkably consistent:

• Outdated CMS plugins and themes. By a wide margin the leading cause. A vulnerability is disclosed, exploit code circulates within days, and mass scanning begins within hours of that.
• Weak or reused admin credentials. Usually an old account belonging to someone who left the company two years ago.
• No multi-factor authentication on the CMS, the hosting panel, the domain registrar or the email account that can reset all three.
• Compromised third-party scripts. A marketing tag, chat widget or analytics snippet that gets hijacked and starts skimming form data.
• Exposed backups, .env files and database dumps sitting in a publicly readable directory.
• Abandoned staging sites on a subdomain, unpatched, unmonitored, and connected to the production database.

Note what is not on that list: sophisticated zero-days and targeted intrusions. Those exist, but they are not what takes down a fifteen-person firm in Chandigarh.

Tier 1: do these this week

1. Multi-factor authentication on the four accounts that matter

Not just the website. The chain of control runs: domain registrar, DNS provider, hosting or platform account, CMS admin, and the email inbox that can reset every one of them. An attacker who takes your registrar account owns your domain, your email and your site, and the site itself was never touched.

Use an authenticator app or hardware key. SMS is better than nothing and worse than everything else, because SIM swap fraud is routine in India and elsewhere.

2. Audit and remove stale accounts

List every user with access to the CMS, the host and the registrar. For each, answer: does this person still work here, and do they still need admin rights? Former employees, former agencies and one-off contractors are a standing liability. Delete, do not merely deactivate.

3. Patch everything, on a schedule

Set a recurring calendar entry. Core CMS, plugins, themes, server packages, and the dependency tree of any custom application. Enable automatic security updates where the platform supports it. Where auto-update is risky (a plugin that has broken your checkout before), the answer is a staging environment and a fortnightly manual window, not indefinite postponement.

Uninstall anything you are not using. An inactive plugin is still code on disk, and in several well-known cases it was still exploitable.

4. HTTPS everywhere, with HSTS

Certificates are free and automatic now, so this is purely an oversight problem. Force HTTP to HTTPS at the server, and add a Strict-Transport-Security header so browsers refuse plaintext on repeat visits. Check that no page loads a mixed-content asset over HTTP, which silently breaks the guarantee.

5. Real backups, stored somewhere else

A backup on the same server as the site is not a backup, it is a second copy of the thing that will be encrypted. You want:

• Automated daily backups of files and database.
• Retention of at least 30 days, so you can go back past a compromise you did not notice immediately.
• At least one copy on separate infrastructure with separate credentials.
• A restore you have actually tested. Untested backups fail at roughly the rate you would fear.

Tier 2: do these this month

6. Security headers

A handful of response headers close whole categories of attack, and they cost one configuration change:

• Content-Security-Policy: the highest-value and highest-effort one. It controls which scripts may run, which is your defence against injected skimmers.
• Strict-Transport-Security: forces HTTPS.
• X-Content-Type-Options: nosniff: stops content-type guessing.
• Referrer-Policy: stops leaking full URLs to third parties.
• Permissions-Policy: switches off camera, microphone and geolocation access you never use.
• X-Frame-Options or a CSP frame-ancestors directive: prevents clickjacking.

7. Inventory and pin your third-party scripts

Open your site, look at what loads, and ask of each tag: do we still use this, and who controls the server it comes from? Every third-party script runs with full access to your page, including your forms. Remove what you do not need. For what remains, use subresource integrity where the vendor supports it, and constrain everything with CSP.

This is the same class of attack that hit thousands of e-commerce checkouts through injected payment skimmers, and it is why the current PCI DSS rules require continuous monitoring of payment pages. Our PCI DSS guide covers that in detail if you take card payments.

8. Lock down the admin surface

• Move the login path off the default where your CMS allows it. Weak on its own, useful against dumb bots.
• Rate-limit login attempts and lock accounts after repeated failures.
• Restrict admin access by IP if your team works from predictable locations.
• Disable file editing from inside the CMS admin, a favourite persistence mechanism.
• Use role-based accounts. Your content editor does not need administrator.

9. Protect your forms

Every public form is an input into your systems and an outbound spam vector. Validate on the server, never only in the browser. Add rate limiting per IP. Use a modern anti-bot check rather than a puzzle that punishes real users. Escape everything before it reaches a database query or a page render.

10. Email authentication: SPF, DKIM and DMARC

Without these records, anyone can send mail that appears to come from your domain, and invoice fraud against your customers becomes trivially easy. Publish SPF and DKIM, then move DMARC from none to quarantine to reject as you confirm your legitimate senders are passing. This also materially improves your deliverability, so it pays for itself twice.

11. Remove what should not be public

Go looking for: .git directories, .env files, database dumps, phpinfo pages, directory listings, README files that disclose versions, old staging subdomains, and backup archives named something like site-backup-final.zip. Attackers check for all of these by name, automatically, on every site they scan.

12. Set up monitoring you will actually notice

Uptime monitoring, file integrity monitoring, and alerts on new admin user creation. The average time from compromise to discovery on an unmonitored small business site is measured in months, and almost every one of those is discovered by a customer or by Google flagging the site, which is the worst possible way to find out.

Tier 3: the quarterly rhythm

• Review access across CMS, host, registrar, analytics and payment tooling.
• Rotate credentials for shared accounts and API keys, especially after anyone leaves.
• Test a restore from backup into a scratch environment.
• Scan dependencies for known vulnerabilities and update accordingly.
• Re-check headers and TLS configuration, which drift as infrastructure changes.
• Check your domain expiry and registrar contact email. A domain lost to an expired card or a dead inbox does more damage than most breaches, and it happens far more often.

What to do in the first hour of a compromise

If you find yourself here, the order matters. Panic-deleting evidence is the most common and most costly mistake.

• Take a forensic copy first. Snapshot files, database and logs before you change anything. You will need them to work out how they got in.
• Contain. Take the site offline or into maintenance mode if data is actively being exfiltrated or malware is being served to visitors.
• Rotate every credential. CMS, database, hosting, registrar, API keys, email. Assume all of them are known.
• Restore from a backup predating the compromise, then patch the entry point before going live. Restoring without patching gets you reinfected within days.
• Check for persistence. New admin users, scheduled tasks, modified core files, injected code in theme templates, unfamiliar entries in your DNS.
• Meet your notification duties. Depending on where you and your users are, you may have obligations under the DPDP Act, GDPR or the CERT-In directions, and some of those clocks are measured in hours, not days.
• Write it down. What happened, when you found it, what you did. You will want this for regulators, insurers and your own next review.

What this costs

Most of the Tier 1 list is free, and takes a competent person a day. Realistic budgets for the rest:

• Hardening pass on an existing site: ₹25,000 to ₹90,000 one-time, depending on stack and mess.
• Managed backups, monitoring and patching: ₹4,000 to ₹20,000 per month.
• Cleaning up after a compromise: ₹40,000 to ₹3,00,000, plus the downtime, plus the customers who saw a malware warning on your homepage.

The asymmetry is the whole argument. Prevention is a predictable line item. Recovery is not, and it arrives at the worst possible time.

How RoseLeap can help

Vigil, our security audit tool, checks the external half of this list automatically: headers, TLS, exposed files, email authentication records, and known-vulnerable components. It is built for businesses that will never hire a security team.

For the ongoing half, our hosting & maintenance plans cover patching, backups, monitoring and the quarterly review, so none of it depends on someone remembering. Tell us what you are running on the contact page and we will tell you what we would fix first.