Use these test cases to check whether a cookie banner lets users make, refuse, change, and prove Article 5(3) consent choices before non-essential storage or access occurs.
Built for privacy, product, analytics, marketing, engineering, and CMP owners who need concrete pass/fail checks rather than generic cookie-banner advice.
Structured answer sets in this page tree.
Cited legal and guidance references.
Run these test cases against the deployed banner and the network behavior it controls. Each case states the user journey, expected result, evidence, and the limited conclusion the test supports. The EDPB Cookie Banner Taskforce report coordinates authority views but expressly does not replace national transposition law or case-by-case assessment, so record the Member State requirements used for the final pass or fail decision.
Open the page in a clean browser profile and inspect the first banner layer. If it offers an accept-all action for non-essential cookies, test whether the user also has a clear and usable way to refuse before any non-essential storage or access.
The EDPB Cookie Banner Taskforce reported that a vast majority of authorities considered the absence of any refuse, reject, or not- option on a layer containing a consent button inconsistent with valid consent. It did not create a binding EU-wide layout rule, and authorities did not agree on every visual-detail question. Evaluate placement, wording, contrast, keyboard focus order, and the applicable national position.
Click into the settings layer and inspect every purpose, vendor, and technology toggle. -required purposes should start off by default; the user's active selection should be needed before those purposes are enabled.
The test should also check granularity. If analytics, advertising, personalization, social plug-ins, and A/B testing are bundled behind one switch, the evidence should explain whether each purpose is being accepted separately or whether a single toggle is forcing to unrelated purposes.
After accepting non-essential cookies, test whether the same user can find a persistent route to change or withdraw . The route can be a footer link, privacy settings control, account setting, or CMP icon, but it must be available without unusual effort and without lowering the service level.
The withdrawal test is not complete when the UI flips a toggle. It should also confirm that -dependent tags stop, future reads or writes are blocked, downstream suppression signals are sent where used, and any deletion or retention behavior is documented.
Analytics requires its own test because teams often misclassify it as necessary. For a French exemption claim, current CNIL material requires audience measurement for the publisher's exclusive account, anonymous statistics, no cross-checking with other processing, no non-anonymous transmission to third parties, and no tracking across sites or apps. CNIL also recommends user information, a limited tracer lifetime, limited data retention, and periodic review. Other Member States can apply different national rules.
When those conditions are not met, analytics should behave like any other -required purpose: off before consent, controlled by a clear toggle, blocked after rejection, and stopped after withdrawal.
The final test is whether the organization can prove what the user saw, what the user chose, and what the technology did as a result. A correct-looking banner is not enough if the team cannot reconstruct the workflow at the time of the session.
Keep the evidence minimal but sufficient. EDPB guidance supports keeping records that show how consent was obtained, when it was obtained, what information was presented, and how the workflow met the criteria for valid consent.
Test the first layer whenever it contains an accept-all action, but do not treat one layout as a rule stated in the Directive. The EDPB taskforce reported broad authority concern where no refusal option exists on any layer with a button. Verify the current Member State position, keep the refusal route clear and usable, and prove that non-essential technologies stay blocked after refusal.
Only if the implementation has a documented exemption basis that matches the actual configuration. Otherwise analytics should be off before , controlled by a clear purpose toggle, and stopped after rejection or withdrawal.
Keep the banner text and screenshots, CMP configuration, purpose and vendor map, event, timestamp, tag release, network or storage trace, and withdrawal path for the version the user actually saw.
Sorena can turn these cookie banner UX checks into cited test scripts, owner assignments, CMP evidence requests, and release gates for Article 5(3) ePrivacy work.
Ask questions tied to cited sources about cookie banner UX, Article 5(3), analytics toggles, and consent evidence using the cited sources on this page.
Review your cookie banner test cases, CMP records, analytics settings, and ePrivacy evidence gaps with Sorena.
"future proof legal framework for online privacy"
"before depositing or reading a cookie or tracer"
"subscriber or user concerned has given his or her consent"
"case-by-case verification"
"demonstrate that valid consent has been obtained"
"Storage and access do not need to be cumulatively present"
"first party analytics cookies are not exempt from consent"