When you hire someone to build your website, you're trusting them with more than a logo and a contact form. You're trusting them with your customers' data, your reputation, and — whether anyone says it out loud or not — your security. The uncomfortable truth is that most web developers aren't thinking about that last part at all.
This isn't a smear on web developers. It's a structural problem with how websites get built, especially for small businesses. Understanding it is the first step to not becoming the next cautionary tale.
Web developers are paid for how a site looks, not how it holds up
Think about how a typical small business website project is scoped. The brief is almost always about design, content, speed, and a launch date. "Make it look professional. Make it load fast. Get it live before the trade show." Security is rarely written into the contract, rarely budgeted for, and rarely tested before handover.
Developers respond to what they're measured on. If nobody asks "is this secure?", security quietly drops to the bottom of the list — behind the hero image, the booking widget, and the colour of the call-to-action button. The site launches, it looks great, everyone's happy. The vulnerabilities don't show up in the screenshot.
"It uses WordPress" is not a security strategy
A huge proportion of UK small business websites run on WordPress, and for good reason — it's flexible, affordable, and quick to build on. But WordPress sites are also one of the most heavily targeted platforms on the internet, precisely because they're so common and so often poorly maintained.
The platform itself is reasonably secure. The risk lives in everything bolted onto it:
- Plugins and themes — the average site runs a dozen or more, often from different authors of varying quality. Each one is code running on your site, and each one is a potential way in. Abandoned plugins that haven't been updated in years are a common entry point.
- Outdated versions — once a vulnerability is published, automated bots scan the entire internet for sites still running the affected version. Patching within days matters; many small business sites go months or years without an update.
- Weak admin access — default usernames, reused passwords, and no multi-factor authentication on the login page that controls your entire website.
A developer who installs a theme, adds the plugins the client asked for, and hands over the keys has built a functional website. They have not built a secure one — and they usually haven't told the client the difference.
The common ways small business sites get attacked
You don't need to be a target to be a victim. The vast majority of attacks on small business websites are opportunistic and automated — bots looking for any site with a known weakness. The patterns are well understood, and the industry-standard reference for them is the OWASP Top 10, a list of the most critical web application security risks. The ones that catch small businesses most often:
- Injection flaws — badly written forms or search boxes that let an attacker run their own commands against your database, potentially dumping every customer record you hold.
- Broken access control — pages or admin functions that should be locked down but can be reached by anyone who knows (or guesses) the URL.
- Security misconfiguration — default settings left in place, error messages that leak technical detail, directories that should never have been public, and missing security headers.
- Vulnerable components — that out-of-date plugin, theme, or library with a publicly known flaw that nobody got around to patching.
- Cross-site scripting (XSS) — flaws that let an attacker inject malicious code into pages your customers view, often to steal logins or payment details.
None of these require a sophisticated, targeted hacker. They require an unpatched site and a bot that finds it — which happens around the clock, to businesses of every size.
Why this is a bigger deal in the UK than people realise
If your website collects any personal data — names, email addresses, phone numbers, booking details, payment information — then under UK GDPR you are legally responsible for protecting it. "Our developer handled the website" is not a defence the Information Commissioner's Office (ICO) will accept.
If that data is breached because of a vulnerability that reasonable security practice would have caught, you — the business owner — are the one who has to notify the ICO within 72 hours, potentially inform affected customers, and answer for why the data wasn't adequately protected. The developer who built the site months ago is long gone. The liability stays with you.
The National Cyber Security Centre (NCSC) publishes clear, free guidance for small businesses precisely because this gap is so common. The frameworks exist. The problem is that they almost never make it into a standard website build.
The questions to ask before you hire (or after you've launched)
Whether you're commissioning a new site or you already have one, these are the questions that separate a site that merely works from one that's actually defensible:
- Is HTTPS enforced everywhere, with a valid certificate and no insecure pages?
- Are security headers configured — things like Content-Security-Policy, Strict-Transport-Security, and X-Frame-Options?
- Who is responsible for keeping the platform, plugins, and dependencies updated after launch — and how often?
- Is multi-factor authentication enabled on the admin login and hosting account?
- Has anyone tested the site against the OWASP Top 10, or is "it looks fine" the only check it passed?
- If the site holds personal data, where is it stored, who can access it, and does that satisfy UK GDPR?
If you don't know the answers, that's not a failure on your part — it's exactly the gap this article is about. Most business owners were never given the chance to ask.
Security built in beats security bolted on
The cheapest, most effective time to secure a website is while it's being built. Retrofitting security onto a finished site — untangling a sprawl of plugins, rewriting insecure forms, locking down access that was never restricted — is slower, more expensive, and never quite as clean as doing it right from the start.
That's the whole idea behind building security in rather than bolting it on: hardening the configuration, reviewing against OWASP standards, enforcing HTTPS and security headers, and handing over a site you can actually stand behind — with a report that tells you what was done and why.
At OkamiSec, this is the principle behind everything we build. If you're commissioning a new website, we'll build it secure from day one. If you already have one, our free Cyber Essentials self-assessment is a sensible first look at where you stand — and our website security reviews go deeper. Either way, you'll finally have the answers to the questions above. Because you shouldn't have to choose between a website that looks good and one that won't get you in trouble.