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 consent standard is the GDPR standard. The EDPB's consent guidance says consent only works where the user has control and a genuine choice to accept or decline without detriment. For cookie walls, that means a user should not be pushed into believing consent is required for access unless the access condition is tied to a strictly necessary service or functionality that the user explicitly requested.

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 blanket rule in the Directive text. The CNIL analytics sheet is useful grounded national 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 by national law and local data protection 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.

Product and privacy teams should therefore treat the exemption as a configuration-dependent claim. If the analytics product cannot prove independent per-publisher storage, no cross-site identifier, purpose limitation, IP truncation, short tracker lifetime, opt-out availability, and no advertising or customer-file reuse, use consent instead of presenting the tracer as exempt.

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 grounded 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 grounding 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 contact must be a customer contact collected in the context of a sale of a product or service. The sender must be the same natural or legal person that obtained the electronic contact details. The campaign must market that sender's own similar products or services, not unrelated offers, third-party offers, affiliate campaigns, or group-company lists.

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 again in every marketing message if the customer did not initially refuse. If the acquisition screen, checkout, order flow, CRM record, or message template cannot prove those facts, route the campaign to consent review instead of soft opt-in.

Keep evidence that proves the exact soft opt-in path, not a generic marketing approval. The file 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 has also described the proposed ePrivacy Regulation as a way to replace the current Directive with one directly applicable set of rules instead of national variations. Do not add country-specific rules, penalties, or exemptions unless they are separately grounded 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.

Equivalent does not mean every button must be visually identical, but the user must not be pushed toward acceptance by layout, wording, colour, contrast, or hidden navigation. A reject option embedded as a small text link, placed only in a later settings layer, or made unreadable through contrast can undermine the user's ability to understand and refuse the consent request.

Review the banner as a live interaction, not only as a design file. The control should be visible before consent-required storage or access occurs, describe the same category of choice as the accept control, and leave the user able to continue without consent unless a specific national rule or valid exception says otherwise.

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 has requested the feature, such as filling a form over several pages or adding items to a shopping basket. The cookie should be tied to the action and expire when no longer needed, with only limited persistence where that is justified by the user's reasonable expectation, 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.

Do not classify analytics cookies as strictly necessary under the general Article 5(3) exemptions merely because the site operator needs measurement. WP29 states that first-party analytics are often useful but are not strictly necessary for a user-requested website feature because the user can still access the site when those cookies are disabled.

Some national implementations or regulator guidance may create narrower analytics approaches or safeguards, but this page does not state country-specific exemptions. Before relying on analytics without consent, check the Member State law and competent authority guidance that applies to the website, the user group, and the deployment.

Retain the consent event, refusal event, and withdrawal event at purpose level, tied to the exact banner or preference-centre version shown to the user. Article 5(3) is triggered by storing information on, or gaining access to information in, terminal equipment; the log therefore needs to connect the user's choice to the cookies, pixels, SDKs, local storage, identifiers, or similar technologies deployed at that time.

The minimum useful record is: timestamp, jurisdiction or site/app surface, pseudonymous user or device/session key where needed, consent status, purpose and category, vendor or recipient list version, cookie/tracker inventory version, banner language/version, policy text version, consent string or preference payload, and whether optional storage or access was blocked until consent.

A log is useful only if it captures consent quality, not just a positive flag. Preserve signals showing that the user saw clear purpose information, made a granular affirmative choice, could refuse optional cookies or trackers, and could later withdraw without undue effort.

For review, keep the evidence that the CMP did not rely on silence, pre-ticked boxes, scrolling, inactivity, or a design that made acceptance look mandatory. If the banner changed, keep the old versioned proof because later screenshots do not prove what a user saw earlier.

The CMP log should not stand alone. It should point to the inventory that explains which cookies, pixels, SDKs, local-storage entries, tags, or identifiers were present, which were strictly necessary, which required consent, and which vendor or controller received resulting data.

When vendors, purposes, cookies, scripts, consent strings, or banner text change, version the inventory and the CMP configuration together. That versioning lets reviewers distinguish a historical valid choice from a later deployment that needs fresh consent or a new assessment.

A CMP log proves that the system recorded a stated choice under a particular configuration. It does not by itself prove that consent was valid, that the banner was lawful, that all trackers were disclosed, that optional tags were actually blocked, or that the right national authority would accept the implementation.

Use the log with screenshots or rendered banner copies, CMP settings, tag-manager release records, cookie scans, vendor lists, policy text, and withdrawal test results. Keep the national-law caveat explicit: cookie placement or reading is governed by Member State laws transposing the ePrivacy Directive, while subsequent personal-data processing may also be assessed under the GDPR.