Small Business Website Security: The Real Checklist

Almost every hacked small business website we've looked at was compromised the same boring way. Nobody picked the business. A bot walked the internet, found a version number in the page source matching a publicly documented vulnerability, and used it. The plugin in question had usually been abandoned by its author two years earlier, and nobody had opened the admin panel since launch.

That's the part the security industry undersells, because it doesn't sell anything. Small Australian businesses are rarely targeted. They're swept — by automated scanners that neither know nor care what the business does, hunting for known holes anyone can spot from the outside in under a second. The scanner doesn't check whether you're a plumber in Ballarat or a law firm in Sydney. It checks whether your contact form plugin is on version 5.2.

Which makes the defence unglamorous and cheap: website security for a small business is a maintenance problem, not a product problem. Nothing you can buy replaces the five habits below. The businesses that get burned are rarely the ones who skipped a security tool; they're the ones who stopped updating.

What actually gets small sites hacked

Four causes account for the overwhelming majority of what we see on Australian small business sites. None are sophisticated.

Outdated plugins and themes. If your site runs WordPress — and statistically it probably does — this is the number one entry point by a wide margin. Researchers who track WordPress vulnerabilities consistently find the great majority sit in plugins and themes rather than core. Core updates itself reasonably well now; the nineteen plugins someone installed in 2021 do not. Every plugin is third-party software with full database access, maintained by a stranger who may or may not still be alive to the job.

Reused admin passwords. The second entry point isn't a hole in your site at all. It's a password that appeared in somebody else's breach three years ago, tried against your login page by a bot working through a list. Credential stuffing works because people reuse passwords, and it costs the attacker nothing to try.

Cheap shared hosting and forgotten copies. On low-end shared hosting, a compromise on a neighbouring account can sometimes reach yours. More often the problem is debris: an /old folder from the last redesign, an unprotected staging copy at dev.yourdomain.com.au, a WordPress install someone put at /blog in 2019 and forgot. Live, public, unpatched software, found as easily as your homepage.

Unprotected forms. Enquiry forms get abused constantly — not usually to break in, but to pump spam through the site or use your mail server to send junk that damages your domain's sending reputation. A nuisance, right up until your legitimate email starts landing in spam folders. We've covered how to stop contact form spam without wrecking conversion.

Notice what isn't on that list. No zero-days. No targeted attacks. "We're too small to be a target" misreads the mechanism — you're not a target, you're a result in a scan, and being small doesn't remove you from the scan.

The five basics that stop nearly all of it

That's the list, and most of the defence available to a business without a security team. The Australian Signals Directorate publishes a baseline called the Essential Eight at cyber.gov.au, aimed at internal IT rather than websites — but four of its controls map onto the five above almost exactly: patch applications, multi-factor authentication, restrict administrative privileges, regular backups. When the national cyber agency and a web studio arrive at the same list independently, it's probably the list.

The one everybody gets wrong

Nearly every business we ask says yes, we have backups. Far fewer can say where they're stored, how far back they reach, or whether anyone has ever restored one — and those questions matter more than the backup's existence.

If backups sit on the same server as the site, a compromise takes both. If they only reach back seven days and the injection happened three weeks ago, every copy you own is already infected; you'll restore the hack. And if nobody has run a restore, you'll learn how during the worst hour of your year.

Do it once, to a staging environment, and write down how long it took. That's your real recovery time, and usually the difference between a bad afternoon and a bad fortnight. Certificates are the other thing people over-trust: free through Let's Encrypt and automatic on most hosts, which makes the padlock table stakes rather than a security programme.

Why a custom build has less to go wrong

A custom studio is obviously not a neutral party here, so here's the honest version.

A static or pre-rendered site has a structurally smaller attack surface than a CMS-driven one, and the reason is arithmetic rather than craft. No public admin login to brute-force. No database behind a form. No plugin ecosystem — the thirty third-party packages a typical WordPress site inherits simply don't exist. What gets deployed is generated HTML with no server-side application behind it — there's nothing running on the page's address for a scanner to exploit. The dynamic parts that remain — enquiry form, booking step, payment handoff — are a handful of narrow endpoints you can reason about individually rather than a whole application you have to trust. That's why our small business website builds sit outside the plugin update treadmill, and why the ongoing bill lands below what WordPress actually costs to maintain.

