The uncomfortable truth about small business website security is that almost nobody is hunting you specifically. You are being harvested. Automated scanners sweep the internet for known-vulnerable component versions, exposed configuration files, and login pages that accept unlimited guesses, then monetise whatever they find.
That is good news, because opportunistic attacks fail against unglamorous controls. Here is the 2026 checklist, in priority order, that an SME can actually finish.
Start With the Five Controls That Stop Most Automated Attacks
If you do only five things, do these: force HTTPS everywhere, put phishing-resistant multi-factor authentication on every administrative account, remove unused accounts and plugins, keep one backup outside the hosting account that you have actually restored, and patch known vulnerabilities on a defined clock. Those five defeat the overwhelming majority of opportunistic compromises.
Everything else in this checklist is valuable, but sequence matters more than completeness. Teams that try to do all of it at once usually finish none of it. Work top down, mark each item done with a date and an owner, and revisit quarterly. If you want the wider organisational view rather than the website-specific one, Cybersecurity for Startups: The Minimum You Need Before Launch covers the same triage logic across the whole company.
HTTPS, HSTS, and Certificate Hygiene
Every request, on every hostname, over TLS, with automated renewal and an alert if renewal fails. Then add HSTS so browsers refuse to downgrade to plain HTTP. Certificates are free and automatable now, so an expired certificate in 2026 is a monitoring failure, not a budget problem.
- ▸Redirect all HTTP to HTTPS with a permanent redirect, covering www and non-www and every subdomain.
- ▸Automate renewal and alert at 30, 14, and 7 days if renewal has not completed. Monitor the hostnames people forget: mail, staging, and any API subdomain.
- ▸Add HSTS with a long max-age once you are confident every subdomain serves HTTPS. Treat preloading as a one-way door and only submit when you are certain.
- ▸Fix mixed content. A single insecure image or script reference undermines the padlock and can break functionality.
- ▸Modern TLS only. Disable legacy protocol versions and weak cipher suites, then re-test after any host migration, because hosting moves quietly reset this.
Admin Access, MFA, and Least Privilege
Every account that can change the site needs MFA and the smallest role that does the job. That means the registrar, DNS, hosting panel, CMS, email, repository, and payment processor. Prefer passkeys or hardware security keys. Codes over SMS are better than nothing and worse than everything else. Shared logins are unacceptable at any company size.
- ▸Individual named accounts. Never a shared administrator login, because it destroys attribution and survives offboarding.
- ▸Phishing-resistant MFA on the registrar first. Domain theft is one of the few incidents that can end a small company outright.
- ▸Registrar lock enabled, with the registrar account tied to an address that is not hosted on the domain itself.
- ▸Rate limit and monitor the login path, and disable user enumeration where the platform allows. Obscuring the admin URL is not security, but it removes an enormous amount of noise.
- ▸Editors get editor rights. Administrator is the role attackers want, so it should be rare, deliberate, and boring.
- ▸Quarterly access review, written down. Delete rather than demote. Old agencies, former contractors, and dormant FTP accounts are the classic finding, and What Security Auditors Find in Almost Every Admin Panel is mostly a catalogue of exactly this debt.
- ▸Session hygiene. Reasonable timeouts, and revoke active sessions on role change or departure.
Know Everything Your Site Actually Runs
You cannot patch what you have not inventoried. Write down the CMS core version, every plugin, theme and package with its version and last update date, the server runtime, and every third-party script executing on the page. Review it monthly. Delete anything you cannot justify keeping.
The mechanism matters more than any statistic. Most SME site compromises trace back to a third-party extension rather than the core platform, because extensions add REST routes, admin endpoints, upload handlers and shortcodes while inheriting the site's full privileges. The recurring risk classes are unauthenticated privilege escalation, arbitrary file upload, stored cross-site scripting reachable from a public form, injection through unsanitised parameters, and missing authorisation checks on REST routes.
- ▸Abandonment is the real danger. A plugin whose author stopped shipping fixes keeps working flawlessly while going unpatched, so nothing looks broken until it is.
- ▸Deactivated is not removed. Files left on disk remain reachable in many configurations. Delete, do not disable.
- ▸Audit your third-party scripts too. Chat widgets, tag managers and ad pixels are code you did not write, running in your customers' browsers.
- ▸Verify vendor-specific claims against the vendor advisory and the public vulnerability record before acting. The wider pattern is covered in Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk.
- ▸Agree patch deadlines by severity with whoever maintains the site: hours for actively exploited criticals, days for high severity, a monthly batch for routine updates.
Backups You Have Actually Restored
Keep at least one backup copy outside the hosting account, make it immutable or write-once where supported, and restore it end to end at least quarterly. Record how long the restore took. If you have never restored, you do not have backups, you have files and an assumption.
- ▸Cover everything. Database, uploads, configuration, and an exported copy of DNS and TLS settings.
- ▸Retention long enough to predate a slow compromise. Attackers frequently persist quietly for weeks, so short retention can mean every copy you hold already contains their access.
- ▸Restore into a clean environment, not over the top of the live site, and confirm the restored site actually functions rather than merely loading.
- ▸Protect the backup credentials with the same MFA rules as everything else, because deleting backups is a standard step in modern extortion playbooks.
WAF, Rate Limiting, and Form Abuse
A web application firewall and rate limiting buy you time. They do not fix vulnerable code, but they blunt credential stuffing, mass scanning, and the burst traffic that turns a small bug into an outage. For most SMEs, the managed WAF in front of a CDN is the best value control you can enable this week.
- ▸Rate limit login, password reset, search, and every form endpoint, per source address and per account.
- ▸Use backoff, not permanent lockout. A permanent lockout on failed logins is a denial-of-service tool pointed at your own users.
- ▸Forms need server-side validation, a honeypot field, and a challenge only where abuse justifies the friction. Never render a raw submission into an HTML email or an admin screen without escaping it.
- ▸File uploads: allowlist types, store outside the web root, rename on receipt, scan, and ensure the storage location cannot execute code.
- ▸Log blocked requests and review them. An unmonitored WAF is a black box that hides your own attack telemetry. Web Application Firewalls: Still Relevant in a Cloud-Native World explains where the boundary of usefulness sits.
Security Headers and the Browser Controls You Get for Free
Security headers are the cheapest hardening available: a content security policy, HSTS, frame protection, referrer policy, and a permissions policy. They cost a deployment, not a project. The content security policy is the one with real teeth, and the one worth rolling out carefully in report-only mode first.
- ▸Content-Security-Policy. Start report-only, fix what breaks, then enforce. It is what turns a stored scripting flaw from a full takeover into a blocked console message.
- ▸Strict-Transport-Security, matching your HSTS decision above.
- ▸X-Content-Type-Options set to nosniff, plus frame-ancestors in your policy to prevent clickjacking.
- ▸Referrer-Policy so you stop leaking full URLs to third parties.
- ▸Permissions-Policy switching off camera, microphone and geolocation you do not use.
- ▸Cookies marked Secure, HttpOnly, and SameSite on anything session related.
- ▸Close the leaks. Remove version banners, disable directory listing, and block public access to version control directories, environment files, database dumps, and editor backup files. These are staple scanner targets and an embarrassing number of SME sites serve them happily.
The First Hour of a Suspected Compromise
Preserve evidence, then contain. Do not delete files, do not reinstall on top, and do not let a well-meaning helper clear the logs. Snapshot first, rotate credentials from a clean device, restrict access, and write down times. The first hour decides whether you can answer the questions that arrive in week two.
- ▸Snapshot before you change anything. Server, database, and logs. Copies, never moves.
- ▸Contain. Maintenance mode or offline, especially if payments or personal data are in scope.
- ▸Rotate credentials from a device you trust: hosting, CMS administrators, database, API keys, SMTP, payment gateway, and registrar. Revoke active sessions and tokens.
- ▸Find the entry point before restoring. Restore without it and you either recreate the hole or restore the backdoor along with the content.
- ▸Call your incident contacts. Developer, host, insurer, and your data protection adviser or lawyer if personal data may be involved. Under the GDPR, breach notification duties run on a tight clock from the moment you become aware, so start that clock consciously and take advice on your specific situation.
- ▸Keep a written timeline from the first observation onward, with timestamps and who did what.
Decide all of this before you need it. A one-page contact sheet with names, numbers, and account owners beats an improvised group chat at midnight, and Incident Response Playbooks That Teams Actually Use shows what a workable version looks like at small scale.
How TuniCyberLabs helps
We run this checklist as a fixed-scope hardening engagement for SMEs: inventory and patch plan, access and MFA cleanup, backup and restore drill, WAF and rate-limit configuration, headers, and a one-page incident sheet with your real contacts on it. Small, finite, and verifiable.
Want it done rather than filed? See how we work and we will scope it against your actual stack.