Website Security for Small Business: The Minimum That Actually Matters

Who you're actually defending against

Forget the image of a hacker picking your company as a target. In the vast majority of cases something else is happening: a bot crawls the internet in sequence, pokes at known paths like /wp-login.php or /administrator, checks for outdated plugin versions, and runs passwords from a dictionary. If something works, your site joins someone else's network - sending spam, funnelling traffic to gambling sites, hosting hidden links.

There's a practical conclusion here. You don't need protection from a targeted attack - you need to stop being an easy target. Those are two very different price tags.

The second most common scenario has nothing to do with hacking at all: the site dies because the domain expired, nobody renewed the hosting, the developer left and took the credentials with them, or an update took the shop down on a Friday evening. Organisational failures cost businesses more than bots do.

Five things a site should never go live without

This is the floor, not the ceiling. If any of these is missing, that's not "elevated risk" - that's an open door.

For every item you can ask your contractor for a straight "done, here's where to check it". "It's all standard, don't worry" doesn't count as an answer.

• HTTPS across the whole site, with automatic certificate renewal. How to check: open the site, click the padlock in the address bar, look at the expiry date. If the certificate has to be renewed by hand, one day it won't be.
• Updates. For a CMS, that means current core and plugin versions; for a custom project, up-to-date dependencies. Ask when things were last updated and whether there's a staging copy where updates get run first.
• Passwords and two-factor auth. A separate password for the admin panel, another for hosting, another for the domain, nothing reused. Two-factor authentication enabled on the hosting, domain registrar and email accounts - those are the three points where losing access means losing the site entirely.
• Backups stored somewhere other than the same server. If the backup sits next to the site, it dies with the site when files get encrypted or the account gets wiped.
• Separate access levels. Your content person gets an editor role, not administrator. Your ads contractor gets analytics access, not the server. One shared admin login for everyone guarantees you'll never know who broke what.

Backups are the one measure that always saves you

Any defence can fail. Restoring from a copy works after a hack, after a developer's mistake, after a hosting outage, and after "I accidentally deleted a whole section". So if you only do one thing from this article, do this one.

Here's the check almost nobody runs: ask for the backup to be restored on a test domain and to see the result. Very often it turns out the backups exist but contain only files and no database, or the archive is corrupt, or the last working copy is two months old. A backup that has never been restored doesn't count as a backup.

Agree on two numbers: how often a copy is taken and how many copies are kept. For a simple brochure site, weekly is fine. For a shop with orders, daily - because a lost day of orders can't be recovered from anywhere.

Forms, enquiries and personal data

Forms are the most vulnerable part of a typical site, though not in the sense of someone breaking into your server. They bring in spam, and along with customer data they bring legal responsibility.

Data protection rules and notification requirements are a conversation for a lawyer, not a developer. The developer's job is to make sure the privacy policy is published, consent is recorded technically, and data isn't sitting in plain view somewhere it shouldn't be.

• Bot protection on forms: a captcha or an invisible check, plus rate limiting per address. Without it, your team will start missing real enquiries buried in junk.
• Send every enquiry to at least two places - for example, email plus a database or CRM. A form that only sends an email will silently swallow an enquiry one day, and you'll never know.
• A privacy policy page and a consent checkbox next to the submit button, not in small print in the footer.
• Don't collect more than you need. Every "date of birth" or ID number field you don't actually use is data you're obliged to protect with no benefit to you.
• Check who receives the enquiry emails. If it's the personal inbox of someone who left the company, that's a leak, not security.

What small businesses shouldn't spend on

Honestly: most companies with a few dozen pages don't need a paid WAF, enterprise DDoS protection, penetration testing or certifications. Those are tools for businesses whose site is their main revenue source or a store of sensitive data.

On scare tactics: if a contractor sells you "hacker protection" on a monthly fee but can't explain what's actually included and how you'd verify the result, they're selling anxiety. A normal answer sounds like "we update the core and plugins, keep an eye on backups, respond to incidents" - and that's usually called site maintenance, not security.

What genuinely costs money and isn't excessive: decent hosting instead of the cheapest option, a separate staging copy for testing updates, and a maintenance agreement with a named person responsible. Boring things that prevent most problems.

What to ask a contractor up front

You can ask these before signing anything, and you don't need technical knowledge to judge the answers. You're not after terminology, you're after specifics: where, how often, who's responsible.

One point everyone forgets: the domain should be registered to you or your company, not to the studio. Hosting should be on your account too, with access granted to the developer. This is your property, and when you part ways with a contractor you shouldn't have to beg for any of it.

• Whose name are the domain and hosting registered under, and will you hand over all credentials when the project is delivered?
• Where do backups go, how often, and can I see a restore?
• If a vulnerability turns up in the CMS or a library six months from now, is that your responsibility or mine?
• Is there a staging copy where updates get tested before going to the live site?
• How are passwords shared - as plain text in a messenger, or through a password manager?

If the site has already been hacked

The order of operations matters more than speed. First, don't delete anything right away: preserve the current state of the site and the logs, or you'll never work out how they got in. Second, change passwords: hosting, admin panel, database, FTP/SSH, email, domain registrar.

Then restore from a backup made before the infection, and only after that close the hole by updating the vulnerable component. If you restore without patching, you'll be hacked the same way within a week.

Check the fallout beyond the site itself: whether the domain has been flagged as malicious by search engines and browsers, whether spam was sent from it, whether unfamiliar pages from your domain now show up in search. Submit a review request in your webmaster tools after everything is clean, not before.