Reject means reject: what the EDPB's April 2026 report (and the SHEIN fine) say about your cookie banner

On April 27, 2026, the European Data Protection Board published a follow-up report from its Cookie Banner Taskforce. The report is the first time since 2023 that the EDPB has restated, as a full Board-level position, what it expects a compliant consent flow to look like — and the timing isn't an accident. In the eight months before publication, regulators issued some of the largest cookie-related fines on record: €325M against Google and €150M against SHEIN, both from the French data protection authority (DPA), both in a single September 2025 decision day.

If you build the consent layer on a website that serves European users, the report and those fines are essentially one document. The fines tell you what regulators are willing to pay legal teams to litigate. The report tells you what they are looking for next. They point to the same handful of failure modes, and most of them are implementation problems, not policy problems.

The "fake reject" is what's getting fined

The single most important pattern in 2025–2026 enforcement is what the EDPB calls "ineffective rejection." It is not a banner-design issue. It is the case where a user clicks "Reject all," the banner disappears, and non-essential cookies keep firing — either immediately, on the next page load, or both.

This is what cost SHEIN €150M. Investigators clicked reject and then watched the network tab. Trackers continued to fire. The DPA's position is straightforward: if your site sets analytics or advertising cookies for a user who has rejected them, you do not have consent, and the rejection control on your banner is decorative.

Two things make this easy to get wrong. The first is asynchronous tag loading: a tag manager fires before your consent management platform (CMP) has propagated the user's choice, and the cookies set during that window are never cleaned up. The second is consent-state caching: the CMP records the rejection in localStorage, but the page-load sequence reads consent from a stale in-memory variable and lets tags through.

The fix in both cases is to verify on a subsequent load. Put the site in an incognito window, click reject, close the tab, and open the page again. Then look at what's in document.cookie and what requests left the network panel before any user interaction. If anything non-essential is there, the rejection isn't holding.

Equal prominence is now a technical requirement, not a design preference

The EDPB report restates a position the French DPA has been enforcing for over a year: the reject control must be as easy to use as the accept control, on the first layer of the banner. The report goes further than the 2023 version by treating "equal prominence" as a measurable property — same surface area, same contrast, same number of clicks to outcome.

For implementation, that means three things. The reject button lives on the first screen of the banner, not behind "Manage preferences" or "More options." It uses the same component as the accept button (same size, same weight, same color treatment, or a deliberate inversion). And clicking it produces the same end-state as accept does in terms of clicks: one click closes the banner and records the choice.

If your CMP ships a default that puts reject behind a settings link, change the default. The 2023 report left some ambiguity here. The 2026 report does not.

Re-prompting is the next enforcement target

The taskforce explicitly flagged immediate re-prompting — showing the banner again on the next page load after a user rejects — as a dark pattern. Several DPAs are converging on a six-month minimum interval before re-asking, with an exception for material changes to your cookie inventory.

Practically: when a user rejects, store that decision with a timestamp and respect it for at least six months. If you add a new vendor or a new purpose, you can re-prompt — but only for the new item, and only with a banner that explains what changed. Re-prompting the entire consent flow because someone cleared their cookies and came back two days later is the pattern regulators are looking for.

Withdrawal has to be as easy as giving

Article 7(3) of the GDPR has always required this; the new report is explicit that the floating "Cookie preferences" link or icon must be present on every page where the original banner appeared, and clicking it must take the user to a control that can withdraw consent in the same number of clicks it took to give it.

A surprising number of sites pass the first audit and fail this one, because the preferences link only appears in the footer of the homepage, or because it opens a settings panel where the only obvious action is "Save preferences" with all toggles still on.

A short audit you can run this week

Open your site in a fresh incognito window, click reject on the banner, close the tab, and reopen the page. Then check, in this order:

• The banner does not reappear automatically on the next visit
• document.cookie contains nothing non-essential
• The network panel shows no analytics or advertising requests before any interaction
• A "Cookie preferences" control is visible somewhere on the page
• Clicking that control lets you withdraw or change consent without going through a multi-step settings menu

If any of those five fail, you have a finding the EDPB report is asking regulators to look for. None of them require a policy change. All of them are fixable in the consent layer.

The 2026 enforcement environment is not new law. It's the same law, applied to implementation details that were tolerated five years ago and aren't anymore.

If you'd rather not run that audit by hand on every site you own, CookieGap does the reject-and-reload scan automatically and flags exactly these patterns.