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. It 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. The timing is not 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, 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 show what regulators are willing to litigate. The report shows 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 most important pattern in 2025 and 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 anyway, either right away, on the next page load, or both.

This is what cost SHEIN €150M. Investigators clicked reject and watched the network tab. Trackers kept firing. The regulator's position is simple. If your site sets analytics or advertising cookies for a user who has rejected them, you do not have consent, and the reject button 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 platform has passed along the user's choice, and the cookies set during that window are never cleaned up. The second is consent-state caching. The platform records the rejection in localStorage, but the page reads consent from a stale in-memory value and lets the tags through.

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

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

The report restates a position the French DPA has enforced 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 2026 report goes further than the 2023 version by treating "equal prominence" as something you can measure: same surface area, same contrast, same number of clicks to the 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, with the same size, weight, and color treatment (or a deliberate inversion). And it produces the same end state as accept in terms of clicks: one click closes the banner and records the choice.

If your consent tool ships a default that puts reject behind a settings link, change the default. The 2023 report left some room for argument here. The 2026 report does not.

Re-prompting is the next enforcement target

The taskforce called out 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 you ask again, with an exception for material changes to your cookie inventory.

In practice: 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 whole consent flow because someone cleared their cookies and came back two days later is exactly the pattern regulators are watching 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 appear on every page where the original banner appeared. 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. The preferences link only shows up in the homepage footer, or it opens a settings panel where the only obvious action is "Save preferences" with every toggle 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 on its own 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 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 is the same law, applied to implementation details that were tolerated five years ago and are not anymore.

If you would 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.