Simon Paul
Simon Paul

The Boring Security Work That Prevents the Interesting Incident

A maintenance checklist and keys on a workbench beside a secured server cabinet, representing the routine small business website security work that prevents incidents

Most of the businesses I’ve watched go through a security incident have said a version of the same thing afterwards: “why would anyone bother with us?”

It’s the right question with a slightly deflating answer. Nobody did bother with you. Nobody sat at a desk and picked your company. A program went looking for a particular weakness across every site it could reach, found it on yours, and did what it was written to do. You weren’t targeted. You were in the way.

That’s genuinely reassuring in one sense and unhelpful in another, because it means being small and uninteresting isn’t protection. It also means your website security doesn’t need to be sophisticated. Almost everything that actually happens to businesses of this size is prevented by a short list of dull tasks done regularly.

What actually happens to sites like yours

Three things, overwhelmingly, and none of them require sophisticated website security to prevent.

A known flaw in something you didn’t write. Modern software is assembled from components — plugins, libraries, frameworks. When a vulnerability is found in one, it’s published, so that everyone can patch. That same publication is a shopping list for automated scanning, and the window between disclosure and mass exploitation is now short. The overwhelming majority of compromised small business sites are running something with a fix that was available and not applied.

A password that was already known. Not guessed. Known, because it appeared in a breach somewhere else and the same one was used again. Credential stuffing is cheap, automated, and remarkably effective against businesses where the admin login has been the same since 2019.

Somebody was tricked. An invoice that looked right, a login page that looked right, a request from the boss’s email address that wasn’t. This is the one that lands hardest commercially and the one technology only partly addresses.

Notice what isn’t on the list. No one is writing a bespoke attack for a Sydney business with forty staff. The threat is ordinary, which is exactly why an ordinary defence works.

The boring website security list

Here it is. None of it is clever.

Apply updates, on a schedule. Particularly security updates to the components your site is built from. This one item prevents more incidents than everything else combined.

Multi-factor authentication everywhere it’s offered. Admin logins, hosting, domain registrar, email. It defeats the stolen-password problem almost entirely, and it takes an afternoon.

Give people the access they need, not all of it. Most people who have administrator rights on a website don’t need them. Fewer administrators means less to steal.

Remove access when people leave. Covered properly below, because it’s the one everybody fails.

Keep secrets out of the code. Passwords and API keys belong in configuration, not committed into a repository where they persist in the history long after somebody thinks they deleted them.

Encrypt traffic, and keep the certificate current. Universal now, and still the cause of a surprising number of outages when a renewal is missed.

Take backups. Then read the next section, because taking them is the easy half.

The backup you’ve never restored isn’t a backup

I want to dwell on this one, because it’s where confidence and reality diverge most sharply.

Plenty of businesses have backups running. Far fewer have ever restored from one. The two situations feel identical right up until the day they don’t, and that day is the worst possible time to discover the difference.

The failures are mundane and common. The backup ran nightly and captured the files but not the database. It captured everything but has been silently failing for five months and nobody read the emails. It’s complete and lives in the same place as the thing it’s backing up, so whatever took out one took out both. It restores perfectly and takes eleven hours, which nobody knew, and the business assumed it would be back within one.

The fix is unglamorous: actually restore one, to somewhere safe, and time it. Do it once a year. You’ll learn whether your backup works and how long recovery takes, which are the only two facts that matter about it, and neither can be established by looking at a dashboard.

Who has access to your systems right now?

Most business owners cannot answer this, and the answer is usually longer than they’d guess.

The developer who built the previous site. The contractor who helped with a campaign in 2023. The agency you stopped working with. Two former staff members. A plugin someone installed to try out and never removed, which still holds a connection to your data. A shared login that four people use, whose password hasn’t changed since it was created.

None of those people are a threat. That’s not the point. Each is an additional route in, sitting outside your control, on a laptop or in a password manager or a text file you’ll never see. When one of them is compromised for reasons that have nothing to do with you, your systems are what’s exposed.

Listing who has access to what, and removing everything that isn’t currently needed, takes an afternoon and closes more risk than most things you could buy.

What “we’ll deal with it if it happens” costs

The direct costs are the visible ones: the site down, the clean-up, the rebuild from a backup that may or may not exist, the emergency rates.

The one businesses don’t anticipate is the obligation. Under the Notifiable Data Breaches scheme in the Privacy Act 1988, mandatory in Australia since February 2018, organisations covered by the Act must assess and, where a breach is likely to result in serious harm, notify both the affected individuals and the Office of the Australian Information Commissioner. If customer data was involved, “quietly fix it and say nothing” may not be legally available to you. The disclosure is frequently more damaging than the incident.

Then there’s the part nobody invoices for: two weeks of senior attention consumed entirely, at whatever moment it happens to land.

A proportionate answer

I’m not suggesting a website security programme. A business of forty people doesn’t need a security operations centre, and being sold one is its own kind of problem.

What’s proportionate is the boring list, done on a schedule, by someone whose job it explicitly is. Updates applied monthly. MFA on everything. An access review twice a year. One restore test annually. Secrets out of code. That’s most of the realistic risk, addressed for a modest ongoing cost, with no drama.

The reason it doesn’t happen isn’t cost or difficulty. It’s that none of it is ever urgent, right up until the morning it’s the only thing that matters. Give it to someone as a standing responsibility, or you’ll be relying on remembering — and the one thing everybody’s diary agrees on is that this is the task that moves.

Not sure who has access to your systems?

Contact our team to get the boring list done properly.


Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He has never once seen an incident that a monthly update schedule and a tested backup wouldn’t have made survivable. Reach out to Simon to talk through what your business should have covered.