A banner that reads "By continuing to browse, you accept our cookies" is not consent, and repeating it in smaller text on every page does not improve it. Most websites that collect EU visitor data do not fail GDPR because they ignored it — they fail because consent was assumed rather than collected, or because a request from a visitor sat unanswered in an inbox for three weeks. The four areas below are where small teams usually need the most work, and where a few focused hours make the biggest difference.
Start with a data map, not a policy document
You cannot write an honest privacy notice until you know what you actually collect. Most sites collect more than the team realises: form submissions, analytics identifiers, server logs, abandoned cart data, newsletter signups, live chat transcripts, and whatever a marketing pixel drops on a visitor's device.
Spend an afternoon building a plain spreadsheet. One row per data flow, with columns that force specific answers:
- What data — email address, IP address, device identifier, payment reference, free-text message.
- Where it comes from — contact form, checkout, chat widget, analytics script, log file.
- Why you have it — fulfilling an order, answering a question, measuring traffic, sending a newsletter.
- Legal basis — consent, contract, legal obligation, or legitimate interests.
- Who else touches it — hosting provider, email platform, payment processor, analytics vendor.
- How long you keep it — and what actually deletes it when that time is up.
If a row has no legal basis, you have found either a data flow to remove or a reason to write down. That spreadsheet becomes the backbone of your Article 30 processing record, your privacy notice, and your answers when someone asks what you hold on them.
Cookie consent: the details that decide whether it counts
Under the ePrivacy rules, non-essential cookies and similar tracking require prior consent. Prior means before the script fires, not after the visitor scrolls past a banner. This is the single most common failure point on business websites.
What a workable consent setup needs
- Reject as easily as accept. No hidden "Manage preferences" link as the only alternative to a bright Accept button.
- No pre-ticked boxes. An unticked box that the visitor never touches is not consent.
- Granular choices. Analytics, advertising, and functional cookies are separate purposes, so they get separate toggles.
- Nothing non-essential loads before a choice. Test with your browser's developer tools and look at the network requests on first load.
- Consent records. Store a timestamp, the version of the notice shown, and the toggles the visitor selected.
- An easy way to change their mind. Withdrawal must be as simple as giving consent — a persistent link in the footer works well.
- An accurate cookie list. Name, provider, purpose, and duration for each one. Update it when you add a tool.
Cookie walls — where access depends on accepting tracking — are a risky pattern and generally treated as invalid consent unless a genuine equivalent alternative is offered. If your business model depends on one, get proper advice before building it.
Privacy notices people can actually read
Your notice has to cover a defined set of information: who the controller is and how to reach them, the purposes and legal bases for processing, the recipients or categories of recipients, any transfers outside the EU and the safeguards used, retention periods, and the full list of visitor rights, including the right to complain to a supervisory authority.
Write it in plain sentences, and use a layered structure: a short summary at the top, detail underneath for those who want it. Link it in the footer and at the point of collection — right next to the form fields, not three clicks away. If you use a chat widget, a newsletter form, and a checkout, each of those is a moment where the visitor's attention is on the data you are asking for.
Data subject requests: build the process before the request arrives
An access, deletion, correction, or portability request has a deadline of one month, extendable by two further months for genuinely complex cases, and it is normally free. Names, dates, and the action taken belong in a single log so nothing depends on one person's memory.
Practical points that save trouble: verify identity proportionately — do not demand a passport scan for a newsletter unsubscribe — reply in a commonly used electronic format, and make sure whoever answers the contact address knows where to forward a request. Search every system, including backups and the support inbox, before you declare that no personal data is held. If a request arrives that you cannot fulfil, for example because a legal retention obligation applies, explain why clearly and on time.
Records, suppliers, and the quiet obligations
Keep your processing record current, and put a written data processing agreement in place with every vendor that handles personal data on your behalf — hosting, email, analytics, support tools. Check where those vendors store data and how transfers outside the EU are covered. Set retention periods that match what you told visitors, then actually delete on schedule. Finally, know your breach path: if a personal data breach is likely to risk people's rights, you generally have 72 hours to notify the supervisory authority, so decide in advance who assesses incidents and who makes that call.
What to do first
If this list feels long, pick three items this week: audit which cookies fire before consent, make your reject button as visible as your accept button, and create the request log. Those three close the gaps that attract the most complaints. Then work through the data map, tighten the notice, and tidy up vendor contracts over the following month.
This is general guidance rather than legal advice. GDPR obligations depend on what your site actually does with data, so for anything involving special category data, large-scale tracking, or transfers outside the EU, have a qualified data protection professional review your setup.
Photo: Mikhail Nilov / Pexels
