Search every question across sub-FAQs

A cookie wall is high risk when it blocks website or app content unless the user accepts cookies, pixels, SDKs, local storage, or similar access to terminal equipment that is not strictly necessary. Article 5(3) ePrivacy analysis starts before GDPR processing analysis: check whether the service stores information on the user's device or gains access to information from it, including through browser cookies, JavaScript, pixels, tracked links, identifiers, or client-side code.

If consent is required, the GDPR consent standard applies. EDPB guidance gives a direct example: blocking content with only an "accept cookies" button does not present a genuine choice, so the consent is not freely given. A cookie wall does not become valid merely because the banner describes tracking or records a click.

The EDPB cookie-wall reply also cautions against overclaiming a single blanket answer: it noted that the French court decision discussed there did not decide whether cookie walls are lawful on the merits, and that the ePrivacy Directive remained the applicable framework while consent under ePrivacy had to meet GDPR standards. Treat national implementation and regulator practice as part of the review instead of inventing a universal country rule.

Keep evidence that lets a reviewer reconstruct what the user saw, what technologies ran before and after each choice, and what access remained available without optional consent. The evidence should be tied to the deployed CMP or banner version, not only to a policy statement.

The most important caveat is national law. The Cookie Banner Taskforce states that placement or reading of cookies is assessed under the national law transposing the ePrivacy Directive, while GDPR concepts such as valid consent are indispensable to the analysis. Record the countries in scope and escalate local-law questions when a cookie wall, paid alternative, media access model, or subscription path is material.

In most EU analytics implementations, yes. Article 5(3) of the ePrivacy Directive covers storing information on, or gaining access to information already stored in, the terminal equipment of a subscriber or user. EDPB technical-scope guidance treats cookies, JavaScript instructions that send browser data, tracking pixels, tracked URLs, local processing results sent to a server, and unique identifier collection as potential Article 5(3) access or storage scenarios.

The answer does not turn on the vendor label "analytics". A product team should classify the real mechanism: which cookie, SDK, pixel, script, local-storage item, app identifier, or server-side measurement flow is used; what identifier or event data leaves the device; whether a third party receives or reuses it; and whether the user can use the requested service without it.

WP29 guidance says first-party analytics cookies are often useful to website operators but are not strictly necessary to provide a functionality explicitly requested by the user. That means the ordinary position is consent, unless the implementation fits a specific exemption path in the applicable national law or supervisory-authority guidance.

A limited analytics exemption is not an EU-wide rule in the Directive text. CNIL's analytics sheet is French regulator guidance: it says audience-measurement tracers generally require consent unless they fall exactly within its defined perimeter, and it warns that the position may vary under national law and local authority guidance.

Under CNIL's conditions, the implementation must inform users, give them the ability to object, limit purposes to audience measurement or A/B testing, avoid cross-checking with customer files or statistics from other sites, limit the tracer to one site or application editor, truncate the last byte of the IP address, and limit tracker lifetime to 13 months. A third-party processor can support multiple publishers only if data and trackers are collected, processed, stored, and kept independent for each publisher.

Treat the exemption as a configuration- and jurisdiction-dependent claim. First confirm that the applicable Member State recognizes the route. Then verify the deployed product against every local condition. For the cited CNIL route, missing proof of purpose limitation, a working opt-out, single-editor scope, IP truncation, a maximum 13-month tracker lifetime, no customer-file or cross-site matching, or independent per-publisher processing prevents reliance on that route.

Keep two evidence bundles: one for the Article 5(3) classification and one for the consent or exemption implementation. The classification file should show whether the analytics technology stores information, gains access to stored information, or instructs a browser or app to send identifiers or event data over a network.

For consent-required analytics, keep the consent banner configuration, the versioned consent text shown to the user, the category mapping that places the analytics tag behind the analytics toggle, proof that tags do not fire before consent, accept and reject UI evidence, and consent logs with timestamp, jurisdiction or locale, banner version, choice, withdrawal events, and the tag state applied after the choice.

For exemption-based analytics, keep the product and configuration evidence showing every exemption condition actually met, plus the national source used for the exemption decision. Recheck the file when the analytics vendor, SDK version, tag manager rule, data sharing setting, retention period, cookie lifetime, country rollout, or measurement purpose changes.

Document the country caveat every time the answer depends on an analytics exemption. The ePrivacy Directive is implemented through national laws, and the EDPB cookie-banner taskforce report frames cookie placement and reading complaints under national laws transposing the Directive. CNIL's exemption conditions are cited French supervisory-authority guidance, not a universal rule for every Member State.

Document the source caveat too: WP29 Opinion 04/2012 says first-party analytics cookies are not exempt under the Directive's two classic criteria, while CNIL guidance describes a conditional national opt-out path for tightly constrained audience measurement. If those sources point in different practical directions for a rollout country, escalate to local counsel or the local supervisory authority's guidance instead of inventing a country rule.

Do not add penalties, country-by-country rules, or enforcement outcomes unless the source for that exact jurisdiction supports them. This FAQ supports the analytics consent and exemption decision, not a penalty table.

