In a company without a dedicated IT team, the website tends to belong to marketing. Nobody says the security of the website belongs to marketing too, but when the site shows a browser warning or the contact form starts sending rubbish, you are the person who gets the message.
You do not need to become a security specialist. You need to be able to check the basics and know who to ask.
The checklist at a glance
| Area | What to confirm | Who to ask |
|---|---|---|
| HTTPS | Padlock on every page, certificate renews automatically | Host or web agency |
| Updates | CMS, theme and plugins updated on a schedule | Web agency or developer |
| Admin accounts | One named account per person, two-factor on | You, with your developer |
| Forms | Spam protection in place, submissions arriving | You, with your developer |
| Backups | Automatic, stored off the server, restore tested | Host or web agency |
| Cookies | Nothing non-essential loads before consent | You, with your developer |
| Email authentication | SPF, DKIM and DMARC all set up | IT provider or domain manager |
| Incident plan | A one-page note of who to call | You |
Keep the site itself healthy
HTTPS and certificates
HTTPS encrypts the connection between a visitor’s browser and your site. It depends on a certificate, which expires and has to be renewed. When renewal fails, visitors see a full-page browser warning telling them the site is not safe.
Check: load your site with and without www, and click the padlock (or the site information icon) in the address bar to see when the certificate expires.
Ask your host: “Does our certificate renew automatically, and who is alerted if renewal fails?”
CMS and plugin updates
Your CMS is the system you edit the site in. Most sites also run a theme and a set of plugins (add-ons for forms, SEO and so on). Security holes are found in all of them regularly, and updates close those holes. Out-of-date plugins are one of the most common ways ordinary business sites are compromised.
Check: log in and look at the updates screen. A long list of pending updates means nobody is doing this.
Ask your developer or agency: “Who applies updates, how often, and are they tested somewhere before they go on the live site?” Also ask for any plugins you no longer use to be removed. Deactivated is not enough.
Backups
A backup is a copy of the site’s files and its database.
Three things make a backup worth having:
- It runs automatically, at least daily for an active site.
- It is stored somewhere other than the web server itself.
- Someone has restored from it and confirmed it works.
Ask: “When did we last test a restore, and how long did it take?”
A backup nobody has ever restored from is a hope. Ask for a test.
Control who can log in
Open the user list in your CMS. You will probably find people who left, an agency you stopped using, and an account called “admin” that several people share.
Tidy it up:
- One account per person, in their own name. Shared logins mean you cannot tell who did what.
- Remove leavers and old suppliers. Do it today.
- Give the least access that does the job. Someone who writes blog posts needs an editor role, not full administrator rights.
- Turn on two-factor authentication. This asks for a code from your phone as well as a password, so a stolen password alone is not enough. Do it for the CMS, the domain registrar, the hosting control panel and your email platform.
Make a note of where the domain name is registered and whose login controls it. Losing control of the domain is worse than losing the website, because the domain decides where both your site and your email go.
Forms and spam
Every public form attracts automated junk. Beyond the annoyance, spam buries real enquiries, and if your form sends an automatic confirmation email, spammers can use it to send messages that appear to come from you.
What to have in place:
- Spam protection. A honeypot (a hidden field only bots fill in) or a challenge service. Ask your developer which is in use.
- A monthly test. Submit your own form from a personal email address and confirm it arrives where it should.
- A record of where submissions are stored. If enquiries are saved in the CMS as well as emailed, that is personal data sitting on your web server. Know how long it is kept.
Cookie consent before tracking
UK law requires consent before you place non-essential cookies on someone’s device. Analytics, advertising pixels and most embedded video fall into non-essential. Cookies needed for the site to function, such as keeping items in a basket, do not need consent.
Many sites display a banner and load every tracker regardless.
Check it yourself:
- Open your site in a private browser window.
- Do not touch the banner.
- Use a browser extension that lists the trackers on a page, or ask your developer to show you the cookies in the browser’s developer tools.
If analytics or advertising cookies are already present before you have clicked anything, consent is not working. Also check that rejecting is as easy as accepting, and that rejecting does in fact stop the trackers.
Expect your analytics numbers to fall once this is fixed. Tell the CEO in advance.
Email authentication
Three records, added to your domain’s settings, tell receiving mail servers that an email claiming to be from you is real:
- SPF lists the services allowed to send email for your domain.
- DKIM adds a digital signature to each message so the recipient can verify it was not altered.
- DMARC tells receivers what to do with mail that fails those checks, and sends you reports about it.
Without them, your mail is more likely to land in junk, and anyone can more easily send email pretending to be you. The large mailbox providers now expect all three from anyone sending in volume.
Every tool that sends on your behalf needs including: your email marketing platform, your CRM, your website’s form notifications, your accounts system.
Ask your IT provider: “Are SPF, DKIM and DMARC set up for our domain, do they cover every service that sends as us, and what is our DMARC policy set to?” A policy of “none” only monitors. The aim is to move, carefully, to one that quarantines or rejects fakes.
When something goes wrong
Write a one-page note now, while nothing is wrong. It should hold:
- Who hosts the site, and their support contact.
- Who registered the domain, and who can log in.
- Who your developer or agency is, and their out-of-hours contact if they have one.
- Where the backups are and who can restore them.
- Who inside the company needs telling.
If the site is hacked or defaced, the order is: tell your host and developer, change passwords for every admin account, restore from a clean backup, then find and close the way in. Restoring without that last step invites a repeat.
If personal data may have been exposed (enquiry form submissions count), tell whoever handles data protection in your company straight away. UK data protection law can require a report to the Information Commissioner’s Office within 72 hours of becoming aware of a breach, so this is not one to sit on over a weekend.
If you would like to know where you stand before anything goes wrong, our Website Audit checks the externally visible security and privacy basics, and a person reviews the findings before you see them. See also whether your hosting is doing its share.