The GDPR consent test most cookie banners quietly fail

In 2024, a small e-commerce store was fined €25,000 because its privacy policy had been copied from a template. The clauses described data processing the store didn't actually do, and left out several things it did: the kind of mismatch that only shows up once a regulator, or a customer's complaint, actually reads the document against what the site is doing. Nobody at the company thought they were breaking the law. They thought they'd handled it.

That gap between "we have a privacy policy" and "our privacy policy is accurate" is where most GDPR exposure actually lives. The regulation applies the moment your website collects personal data from a single EU resident, regardless of where your business is based, and the well-known number (fines up to €20 million or 4% of global revenue) is the ceiling, not the typical outcome. The typical outcome for a small site is a few thousand to a few tens of thousands of euros, usually triggered by a complaint about the exact thing that gets skipped: a cookie banner with no real choice in it, or a signup form nobody reads before writing.

You don't need a legal team to close most of that gap. You need to understand what actually counts as consent, because most cookie banners and signup forms fail a specific, checkable test without anyone noticing.

The five-part test that decides whether consent is real

GDPR Compliance for Business Websites lays out the legal definition of valid consent as a five-part test, and it's specific enough to run against your own site in about two minutes. Consent must be:

1. Freely given: the user faces no penalty or degraded service for declining.
2. Specific: a separate, distinct consent for each purpose, not one checkbox covering everything.
3. Informed: a clear explanation of what they're agreeing to, before they agree to it.
4. Unambiguous: an active opt-in action, never a pre-checked box someone has to notice and uncheck.
5. Revocable: a way to withdraw consent that's as easy as giving it.

Most non-compliant cookie banners fail on two and four at once: one "Accept" button covers analytics, marketing, and functional cookies together, and it's pre-selected so that closing the banner counts as agreement. That's not a technicality. Bundling purposes removes the "specific" requirement, and a default-on toggle removes "unambiguous": the whole design assumes inaction as agreement, and GDPR explicitly rules that out.

The book's worked example is a newsletter signup, and it's a useful template because the same logic applies to almost any form on a site. A compliant signup collects only the email address at first, nothing else, no phone number "just in case." It states plainly what the subscriber is agreeing to receive and how often. It links to the privacy policy at the point of signup, not buried in a footer three clicks away. It uses a double opt-in, so the email address itself is confirmed by its owner rather than assumed. And it offers granular choices: a subscriber who wants product updates but not promotional offers can say so, rather than getting an all-or-nothing toggle.

Run your own forms against the five-part test and the failures tend to be structural, not exotic: a contact form that also signs people up for marketing without saying so, a cookie banner where "Reject All" takes three more clicks than "Accept All," a checkbox pre-ticked because someone assumed more signups beats fewer. None of these require sophisticated tracking to notice. They require reading your own form the way a regulator, or an annoyed visitor, would.

Where people go wrong

The template-privacy-policy failure that opened this post is the most common one, and it's rarely deliberate. A business owner finds a policy online, swaps in the company name, and treats the document as finished. The problem is that GDPR doesn't grade a privacy policy on how legal it sounds. It grades it on whether it accurately describes what the site actually collects and why. A template written for a SaaS company will describe subscription billing data a five-page brochure site never touches, and it will miss the analytics cookie the site added six months later. The fix isn't a better template. It's writing the policy from your own data inventory: what you collect, why, and how long you keep it.

The second failure mode is the pre-checked box, already covered above, but worth naming separately because it's the single most common reason cookie consent gets challenged. If a checkbox starts ticked, or if declining requires more effort than accepting, the consent it produces isn't valid regardless of how the banner is worded.

The third is collecting data "just in case" and never revisiting it. A form field for a phone number nobody calls, a customer account field for a birthday nobody uses: each one is a small liability that serves no purpose, sits in a database indefinitely, and becomes one more thing to explain if a data subject ever asks what you hold on them. The full digital safety guide covers this alongside the account-security side of running a site, since the two problems (what you expose to attackers, and what you're obligated to disclose to regulators) tend to trace back to the same sloppy data habits.