Treat soft opt-in as available only when every Article 13(2) condition is documented before launch. The sender must have obtained the customer's electronic contact details in the context of selling a product or service. The same natural or legal person must send the campaign for its own similar products or services. Article 13(2) does not itself extend the route to prospects, bought or shared lists, affiliates, another group company, third-party offers, or unrelated products.

The customer also needs a clear and distinct chance to object, free of charge and in an easy manner, when the details are collected and in every later message if the customer did not initially refuse. Each message must disclose a valid address for stopping further communications and must not disguise or conceal the sender. If the sale record, collection screen, CRM record, similarity assessment, sender identity, or message template cannot prove those facts, do not rely on Article 13(2).

Keep evidence that proves the exact soft opt-in path, not a generic marketing approval. The record should connect the customer record, sale context, sender identity, product-similarity assessment, opt-out presentation, message template, and suppression-list enforcement.

Suppression evidence matters because Article 13(2) depends on the customer not having initially refused and on the customer receiving a continuing objection opportunity. A working suppression list should record collection-stage refusals, later unsubscribe requests, bounced or invalid stop addresses, and downstream systems where the block must be honored before the next send.

Escalate when any condition depends on interpretation: whether a free trial is a sale, whether a service renewal is similar enough to a new product, whether a group affiliate is the same sender, whether the collection notice was clear, or whether national law adds stricter rules for a channel, recipient type, or local implementation.

The ePrivacy Directive is implemented through national law. Article 13(3) leaves Member States a choice for other direct-marketing cases, and Article 13(5) requires protection for subscribers that are not natural persons under Union and applicable national law. The Commission's 2017 proposal for a directly applicable ePrivacy Regulation was withdrawn in 2025, so it does not replace those national variations. Do not add country-specific rules, penalties, or exemptions unless they are separately sourced for the relevant country.

EU-level source material does not phrase Article 5(3) as a literal, standalone command to use the words "reject all". The safer operational rule is stronger than a wording debate: if a banner presents an accept-all control for consent-based cookies, SDKs, pixels, local storage, fingerprinting, or comparable storage/access, it should also present a clear refuse, reject, or continue-without-consenting option at that same decision layer.

The EDPB Cookie Banner Taskforce reported that a vast majority of authorities considered the absence of refuse/reject/not-consent options on any layer with a consent button to be inconsistent with valid consent and an ePrivacy infringement. The same report notes a minority view that Article 5(3) does not explicitly mention a reject option, so teams should avoid saying there is one uniform EU statutory label and instead document the applicable national implementation and regulator guidance.

EU-level sources do not set a universal pixel-for-pixel prominence rule. The Cookie Banner Taskforce reached a common view that banners must not be designed in an obviously misleading way that pushes users to consent, while particular colour and contrast complaints require case-by-case assessment. National authorities may impose more specific presentation rules.

Review the live interaction, not only the design file. A refusal link hidden in a paragraph, made unreadable through contrast, or placed behind navigation that the accept action does not require can impair a genuine choice. The refusal control should operate before consent-required storage or access and block the same optional purposes covered by the accept-all control.

Keep enough evidence to prove both sides of the consent choice: the user-facing refusal path and the technical result after refusal. A screenshot alone is not enough if tags still fire, local storage is populated, or SDKs access device information before or despite rejection.

Consent records should also preserve the banner version, language, country or market setting, purposes shown, vendor/category configuration, timestamp, and withdrawal route. The EDPB consent guidance says controllers must be able to demonstrate valid consent, while the cookie banner taskforce expects website owners to maintain cookie lists and demonstrate why claimed essential cookies are essential where requested.

First, Article 5(3) applies broadly to storage of, or access to, information on terminal equipment; it is not limited to browser cookies or personal data. That means a reject-all review should cover pixels, app SDKs, local storage, unique identifiers, fingerprinting signals, and other similar technologies that store or access device information.

Second, cookie placement or reading is governed by national laws transposing the ePrivacy Directive, while later personal-data processing may also need GDPR analysis. The EDPB taskforce describes its banner positions as a common denominator and says they must be combined with additional national requirements and competent-authority guidance. This FAQ therefore should not be used to infer country-specific rules, penalties, or regulator deadlines that are not separately sourced.

Treat the exemption as a cookie-by-cookie, purpose-by-purpose test. For the transmission exemption, the communication must not be possible without the cookie or similar storage/access operation; a cookie that merely helps, speeds up, measures, or improves the service is not enough.

For the user-requested service exemption, the user must have taken a positive action to request a clearly defined service or feature, and the cookie must be strictly needed for that feature to work. The test is from the user's point of view, not from the website operator's preference for measurement, monetization, personalization, or operational convenience.

WP29 treats first-party user-input session cookies as a core example where the user requested the feature, such as completing a form over several pages or adding items to a shopping basket. The cookie should remain tied to that action and normally expire with the session. Limited extra persistence needs its own justification based on what the user requested and reasonably expects, such as recovering a recently closed basket.

Session authentication cookies can also qualify where they are needed to keep the user authenticated across page requests for a service the user logged into. User-centric security cookies can qualify when they protect that requested login service, such as detecting repeated failed login attempts. Those examples do not authorize secondary uses such as behavioral monitoring, advertising, or cross-site tracking.