What good website security actually looks like, and when you don't need to worry

Every few weeks someone tells us their website got hacked, or their contact form is suddenly buried under fake submissions, or a plugin they never heard of started sending strange emails. When we look into it, it's almost always one of three situations. And each one calls for a different level of security, not the same blanket answer.

You run a simple site with no logins or payments

Think a five-page company site: who you are, what you do, a contact form. Nobody logs in, no personal data is stored beyond a name and email in a form submission, no money changes hands on the site itself.

For this, you don't need much. A reasonable hosting provider, HTTPS turned on (which is standard everywhere now), regular updates to whatever CMS or framework it runs on, and a backup that actually gets tested once in a while. That's genuinely it. If a supplier is trying to sell you a security package on top of a brochure site like this, ask what specifically it protects, because there often isn't much to protect.

You handle logins, payments or personal data

This is a webshop, a customer portal, a booking system, anything where people create accounts, enter card details, or hand over information that matters if it leaks. Here the calculation changes completely.

You need passwords stored properly (hashed, never in plain text), encrypted connections everywhere, dependency updates that actually happen instead of piling up, monitoring that flags unusual activity, backups that are tested and restorable, and rate limiting so someone can't just hammer your login page with thousands of guesses. GDPR also means thinking about where data lives and who can access it, not just whether it's encrypted.

This is where security has to be designed into the build from day one. Bolting it on afterwards is possible but always messier and more expensive than doing it properly the first time. This is genuinely the situation where an experienced technical partner earns its keep.

You're running something old that nobody actively maintains

This is the one that worries us most, and it's more common than people admit. A WordPress site with forty plugins, half of them unused. A PHP version three releases behind. A system built years ago by someone who's since left the company, and nobody currently on the team knows how it's wired together or who owns the updates.

The risk here isn't visible day to day, which is exactly the problem. Vulnerabilities can sit quietly for years before someone finds and uses them. This doesn't always mean a full rebuild. Sometimes an honest audit, a clean-up of what's actually needed, and a plan for who owns maintenance going forward is enough. But it does mean someone has to actually look, rather than assume it's fine because nothing has gone wrong yet.

• Simple brochure site, no logins or payments: low risk, host-level security and basic updates are enough, don't overpay for anything more
• Site or app with accounts, payments or personal data: real risk, needs security engineered in from the start plus ongoing monitoring and updates
• Old or unmaintained platform: unknown risk until someone audits it, start with a proper look before deciding what to fix

The honest answer is to match the effort to what you're actually running. A five-page site doesn't need enterprise-grade monitoring, and a payment system can't get away with 'we'll update it when we have time'. Figure out which of these three you actually are before you decide what to spend, and on what.