Nobody breaks into a small business website the way films depict it. There's no one at a terminal defeating your firewall. In practice someone logs in — with a password that leaked from an unrelated service three years ago, through an admin plugin that hasn't been updated since 2023, or using an API key that's been sitting in a public code repository since an intern pushed it.

That's genuinely good news, because it means the defence isn't exotic either. A handful of unglamorous controls, most of them free, remove the overwhelming majority of realistic risk. Here's the baseline we set up on every project, explained without jargon.

How do small websites actually get broken into?

Four routes account for nearly everything we've been called in to clean up. Recognising them tells you exactly where to spend your effort:

1. 01Stolen or reused credentials. A password you used elsewhere appears in a breach dump, and someone tries it against your hosting, email, or admin panel. Automated, indiscriminate, and by far the most common route.
2. 02Outdated software. A known flaw in a plugin, theme, or library gets published, scanners sweep the internet for sites still running it, and yours answers. The window between disclosure and mass exploitation is often days.
3. 03Leaked secrets. An API key, database password, or access token committed to a repository, pasted into a support ticket, or emailed. Bots scan public code continuously for exactly this.
4. 04Social engineering. Someone convinces your hosting support, your domain registrar, or an employee to hand over access. No technical flaw involved at all.

Notice what isn't on that list: clever exploits against your custom code. It happens, but it's far down the odds. Which is why the baseline below is mostly about accounts and hygiene rather than anything you'd call cybersecurity.

Start with accounts, not servers

Make an inventory of every account that could hurt you if someone else controlled it. For most businesses it's shorter than expected and includes things people forget are security-critical: your domain registrar, your DNS, your business email, your hosting and database providers, your code repository, your payment processor, your analytics, your social accounts, and your CMS or admin panel.

Two of those deserve special attention. Your domain registrar controls where your brand points — anyone with that access can redirect your website and intercept your email in minutes. And your business email is the master key: it's where every password reset arrives. Protect those two first and hardest.

Passwords, two-factor, and passkeys — what to actually use

Use a password manager for the whole team, make every password unique and generated rather than invented, and turn on a second factor everywhere it's offered. That's the entire policy. Complexity rules — a symbol, a number, a capital — matter far less than uniqueness, because the real threat is a password reused somewhere that got breached.

On second factors, the options aren't equal:

• Passkeys are the strongest and, increasingly, the easiest — you approve a login with your device's fingerprint or face. Because they're tied to the real site, they can't be handed to a convincing fake one. Use them where offered.
• An authenticator app generating six-digit codes is a solid second choice, and works everywhere.
• SMS codes are better than nothing, but treat them as the weak option: a determined attacker can persuade a mobile operator to move your number to their SIM, and then the codes arrive on their phone. Avoid SMS specifically on your registrar and your email.

One more habit worth building: stop sharing logins. Shared accounts mean you can't tell who did what, and you can't remove one person's access without disrupting everyone. Nearly every serious platform supports separate users with different permission levels. Use them.

Backups: the control that turns a disaster into a bad afternoon

A tested backup is the single most valuable thing on this list, because it's the only one that helps after something has already gone wrong — whether that's an attack, a bad deploy, a corrupted database, or someone deleting the wrong thing at 11pm.

Three rules cover it. Keep more than one copy, in more than one place, with at least one somewhere an attacker who compromised your main account couldn't reach — a backup stored inside the account that just got taken over is not a backup. Automate them, because manual backups quietly stop happening within about a month. And restore one, on purpose, before you need to.

That last point is the one people skip. A backup you've never restored is a hypothesis. We've seen backups that ran nightly for two years and turned out to contain no database, and backups that restored perfectly but took eleven hours nobody had planned for. Do a restore drill once, write down how long it took, and you've converted a hope into a plan.

Keep software current — and keep less of it

Every plugin, theme, package, and integration is code you didn't write running on your site, and each one is a door someone else maintains. When a flaw in a popular component is disclosed, mass scanning follows within days. Being a few weeks behind on updates is what turns a public disclosure into your problem.

The practical version for a small team: turn on automatic security updates where the platform offers them, put a recurring half-hour in the calendar to apply the rest, and — most effective of all — delete what you don't use. The deactivated plugin from a campaign two years ago is still installed, still reachable, and still exploitable. The most secure dependency is the one you removed.

Keep secrets out of your code

Passwords, API keys, and access tokens should never appear in your codebase, in a screenshot, in a support ticket, or in an email. They belong in environment variables or a secrets manager, which every modern hosting platform provides. Bots scan public repositories continuously; keys pushed by accident are often found and used within minutes.

If a key has ever been exposed, rotate it rather than deleting the commit — the history is already cloned elsewhere, and removing it from your repository doesn't un-publish it. Rotation is the only real fix, and it's usually a two-minute job you avoid because it feels like admitting a mistake.

Who has access — and who still has access?

Access accumulates. The freelancer from last year's redesign, the marketing agency you stopped working with, the developer who left in March, the analytics consultant who needed 'admin just for a week'. None of them are threats. All of them are additional accounts that can be compromised on your behalf, and none of them are watching for suspicious activity on your project any more.

Two habits fix this permanently. Grant the least access that lets someone do their job — most people need to edit content, not administer a server. And make removing access part of the ending of every engagement, in the same conversation as the final invoice. That pairs naturally with the ownership checklist: you can only revoke access to accounts you actually own.

Put a quarterly review in the calendar. Open each critical service, read the user list, and remove anyone who no longer needs to be there. It takes twenty minutes and it's the highest-value twenty minutes in this whole article.

What to do in the first hour of an incident

If you think something is wrong, the instinct is to delete the suspicious thing and move on. Resist it — you'll destroy the evidence of how they got in, and they'll be back through the same door. A better order:

1. 01Preserve before you clean. Take a snapshot or backup of the current state, compromised as it is, and download the recent access logs. This is what tells you the entry point later.
2. 02Change credentials and end sessions. Reset passwords on the affected accounts and use the 'sign out of all devices' option — a password change alone doesn't always evict someone already logged in.
3. 03Check the quiet places attackers hide. Email forwarding rules and filters, additional recovery addresses, unexpected admin users, new API keys, and your DNS records. These are how they get back in after you've cleaned up.
4. 04Then clean and restore, ideally from a known-good backup rather than by deleting things until the symptoms stop.
5. 05Tell the people who need to know. If customer data was involved, there are legal obligations with deadlines, and they're shorter than most people assume. A short, honest notification survives far better than a discovered cover-up.

What this costs

Almost nothing, which is the frustrating part. A team password manager runs a few dollars per person per month. Two-factor authentication and passkeys are free. Automatic updates are free. Backups are usually included with your hosting, or cost a few dollars for object storage. The access review is a calendar entry.

The real cost is attention, and attention is what small teams have least of. So make it structural instead of heroic: set it up once during a project rather than promising to be careful, put the recurring reviews in a shared calendar, and write down who's responsible. Security that depends on someone remembering is security that expires.

None of this makes you unbreakable, and anyone promising that is selling something. What it does is move you out of the category that gets compromised by automated, indiscriminate scanning — which is the category nearly every small-business incident belongs to.

We set this baseline up as part of every software engagement, and hand it over documented. If you've inherited a project and aren't sure what state it's in, a conversation is a reasonable place to start.