What “security-first” actually means for a small business site

Once your website takes bookings, stores customer details or sends invoices, it isn't a brochure anymore. It holds personal data and it touches money. That changes what "secure" needs to mean.

"Security-first" is easy to put on a sales page. Here's what it should mean in practice, in plain terms, and what you can check yourself.

1. Data is encrypted on the way and at rest

• In transit: every page loads over HTTPS (the padlock), with no mixed or insecure content, and plain HTTP redirects to HTTPS.
• At rest: the database and backups are encrypted where they're stored, so a lost disk or leaked backup isn't readable.

Check it yourself: visit your site with http:// at the front. It should switch to https:// on its own.

2. Logins are hard to steal

The admin panel is the most valuable door into your business. It should have:

• Two-factor authentication for every staff and admin account, not as an optional extra.
• No shared logins. Each person has their own account so access can be removed when someone leaves.
• Sensible lockouts after repeated failed attempts.

Check it yourself: if your whole team shares one admin password, that's the first thing to fix.

3. People only see what they need

This is called least privilege. A receptionist doesn't need to export your customer list; a contractor doesn't need to see invoices. A well-built system has roles, and the rules are enforced in the database itself, not just by hiding buttons on screen.

Ask your developer: "If a staff member guessed the URL of a page they're not allowed to see, what happens?" The right answer is "they get refused, and it's logged."

4. Inputs are treated as hostile

Every form on a public website is an open door. Security-first code assumes anything typed into it might be an attack:

• Everything is validated on the server, not just in the browser.
• Data is never pasted straight into database queries or pages (the cause of injection and cross-site scripting attacks).
• Forms are rate-limited and protected against bots, so nobody can flood you with junk or test stolen card numbers.

5. The site sends the right security headers

Browsers have built-in protections that a site has to switch on through security headers. They control which scripts can run, whether your site can be embedded in someone else's, and more.

Check it yourself: free scanners such as Mozilla Observatory or securityheaders.com grade any public site in seconds.

6. Backups exist and have been restored

Almost everyone says "we back up daily". Far fewer have ever restored one. A backup you haven't tested is a hope, not a plan.

Ask your developer: "When did you last restore a backup of my site, and how long did it take?"

7. It's tested before launch, not after

Security-first means someone tries to break it before your customers (or attackers) do:

• Load testing. Does it stay up on your busiest day, or after a promotion goes out?
• Access-control testing. Can one customer see another's data? Can a staff member reach admin-only pages?
• Injection and input testing on every form.
• A written record of what was tested and what was fixed.

8. Updates and monitoring don't stop at launch

Software ages. Libraries get security patches, certificates expire, and new attacks appear. After launch, someone should be:

• Applying security updates promptly
• Monitoring uptime and alerting on problems
• Keeping an eye on unusual login activity

If nobody is named as responsible for this, nobody is doing it.

Questions to ask before you hire anyone

1. Is two-factor login included for every admin account?
2. Where is my data stored, and is it encrypted at rest?
3. How are permissions enforced: on screen, or in the database?
4. What testing happens before launch, and do I get a written record?
5. When was a backup last restored, and who does it?
6. Who applies security updates after launch?
7. If we part ways, do I get the code, the data and the admin access?

None of this needs a big budget. It needs the work to be done on purpose, on every build, and not sold as an upgrade.

Next steps

• Security & stress testing
• Hosting, care & improvements
• Why we build security-first