GDPR and Your Website: Cookies, Forms, and Data Handling Done Right

A client once forwarded us a screenshot of their own website with the message "is this a problem?" It was a cookie banner with a bright green "Accept All" button front and center, and a "Manage preferences" link in pale grey text underneath it, two clicks deep to actually reject anything. The banner had been installed correctly, in the sense that it appeared on every page and logged a timestamp. It was also, in the way it was designed, exactly the kind of pattern that data protection authorities have been fining companies for since 2020. The plugin was doing its job. The configuration wasn't doing GDPR's.

That gap, between "we have a cookie banner" and "we are actually GDPR compliant", is where most small business websites live. Not because anyone is being reckless, but because GDPR compliance for websites is usually treated as a one-time checkbox during launch rather than something that needs to hold up under real scrutiny. This isn't a legal explainer of the regulation itself; it's a practical look at the parts of a website (cookies, forms, the privacy policy, and the scripts running quietly in the background) that tend to be wrong even on sites built by people who meant to get it right.

The cookie banner most sites get wrong

The legal standard for cookie consent under GDPR (and the ePrivacy rules that sit alongside it) is simple to state and easy to violate: consent has to be freely given, specific, informed, and as easy to withdraw as it was to give. In practice, that means a genuine choice, not a nudge toward one outcome.

A few things separate a compliant banner from a decorative one:

• Accept and reject need equal visual weight. If "Accept All" is a solid colored button and "Reject" is a text link, a grey ghost button, or buried behind a "Settings" click, that's not a free choice, but a design pattern built to push people toward the answer you want. Regulators in several EU countries have explicitly called this out as non-compliant.
• Consent has to be categorized, not all-or-nothing. Necessary cookies (the ones that make the site function: session handling, security, load balancing) don't need consent. Analytics cookies, marketing/advertising cookies, and anything used for cross-site tracking do. A compliant banner lets someone accept analytics but reject marketing, rather than forcing an all-or-nothing decision.
• No pre-ticked boxes. If a consent toggle defaults to "on," it isn't consent. It's an opt-out disguised as an opt-in. Every non-essential category should start off.
• Rejecting has to be as easy as accepting. One click to accept, three clicks and a sub-menu to reject fails the "as easy to withdraw" test even if the banner technically offers a reject option somewhere.

Here's the part that trips up even well-intentioned setups: the banner is only half the job. The other half is what happens technically before someone answers it. A shockingly common pattern is a site where the analytics script, the ad pixel, and the chat widget all load and start firing the moment the page renders, while the cookie banner sits on top, visually blocking nothing. The visitor sees a consent request; the tracking has already started. That's not a subtle technicality. If a script sets a cookie or sends data to a third party before consent is recorded, the consent banner is theater, not compliance. Non-essential scripts need to be genuinely blocked (not loaded and hidden, but not loaded at all) until the relevant consent category is accepted, and they need to stop again cleanly if consent is withdrawn.

Cookie category	Consent required?	Typical examples
Strictly necessary	No	Session cookies, load balancing, security, cart contents
Analytics / performance	Yes	Google Analytics, Hotjar, heatmap and session-recording tools
Marketing / advertising	Yes	Ad pixels, retargeting scripts, cross-site tracking cookies
Functional (non-essential)	Usually yes	Embedded video preferences, chat widget history, third-party fonts with tracking

Getting this right technically (actually gating script execution behind consent state, rather than just displaying a banner) is implementation work, not just a policy decision, which is one of the reasons cookie consent tends to quietly rot over time as new tools and tracking pixels get added to a site without anyone updating the consent logic to match.

Contact and lead-capture forms: collect less, explain more

Every form on a website is a small data collection event, and GDPR applies to it whether it's a two-field contact form or an eight-field quote request. Two habits fix most of the common problems.

The first is data minimization: only ask for what the stated purpose actually requires. A newsletter signup needs an email address. It doesn't need a phone number, a company size, or a job title unless that information genuinely changes what gets sent. A contact form needs enough to respond to the enquiry: name, email, and the message itself is usually sufficient. Every additional required field is data you now have to secure, retain, and justify holding if someone asks why you have it. It also tends to hurt conversion rates, which makes minimization one of the rare cases where GDPR compliance and good UX point in the same direction.

The second is being specific about purpose at the point of collection, not just linking to a general privacy policy and calling it covered. "By submitting this form you agree to our privacy policy" is common, but it puts the burden on the visitor to go find, read, and interpret a separate document to understand what happens to the information they're about to submit. A short, specific line next to the form does more of the actual informing: "We'll use this information to respond to your enquiry and won't add you to any marketing list unless you opt in below." If a form doubles as a marketing list signup, that should be a separate, unticked checkbox, not bundled into submitting the form itself.

This matters more on lead-capture and quote-request forms than on simple contact forms, because they tend to collect more (budget range, company details, project scope) and because the data often flows into a CRM or an email marketing tool immediately after submission, which is itself a third-party data transfer worth being aware of and disclosing.

What a privacy policy actually needs to cover

Most privacy policies fall into one of two failure modes: generic boilerplate copied from a template that doesn't reflect what the site actually does, or an accurate policy so dense with legal language that no visitor will ever read it. Neither is particularly useful, but the boilerplate version is the riskier one, because it creates a written record of what you claim to do that may not match reality.

