Skip to main content
Back to Guides
Compliance5 min read

A Cookie Plugin Alone Won't Make You Compliant

Installing a well-known consent plugin and watching the banner appear feels like the job is done. It isn't. noyb filed 226 complaints against companies running one of the biggest CMPs. The tool isn't compliance, the configuration is.

The banner appeared, so we're covered, right?

The usual story goes like this: you install a well-known consent plugin, a banner shows up on the site, and the compliance item gets ticked off the list. The trouble is that the banner appearing and the site being compliant are two different things. In 2022, the privacy group noyb filed 226 formal GDPR complaints against companies that had installed OneTrust, one of the largest consent platforms in the world, and were still non-compliant. The tool wasn't the problem. The default settings and the missing configuration were.

The law makes you responsible, not the plugin

Under the GDPR, the data controller (that's you, the website operator) is accountable for compliance, and Article 24 says so directly: the controller has to implement appropriate measures and be able to demonstrate that processing is lawful. A consent tool is a processor or, often, just a piece of software you configure. You can't hand your accountability to it. When a banner is set up wrong, the regulator's decision names the website, not the vendor. "We used a reputable plugin" has never been a defence.

Default settings are frequently non-compliant

Plenty of consent plugins ship with defaults that fail out of the box: an "Accept All" button with the reject option buried or absent, non-essential categories pre-enabled, no actual blocking of scripts before consent, and a generic cookie list that has nothing to do with your site. A 2025 audit of 10,000 EU sites found 78% of banners non-compliant, and a large share of those sites had a plugin installed. The plugin handed them the parts. Nobody assembled them correctly. See why 'accept all' only banners get fined and why most cookie banners fail.

The plugin doesn't know your cookies

A consent tool can only describe what it has been told about. Out of the box it doesn't know which analytics, advertising, and embedded third-party scripts actually run on your pages. If you skip the scan and don't map each cookie to a purpose, your banner shows a generic or borrowed cookie list, which fails the requirement that consent be specific and informed. The list a regulator compares against your live traffic has to be yours. See how to audit your website's cookies.

Prior blocking is the part that's most often missed

The single most common configuration gap is blocking. Consent has to come before non-essential cookies are set, which means the tags have to be held until the visitor opts in. A banner that displays but lets Google Analytics and ad pixels fire on page load is decorative: it records a choice the site then ignores. Many plugins don't block automatically, they expect you to tag or gate each script, or to wire up Consent Mode. Install it and forget it, and the tracking runs regardless of what anyone clicks.

Consent records are on you too

If a regulator or a user asks you to prove consent, "the plugin handles it" won't do. You need retrievable, timestamped records of who chose what and when. Some tools don't log at all, and some log to a place you've never exported. Confirm that your setup captures proof of consent and that you can actually produce it. See proof of consent documentation.

It's not set-and-forget

Cookie law keeps moving. Reject-button rules, Consent Mode v2, and regional obligations have all changed in the last two years, and your own cookie list changes every time you add a marketing tool or an embed. A one-time install captures a single moment and then drifts out of date. Compliance is a process you maintain, not a checkbox you tick once. See why consent management is an ongoing process.

Being a big-name customer isn't a shield

The instinct is that a market-leading tool must keep you safe. noyb's OneTrust wave showed the opposite. After an earlier round of warnings in 2021, many sites running the same software fixed their banners, and the 2022 complaints went to the ones that hadn't. Same software, opposite outcomes, and the difference was entirely in how each site had it configured. The vendor's name on your banner tells a regulator nothing about whether your specific setup obeys the law.

Five settings worth checking today

If you inherited a plugin someone installed months ago, open its configuration and confirm five things: there's a Reject option as easy as Accept on the first layer; no non-essential category is pre-enabled; scripts are actually held until consent (reload with developer tools open and watch); the cookie list came from a scan of your own site, not a template; and consent choices are logged somewhere you can export. If any of those is off, the banner is running but the compliance isn't.

What actually makes you compliant

Choosing a tool is step one, not the finish line. The configuration is what counts: scan your real cookies, block non-essential ones until consent, put a reject option of equal prominence on the first layer, pre-select nothing, adapt to the visitor's region, log every decision, and review it on a schedule. A platform like CookieBeam does the scan, blocks before consent, ships an equal-prominence Reject All, and logs choices by default, so the compliant setup is where you start rather than something you have to hand-assemble. Even then, you're the controller: check that it reflects your site, and keep checking. Start with the GDPR cookie compliance checklist.

Sources

  • noyb, 226 complaints lodged against deceptive cookie banners (websites using OneTrust software, Aug 2022), noyb.eu
  • GDPR Article 24 (responsibility of the controller), gdpr-info.eu
  • EDPB Guidelines 03/2022 on deceptive design patterns, edpb.europa.eu
A Cookie Plugin Alone Won't Make You Compliant | CookieBeam | CookieBeam