GDPR checklist for a small business website

Data protection on a business website rarely shows up as one big problem. It shows up in pieces: a form that forwards to a private mailbox. A map that loads before anyone was asked. A privacy policy describing a tool that was removed two years ago. Each of these is small on its own and settled within an hour — as long as you know it is there.

This list is therefore ordered by how the points actually cause trouble in projects, not by statute. It does not replace a review. It is there so you walk into the conversation with your legal adviser holding a concrete list, rather than the question “is this alright?”.

The privacy policy, and what it actually has to describe

A privacy policy is not a text block you drop in once and forget. It is a description of what really happens on your website. The most common defect is therefore not a wording error but a discrepancy: the text describes a state of affairs the site no longer has, or never had.

That happens in two ways. Either the text came from a generator and lists services that were never embedded. Or it did not grow with the site: a booking tool was added, a newsletter, a chat window — and the text stayed as it was. Both lead to the same situation. The policy explains something other than what the website does.

• Who is responsible, with a full postal address — the same details as in the Impressum, not different ones
• What data arises from simply loading a page, and what the server logs of it
• Every tool running on the site, named individually: form, analytics, maps, video, fonts, booking, chat, newsletter
• The purpose each set of data is processed for, and on what legal basis
• How long things are stored, or by what criterion they are deleted
• Whether data goes to third parties or to countries outside the EU
• The rights of data subjects and how someone exercises them with you in practice — an address they can write to

The practical starting point is therefore not the text but an inventory. Open your home page, one inner page and the contact page, and note every third-party script that loads. That list is what your legal adviser needs. Without it, even a good firm can only write down what is customary.

The contact form: three questions nobody asks

A contact form is the point where a website first actively collects data about a specific person. Three questions about it are rarely asked and rarely hard to answer.

• What is collected? Every required field should be necessary to reply. A phone field is fine — making it mandatory needs a reason if you answer by email anyway.
• Where does it go? Forms send the enquiry by email, also store it in the website database, or both. The database copy is regularly forgotten and fills up for years.
• How long does it sit there? Enquiries that never became a job do not need a permanent home. A deadline you actually keep is worth more than a short one nobody applies.

Two technical points belong here because they are easily missed. First: if the form goes to an email address, that mailbox is part of the same question — a business address, not a private account that other people read over your shoulder. Second: a spam filter, a map next to the form or an embedded booking calendar is each a further service and belongs on the inventory, even if it looks like two lines of code in the back end.

Consent before loading, not after

The term cookie banner is misleading, because it describes the visible part rather than the decisive one. What matters is what happens in the background while the notice is still on screen. A notice that merely informs — “this site uses cookies, OK” — is a statement, not consent. And a dialogue that appears after analytics has already started changes nothing about the processing.

The sequence is the whole point:

1. 01The page loads completely without any non-essential script starting.
2. 02The notice appears and says in plain language what consent is being asked for — not “for a better experience”.
3. 03Refusing is as easy as accepting: same level, equally visible, one click against one click. Not a coloured button against a grey link in a sub-menu.
4. 04Consent is given actively. No pre-ticked boxes, no “continuing to browse counts as agreement”.
5. 05Only after consent is the relevant script loaded — and only the one consent was given for.
6. 06The decision is recorded: what, when, and under which version of the notice.
7. 07Withdrawal is possible at any time and as easy as giving consent — permanently reachable, not only on the first visit.
8. 08Anyone who refuses can still use the site normally. Putting content behind consent is a separate legal question.

The most useful test takes a minute. Open your site in a fresh browser window, open the developer tools, and look at which external addresses are contacted before you have clicked anything. Whatever appears there runs without consent. That list should be short and consist essentially of your own server.

Analytics tools: the question first, the tool second

With analytics tools one question is worth asking before any technical one: what decision do you make with this number? Plenty of small websites measure visitor counts without anything ever following from them. A tool whose results nobody reads is the easiest item on any list — it gets removed, and half the discussion goes with it.

If you do want to measure, consent changes the character of the numbers, and it is better to know that in advance. As soon as some visitors refuse, the figures are incomplete. They are then good for trends and comparisons over time, but no longer a count of all visitors. Miss that and you will puzzle over a drop that is really just a changed basis of measurement. There are also tools that work differently and collect less data about individuals — whether one of them may be used without consent in your case is, again, a legal question and not a technical one.

Embedded content: maps, video, fonts

Third-party content inside your own layout is where most otherwise careful sites get caught. The reason is structural: an embed is a connection to someone else’s server, and that connection is made while the page loads — before the visitor has decided anything.

• Map services on the contact page
• Video embeds from video platforms
• Fonts loaded from an external server instead of your own
• Review widgets, booking tools, chat windows, social media feeds
• Tracking pixels from ad accounts, added once for a campaign and never removed

For most of these there is a technical answer that defuses the legal question instead of having to answer it. Fonts can be shipped with the site rather than fetched, which is faster anyway. A map can be replaced by an image with the address and a link; anyone who genuinely wants directions clicks and lands at the map service they would have ended up at regardless. Videos can be given a preview that only loads on click. When we relaunched our own website in August 2026 we worked exactly that way: fonts sit on our own server, and anything nobody needs is not built in at all.

Contracts with providers, and the connection itself

As soon as a provider processes data on your behalf — the host, a newsletter service, a booking tool, a backup solution — there is usually a data processing agreement behind it. With most providers it is available in the account or part of the terms, and only has to be accepted once and then filed. It is a twenty-minute piece of admin that stays open almost exclusively because nobody has it on a list.

Keep those agreements in one place: a folder, a list, a date. The same overview later answers the question of which services are running at all, which makes it the basis for the privacy policy too. On the connection itself: a website without encryption is no longer normal. A certificate is part of the package with practically every host, renews automatically, and is the one item on this list that can be settled entirely by technical means. Also check that the unencrypted address redirects to the encrypted version, and that no single file — an image, a script — is loaded unencrypted alongside it.

Who decides what

The third column is the real content of this table. Nearly every row has a technical part and a legal part, and the most common reason a point stays open for years is not negligence but an assumption: each side takes it that the other is handling it.

What a web designer can do here, and what they cannot

Being honest about this topic means drawing the line clearly, not least because proposals routinely blur it. What we take on is the technical side:

• We build the consent prompt so that it genuinely comes first and a refusal takes effect technically
• We provide the complete list of services running on your site — the basis for any review
• We serve fonts from your own server, replace embeds with versions that only load on click, and remove what nobody needs
• We set up forms so it is traceable where an enquiry goes and what is additionally stored
• We take care of encryption and a clean redirect to the encrypted address

What we do not do: write or assess legal texts. We will not tell you whether your privacy policy is sufficient, whether a given service requires consent in your case, or which retention period is right for your enquiries. That is not modesty but a question of competence. Those judgements depend on your business, your data and your circumstances, and someone who is qualified and insured for it has to stand behind them.

No article, no tool and no supplier can promise you that your website is in order — and anyone promising that should give you pause. What you can realistically achieve is a clean, documented position: you know what runs on your site, you have written it down, and you have had it reviewed once by someone entitled to judge it. The rest is upkeep, and it consists of two questions with every new embed: what does that load, and is it in the policy?

Frequently asked questions about data protection on your website