Guide

Small business website security: a checklist you can run yourself

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

The quickest way for a small business owner to check website security is a short self-audit: is the connection encrypted and the certificate valid, is the software up to date, who has access, is every login protected by a second factor, is there a backup that has actually been restored, and do you control your own domain and hosting? It takes about 15 minutes, needs no technical background and works the same whether your site runs on WordPress, Shopify, Wix, Jimdo or is looked after by an agency. This guide walks you through each point and explains when an outside review is worth it.

Why small websites get attacked too

Plenty of owners assume: “Nobody cares about my little site, there’s nothing to steal.” From a human point of view that may be true, but most attacks on websites today are carried out by software. These programs work through millions of addresses around the clock, testing whether a known vulnerability is open, whether a default password works or whether a form can be abused. They don’t care whose site it is. It isn’t personal. Think of someone walking down a street and trying every front door handle.

Once inside, even a small site is useful to an attacker: to send spam, to redirect visitors to scam pages, to host malware, or to collect whatever comes in through your contact form. For you, the worst case means your site goes offline, Google and browsers warn your visitors away, your reputation takes a hit, and if customer data is involved, data protection obligations kick in.

The good news: because these attacks look for doors left open, the basics stop most of them. That is what the self-check below is about.

The 15-minute self-check

Set aside a quarter of an hour and open your website and your account with your hosting company or website builder. For each point you will find what to check, how to check it and what a good result looks like. Anything you can’t answer yourself goes on a list of questions for whoever looks after your site.

1. Encryption: HTTPS and a valid certificate

Open your site in a browser. The address should start with https:// and the browser should show no warning. The certificate works like a digital ID card for your site and makes sure that what visitors type in, such as their name, email and message, is sent encrypted.

• Check: Type your address once with http:// (no s). You should be sent straight to the https:// version.
• Check: Click the icon to the left of the address and view the certificate. It shows the date until which it is valid.
• Ask your provider: Does the certificate renew automatically? An expired certificate triggers a full-page warning that drives most visitors away.

2. Software and add-ons up to date

Most successful break-ins exploit flaws that were fixed long ago. Who is responsible here depends on how your site is run.

• Website builder (for example Wix, Jimdo, Shopify): the provider updates the servers and the core software. Your part is the apps and third-party extensions you have installed: remove anything you no longer use.
• Self-hosted (for example WordPress): log in to the admin area and see whether updates are waiting for the core, plugins or theme. If notices have been sitting there for weeks, nobody owns updates. Our WordPress security guide covers WordPress in depth.
• Ask your provider: Who installs updates, how often, and who checks afterwards that the site still works?

3. Who has admin access?

An admin account has full rights: whoever holds it can change anything. Over the years these accounts pile up, from former staff, a previous agency or the nephew who once set the site up.

• Check: Open the user list of your website and of your hosting or builder account. Do you know every person on it, and does each of them still need access?
• Good result: Everyone has their own account, nobody shares a password, and only people who genuinely need to change everything have admin rights. Someone who only edits text gets a role with fewer rights.
• Act: Remove unknown or unneeded accounts. An admin account you don’t recognise can also be a sign of a break-in. If so, read Website hacked: what to do first.

4. Two-factor login

With two-factor login, a password on its own is not enough. You also enter a code, generated for example by an app on your phone. Even if someone knows your password, they still can’t get in. Germany’s Federal Office for Information Security (BSI) recommends this method for online services.

• Check: In your account settings under “Security”, see whether two-factor login (often called “2-step verification”) is switched on. Many providers offer it. Wix, for example, supports an app, text message or email.
• Where: Your website login, your hosting or builder account, your domain registrar, and the email inbox used for password resets. Whoever takes over that inbox can reset every other password.
• Important: Store the recovery codes shown during setup somewhere other than your phone.

5. Backups, and whether a restore has ever been tested

A backup is a safety copy of your site. Almost every provider says backups exist. The question that matters is a different one: has a backup ever actually been restored?

• Check: Where are the backups stored, how often are they made, and how far back do they go? A break-in is sometimes only noticed weeks later. If you only keep the last few days, all you have left are damaged copies.
• Good result: At least one copy is kept separately from the website, not just on the same server. And a restore has been rehearsed at least once, ideally on a test copy.
• On a website builder: Many builders keep a version history of your pages. Check whether products, orders and form submissions are covered too, and whether you can export your content.

6. Contact form and spam

The contact form is where strangers send data to your site. Usually that just means annoying spam, but it is also a common entry point for abuse.

• Check: Fill in your own form once. Does the message arrive, and where? Are submissions also stored somewhere on the website, and who can read them there?
• Good result: The form only asks for what you really need, does not accept arbitrary file uploads, and has spam protection set up by your provider or developer.
• Warning signs: A sudden flood of spam, or complaints that emails were sent in your name.

7. Domain and hosting in your own hands

Your domain, the address of your website, is a business asset. In practice it is often registered to the agency, a former web designer or a private individual. As long as everything runs, nobody notices. When the relationship ends or someone can no longer be reached, you may lose access to your own address.