A privacy policy that's actually doing its job covers, in plain language:

• What data is collected, and from where: forms, cookies, analytics, account creation, payment processing if applicable.
• Why it's collected: the specific purpose for each category, not one blanket justification.
• How long it's kept: retention periods, even approximate ones ("contact form submissions are retained for 12 months unless an ongoing relationship continues").
• Who it's shared with: hosting providers, email marketing platforms, analytics tools, payment processors, and any other third party the data touches, along with whether any of them are outside the EU/EEA.
• How to exercise data subject rights: concretely, an email address or form to use, not just a citation of "Articles 15–22 of the GDPR."
• Contact details for privacy questions: a real, monitored inbox, not a generic info@ address that routes to nowhere.

The policy doesn't need to be long to be complete. It needs to be accurate, specific to the actual site, and written so a non-lawyer visitor can understand what happens to their information in under two minutes of reading.

Data subject rights: what to do when a request actually arrives

GDPR gives visitors and customers rights to access, correct, and delete their data (among others), and most guidance stops at listing them. The more useful question for a website owner is what actually happens the day someone emails asking to see or delete their data, because it will eventually happen, even for a small site.

A workable process looks like this:

• Access requests: confirm what personal data you hold on the person (form submissions, CRM entries, email list membership, order history) and provide it in a clear format. This is usually a manual pull from a CRM or database export, not something that needs automated tooling for a small site.
• Rectification requests: correct inaccurate data (a misspelled name, an outdated address) across every system it lives in: CRM, email platform, and any spreadsheet exports, not just the primary database.
• Erasure requests: delete the data from all systems it was copied into, keeping in mind that "delete from the website" often isn't the whole job if the same data was synced into a mailing list tool or a CRM.
• Respond within one month. That's the standard GDPR timeframe for these requests, extendable in genuinely complex cases, but a month is the default expectation to plan around.

The practical failure mode isn't malice, but not knowing where all the copies of someone's data actually live. A contact form submission that gets forwarded by email, added to a spreadsheet, and synced into an email marketing tool has effectively been copied three times, and an erasure request needs to reach all three. Keeping a simple internal map of "where personal data flows on this site" makes these requests take twenty minutes instead of becoming a scramble. It's also the kind of thing worth revisiting whenever a new tool gets added to the site, which is part of why compliance tends to be an ongoing task handled through regular website maintenance rather than something finished once at launch and never touched again.

Third-party scripts and embeds: the surface everyone forgets

This is the part of GDPR compliance that catches out the most careful site owners, because it's invisible unless you go looking for it. Every embed or third-party script added to a site is a potential data transfer, and most get added one at a time, by different people, over months or years, without anyone reassessing consent coverage each time.

Common offenders:

• Analytics tools (Google Analytics, Hotjar, Meta Pixel) set cookies and send behavioral data to the provider's servers. This needs explicit, categorized consent, not just a mention in the privacy policy.
• Embedded YouTube or Vimeo videos can set tracking cookies the moment the page loads, before anyone even presses play, depending on the embed mode used. A "privacy-enhanced" embed mode exists for a reason.
• Social share buttons from platforms like Facebook or LinkedIn often load tracking scripts from that platform just by being present on the page, whether or not a visitor ever clicks them.
• Chat widgets frequently set their own cookies to persist conversation history and may transfer message content to a third-party server outside the EU.
• Ad pixels and retargeting tags are the most obviously consent-dependent category, but they're also the ones most likely to be left firing by default because they were set up once by an ads agency and never revisited.

The fix isn't necessarily to remove these tools. Most are genuinely useful. It's auditing what's actually running on the site (a browser's network tab or a cookie-scanning tool will show this quickly), matching each script to a consent category, and confirming it's technically blocked until that category is accepted. This is also where the general website compliance covered here connects to a more specific concern: if the site uses AI-powered chat, content generation, or personalization tools, those introduce their own data handling questions on top of everything above, covered in more depth in our practical AI and GDPR compliance checklist, which builds on this same foundation for AI-specific tools.

Treat this as a foundation, not a finish line

None of this is exotic. A properly categorized, genuinely opt-in cookie banner; forms that ask for less and explain more; a privacy policy that matches what the site actually does; a clear process for handling rights requests; and an honest audit of every third-party script quietly running in the background: together these cover the large majority of what GDPR actually expects from a typical business website. The gap between having these things and having them work correctly is almost always in the implementation details: whether scripts are truly blocked before consent, whether the policy was updated the last time a new tool was added, whether anyone actually knows what happens when a deletion request lands in the inbox.

This article is general information based on common GDPR requirements and practical experience building compliant websites. It isn't legal advice, and GDPR obligations can vary depending on what a business collects, processes, and where its users are located. For decisions specific to your business, it's worth involving a qualified data protection advisor or legal professional alongside the technical work.

If you're not confident your site's cookie consent, forms, or privacy policy would hold up to a closer look, that's exactly the kind of thing we build correctly from the ground up as part of our custom web design work, or we can review and fix what's already there. Get in touch and we'll take a look.