What a secure website actually protects you from

Small business owners tend to hear website security as something for banks. Nobody wants what I have, the thinking goes, so nobody will come looking.

That is a reasonable assumption about people and a wrong one about software. Almost nothing that happens to a small site involves a person choosing it. It involves a program working through every address it can reach, testing each one against a list of known weaknesses, and stopping wherever something answers. You are not selected. You are enumerated.

Which changes what security means. It is not about being interesting enough to attack. It is about not being on the list of things that answer.

The list is public, and that is the whole problem

When a vulnerability is found in a piece of widely used software, it gets published. That is the correct process: publishing it is how everyone learns to fix it. A patch is released, and the people who apply it are fine.

The publication also tells everyone else exactly what to look for and how. Before long it is folded into automated scanners, and every site still running the unpatched version becomes findable by anyone who cares to look.

So the window that matters is between the patch existing and you applying it. A site nobody has updated in two years is not running unknown risks. It is running published, documented, tooled-up ones. This is why "we built it and it has been fine ever since" is not the reassurance it sounds like. Nothing about the site changed, but the world's knowledge of its weaknesses kept growing.

What HTTPS does, and what it does not

The padlock is the one piece of security most people can name, and it is routinely misread as a general statement of safety.

HTTPS encrypts the connection between the visitor's browser and your server. It means somebody sharing the coffee shop network cannot read what your customer typed into your form, and cannot quietly alter your page on the way through. That matters, and it is why browsers now mark sites without it as not secure, which costs you trust before anyone reads a word.

What it does not do is say anything about your site. A site with a padlock can be running software full of holes, storing passwords in plain text and leaking its database. HTTPS protects the journey, not the destination. Get it, since it is free and automatic on any decent host, and do not treat it as the job finished.

Backups are the only actual recovery

Everything else here reduces the chance of a bad day. Backups are what you have on the bad day.

Two things separate a backup from the appearance of one. It has to sit somewhere the problem cannot reach, because a copy on the same server as the site goes wherever the site goes. And somebody has to have restored one. An untested backup is a guess, and people tend to discover the file has been silently empty for eight months at the exact moment they need it.

If you take one thing from this page, take that. Ask whoever runs your site when they last restored a backup, not whether they take them.

What actually goes wrong, and what it costs

The failures worth planning for are unglamorous.

A compromised site usually gets used rather than destroyed, because a working site with a clean history is worth more to whoever took it than a broken one. It gets pages added selling things you do not sell, or it starts sending mail, or it quietly serves something unpleasant to your own visitors. You often find out because a customer tells you, which is the worst available way to find out.

Then it compounds. Browsers start warning people away, and that warning outlives the fix. Your host may suspend the account to protect the rest of their server, so the site is not merely compromised, it is off. If you send email from the domain, your address can end up on blocklists and ordinary business mail stops arriving. Clearing that up takes longer than closing the original hole.

The other category is data. If you collect names, emails, phone numbers, or anything a customer typed expecting privacy, you are holding something that belongs to them. Losing it is a different kind of problem from losing your own files, with obligations attached in most jurisdictions and a trust cost no technical fix addresses.

What being kept secure actually consists of

Concretely, for an ordinary business site: software gets updated when patches come out rather than when somebody remembers. Backups run automatically, off the server, and get restored occasionally to prove they work. Admin access uses passwords nobody reuses elsewhere, and old accounts get removed when people leave. Forms validate what they accept, because a form that takes anything is an open door. HTTPS is on and stays on. And somebody notices when the site goes down, instead of the owner noticing on Monday.

None of that is dramatic. It is maintenance, it is boring, and boring is the entire objective.

Who does it matters more than what it costs

This is the part worth being direct about, because it is why we structure our own work the way we do.

Every item on that list is ongoing. None of it is bought once at launch. So the real question at handover is not whether your site is secure, it is who is responsible for keeping it that way, and whether they know that they are.

If you have someone technical, or you are willing to learn a short routine and stick to it, run it yourself. That is a legitimate answer and we deliberately build projects that way. What does not work is the third option, where the site ships, everyone assumes it is handled, and two years pass. That is the state most compromised small sites are in, and it is a failure of ownership rather than of technology.