IN THIS ARTICLE · 7 PARTS
The short answer: if your website has a contact form, analytics or ads, it collects personal data and the GDPR applies to you, however small your business is. In practice that means three things. First, a privacy policy that says who you are, what you collect, why and how long you keep it [2]. Second, a banner that asks before any cookie that is not strictly necessary [4]. Third, a plan for the data from your form: who sees it, where it is stored and when you delete it [3].
This is general information, not legal advice. The aim is to help you know what to check and what to ask. For your own situation, talk to a lawyer.
Which parts of your website fall under the GDPR
Most small websites collect data in fewer places than the owner fears, but in more places than is obvious at first glance. The usual ones:
| Part of the website | What data | What you need |
|---|---|---|
| Contact form | Name, phone, email, message | A short note by the form and a link to the policy [2] |
| Online bookings | Name, phone, time slot | The same; the data serves the service the person asked for [1] |
| Analytics (e.g. Google Analytics) | Cookies and visit data | Consent before it runs [4], [5] |
| Ad tags (Meta Pixel, Google Ads) | Advertising cookies | Consent before they run [4] |
| Newsletter | A separate legal basis, most often consent [1] | |
| Embedded map, video, chat | May set their own cookies | Check what they load and include them in the banner [6] |
Why doesn't a contact form need an "I agree" tick box when a newsletter does? The European Data Protection Board (EDPB) explains that when someone asks you for a quote, you may process their data to reply, without separate consent [1]. Marketing is a different purpose and needs a different basis, most often consent [1]. That is why a newsletter sign-up has a tick box, while "Send enquiry" usually doesn't need one.
Cookies: which need consent and which don't
A cookie is a small piece of data a website leaves in the browser so it can "remember" something next time [6]. Cookies are used for three things: sign-in and shopping carts, settings such as language, and tracking behaviour [6].
According to the EU's Your Europe portal, a website has to ask for consent before it places a cookie [4]. It is not enough to say that the site uses cookies or to explain how to switch them off [4]. People must be told what the cookies are used for and be able to withdraw their consent [4].
There is an exception. Cookies that are strictly necessary for a service the person asked for, such as filling in a form or using a shopping basket, don't need consent [4]. Analytics and advertising are not in this group.
A banner that only says "we use cookies" is not consent. People must be able to say no, and the website should keep working.
The EDPB describes what makes consent valid [1]:
- Free: people can refuse without consequences and withdraw at any time, as easily as they agreed.
- Specific: given for each purpose; analytics and advertising are not the same thing.
- Informed: written clearly and plainly.
- Unambiguous: given by an active step, with no pre-ticked boxes.
One practical point: on a phone, a cookie banner covers a large part of the screen. Keep it short and easy to close, or it drives people away, as explained in what a mobile-friendly website really means.
Analytics and ads: making them wait for consent
The banner on its own doesn't stop any scripts. The website's code also has to respect the visitor's choice. For Google's tools there is consent mode [5]. Google states clearly that you are responsible for obtaining consent; consent mode only passes the choice on to their tags [5].
There are two versions [5]:
- Basic: Google tags don't load until the visitor makes a choice in the banner. Nothing is sent to Google before that, and nothing at all if they decline.
- Advanced: tags load straight away, set to "denied" by default. While that is the case, they send measurements without cookies, which Google uses for more detailed modelling of the missing data.
Decide which one fits you together with whoever advises you on the GDPR. Basic is the easier one to check: open the site, decline, and nothing should run. Meta works on the same idea; see how the pixel waits for consent in what is the Meta Pixel.
You will see fewer visits in your reports, because some people decline. That is normal. Enquiries and calls remain the most reliable measure: how to measure what your website brings you. And fewer scripts also make the site faster (why is my website slow).
Privacy policy: what it should say
The EDPB recommends giving the information in two layers [2]. A short note where people hand over their data, for example under the form, plus a link to the full text [2]. Under a form, something like this is enough: "We use your name and phone number only to reply to your enquiry. More in our privacy policy."
The full policy, in plain language, answers these questions [2], [1]:
- Who you are: your company name and how to contact you about personal data.
- What data you collect and what for.
- On what basis: replying to an enquiry, a contract, consent.
- Who else sees it: hosting, email service, booking system.
- How long you keep it, or how you decide that.
- What rights people have: to see, correct or delete their data, to restrict processing, to receive it, to object.
- That they can complain to the data protection authority. In Bulgaria that is the Commission for Personal Data Protection (CPDP).
If someone asks to see or delete their data, the EDPB says you should answer within one month and, as a rule, free of charge [2]. Keep a note of the request and your reply.
Form data: who sees it and how long you keep it
Under the GDPR you are the "controller": you decide why and how the data is processed [3]. Companies that process it on your behalf, such as your host, email service or CRM, are "processors" [3]. There must be a contract with them saying they act only on your instructions, keep the data secure and return or delete it when you stop working together [3]. Check each provider's terms for such an agreement (often called a Data Processing Agreement, or DPA).
Three more habits that protect both you and your customers:
- Ask only for what you need. The EDPB advises collecting the least data you can work with [1]. For a call-back, a name and a phone number are enough.
- Send the form over a secure connection. The website should run on HTTPS, with an SSL certificate.
- Set a period and clean up. An old enquiry that never became a customer doesn't need to sit in your inbox for years.
A checklist to copy
- You have a privacy policy, linked in the footer of every page and under every form.
- Under the form, one or two sentences say what you use the data for.
- The form asks only for what you need.
- Analytics and ad tags don't run before consent. Test it: open the site in a private window, decline, and check that they don't fire.
- The banner has a clear decline button and no pre-ticked boxes.
- Consent can be withdrawn easily, for example through a "Cookie settings" link in the footer.
- You know which outside services see the data and you have their processing terms.
- You know how you will reply if someone asks to see or delete their data.
These points also belong in your pre-launch website checklist. If you are ordering a new website, write into the contract who prepares the privacy policy and the banner.
At Studio V1 a website is €50 a month including VAT, with design, hosting, maintenance and a real person you can ask which scripts your site loads. If you'd like to talk it through, get in touch.
References
- European Data Protection Board. "Process personal data lawfully." edpb.europa.eu/sme-data-protection-guide
- European Data Protection Board. "Respect individuals' rights." edpb.europa.eu/sme-data-protection-guide
- European Data Protection Board. "Data controller or data processor." edpb.europa.eu/sme-data-protection-guide
- European Union, Your Europe. "Data protection and online privacy." europa.eu/youreurope
- Google for Developers. "Consent mode overview." developers.google.com/tag-platform
- MDN Web Docs. "Using HTTP cookies." developer.mozilla.org/docs/Web/HTTP