• Check: Who is listed as the domain holder with your registrar? It should be your business. If unsure, ask the registrar.
• Check: Do you have your own login to the registrar and hosting accounts, or does only your provider?
• Good result: Contracts are in your company’s name, you have your own credentials, and invoices go to an inbox you actually read. A domain that lapsed because the renewal notice landed in a former employee’s inbox is an easily avoided problem.

8. Who maintains the site, and is it in writing?

“The agency takes care of it” is often an assumption, not an agreement. Many contracts cover building the site but not looking after it.

• Check: Does your contract say who installs updates, who checks backups and who responds in an emergency, and how quickly?
• Good result: Responsibilities are written down, and you know whom to call when the site goes down.
• If there is no contract: then in practice nobody maintains the site. That is the most common reason websites run for years without updates.

9. Google Search Console: “Security issues”

Google Search Console is a free Google tool for website owners. It includes a “Security issues” report, where Google tells you if it finds hacked content, malware or deceptive pages on your site, for example pages that trick visitors into entering passwords.

• Check: Is your site already set up in Search Console, and do you have access yourself? Often only the agency does.
• Good result: The “Security issues” report shows no entries, and notices from Google reach an inbox someone reads.
• If something is listed: fix the cause first, then request a review from within the report. Google says reviews take several days to a few weeks.

Website builder or self-hosted: who is responsible for what?

Whether your site runs on a builder such as Wix, Jimdo or Shopify, or is self-hosted, say WordPress with a hosting company, doesn’t change whether you need to think about security, only which part is yours. This is called shared responsibility: part sits with the provider, and part always stays with you.

A builder takes the hardest technical parts off your plate. It does not protect you from a weak password, a forgotten login belonging to your old agency or a domain registered to someone else. A self-hosted site adds updates to the list, and that is where most problems start.

Free testing tools: what they show and what they miss

Two reputable, free tools can confirm part of the self-check from the outside. They don’t attack your site. They only read what it already serves publicly.

• SSL Server Test by Qualys SSL Labs (ssllabs.com/ssltest): analyses how your server’s encrypted connection is configured and gives it a grade. Tick “Do not show the results on the boards” before you start if you don’t want your result in the public lists.
• HTTP Observatory by Mozilla (developer.mozilla.org/observatory): checks so-called security headers, instructions your site sends to the browser, such as allowing encrypted connections only. The tool used to have its own address and has been part of Mozilla’s MDN developer portal since 2024.

Both tools are useful, but neither is a security test. Mozilla itself says that even a top grade does not mean a site is secure: outdated software, vulnerable plugins, flaws in forms and databases and the handling of passwords are not checked. A good grade is a good sign for the basic settings, nothing more. On a website builder you also have no control over many of these settings, so an average grade there is no cause for alarm.

What you can do yourself, and when an outside review makes sense

For a simple brochure site with your services, opening hours and a contact form, the self-check above, repeated regularly, say once a quarter, is often enough. Whatever you find, you can fix yourself or with your developer.

It’s a different picture once your website does more than inform. That brings risks you can’t see from the outside and that no free tool will find:

• Online shop or payments: orders, addresses and payment flows are a worthwhile target. Custom changes and add-on apps in particular deserve a close look.
• Customer data: bookings, enquiries containing health or financial details, job applications. The more sensitive the data, the bigger the damage if it leaks.
• Login areas: customer portals, member areas, download sections. The key question is whether each customer really sees only their own data.
• Custom features: calculators, configurators, connections to your inventory or calendar, anything built specifically for you. Custom code gets no vendor updates, and its flaws are only found by someone looking for them.

For sites like these, a penetration test makes sense: an authorised security assessment within a scope agreed in writing, in which specialists examine your website the way an attacker would and back every finding with evidence. Our article Penetration testing: process, duration and cost explains what happens and how long it takes. If you first want to know whether there are weaknesses at all, a vulnerability assessment is the smaller first step.

A word on the law

As soon as your website processes personal data, and a simple contact form already does, the EU General Data Protection Regulation requires appropriate technical and organisational measures to protect it (Article 32 GDPR, “Security of processing”). These explicitly include the ability to restore data promptly after an incident and a process for regularly testing whether the measures work. The self-check above is an easy way to keep both in view.

If a break-in means unauthorised people may have accessed personal data, Article 33 GDPR requires the controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to the people affected (as of October 2026). Whether that applies in your case is something to settle with your data protection officer or a lawyer. This section is general guidance and not legal advice.

The checklist

Frequently asked questions

Further reading

• Website security check in 8 steps
• Content Security Policy and security headers
• Shopify store security: what merchants have to do themselves
• Website hacked: what to do first
• WordPress security: the practical guide for businesses
• Vulnerability Assessment: what it is and when you need one
• Service: penetration testing with verified findings

Sources

• EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 32 to 34
• BSI: Whitepaper on biometrics in two-factor authentication (2024, German)
• Google Search Console Help: Security issues report
• MDN HTTP Observatory: Frequently asked questions
• Qualys SSL Labs: SSL Server Test
• Wix Help Center: Using 2-Step Verification for Your Wix Account