The caveats are equally real. Custom is not a synonym for secure. Custom code has its own bugs, and framework dependencies still need updating — a build nobody has touched in three years carries known vulnerabilities exactly the way a stale plugin does. A badly built custom site with a hand-rolled login and no rate limiting is comfortably worse than a well-maintained WordPress one. The advantage is less surface to defend, and being able to see all of it — not that it defends itself.

So if you're on WordPress and it's working, the answer isn't a panicked rebuild. It's a maintenance arrangement with a name attached — a cheaper conversation, and one we cost out in our breakdown of website maintenance in Australia.

The legal bit: Notifiable Data Breaches, in one paragraph

Australia's Notifiable Data Breaches scheme sits under the Privacy Act and is run by the Office of the Australian Information Commissioner. If a covered organisation has a breach likely to cause serious harm to the people whose information was exposed, it must assess that breach promptly and notify both the OAIC and the affected individuals. The wrinkle for small business is a long-standing exemption: businesses under a $3 million annual turnover threshold generally fall outside the Act. But the exceptions swallow much of the rule — health service providers are covered regardless of size, as are businesses that trade in personal information — and the exemption has been flagged by government as a candidate for removal in ongoing privacy reform. Check the OAIC's current position rather than planning around it, and if you're a clinic of any size, assume you're covered.

The commercial point is simpler: whether or not you're obliged to tell customers their details leaked, you'll have to tell them anyway.

What cyber insurance now asks about your website

Cyber cover has tightened, and the proposal forms have gone from a page to an interrogation. The questions that keep appearing are the ones you'd expect from the list above: is multi-factor authentication enabled on email and administrative accounts, how often is software patched, are backups held offsite, have restores been tested, is any end-of-life software still running, who has privileged access.

Two things follow. First, the insurer is working from the same short checklist we are — decent independent confirmation it's the right one. Second, those answers usually form part of the basis of the policy. Ticking "yes, MFA is enabled everywhere" when it's on two accounts out of nine isn't a small inaccuracy; it's the kind of thing examined closely at claim time. Answer against what's true today, fix the gaps, then update the answer.

FAQ

How do I know if my website is secure?

You can't know from the outside, but you can rule out the common failures in twenty minutes. Check that HTTPS is enforced on every page and the certificate isn't near expiry. Log into the admin and count pending updates and user accounts. Ask your host where backups live and how far back they reach. Search your own domain for forgotten subdomains and old folders. Four clean answers puts you ahead of most small business sites.

Does an SSL certificate mean my website is secure?

No. An SSL or TLS certificate encrypts the connection between browser and server, stopping someone on the same wifi reading what's submitted. It says nothing about whether the site has been compromised or whether your plugins are current. Certificates are free and automatic now, so the padlock is a minimum requirement, not an achievement — plenty of malicious sites display one.

How often should a small business website be updated for security?

Monthly is the realistic baseline for a CMS-driven site, with critical patches applied as they're released rather than held for the monthly pass. A custom-built site needs its dependencies reviewed on a similar cadence, even though there's less to update. Frequency matters less than ownership: a named person responsible beats an ambitious schedule nobody runs.

What should I do first if my website has been hacked?

Take a forensic copy before changing anything, then change every password — hosting, CMS, registrar, and the email account those accounts recover to. Don't restore from a backup until you know when the compromise started, or you'll restore the compromise. If the site was flagged in search results, the cleanup order matters a great deal; we've set out the sequence in our guide to recovering rankings after a hack.

Do small businesses have to report a data breach in Australia?

It depends on whether the business is covered by the Privacy Act. Many businesses under $3 million in annual turnover currently sit outside it, but health service providers and several other categories are covered at any size, and the exemption is under review. If you're covered and the breach is likely to cause serious harm, you must assess it promptly and notify both the OAIC and the affected individuals.

Where to start this week

Take the thirty-minute version first. Turn on multi-factor authentication for your hosting, your domain registrar and the email address those accounts recover to — the highest-value single change available, and it costs nothing. Remove every admin user who no longer works with you. Look up your business email addresses on Have I Been Pwned and change anything that appears in a breach.

The next hour: ask your host where backups live and how far back they reach, then restore one to staging and time it. Delete the old staging sites, the abandoned installs, and every plugin nobody uses.

For a fast read on the publicly visible half of this, run your site through our free audit — whether HTTPS is properly enforced, and what's exposed on the surface. Be clear about what it isn't: not a vulnerability scan, and it won't tell you a plugin is three years stale. For that, someone has to open the admin panel. The argument of this whole piece is that somebody should, on a schedule, with their name on it.