---
title: "EU ePrivacy Directive FAQ: cookies, consent, marketing, GDPR interplay"
canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/faq"
source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/faq/items"
author: "Sorena AI"
description: "Answers to recurring EU ePrivacy Directive questions on Article 5(3), terminal-equipment access, cookie consent, exemptions, analytics, direct marketing, GDPR interplay, national enforcement, and evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU ePrivacy Directive"
  - "Article 5(3)"
  - "cookies"
  - "terminal equipment"
  - "cookie consent"
  - "direct marketing"
  - "GDPR interplay"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EU ePrivacy Directive FAQ: cookies, consent, marketing, GDPR interplay

Answers to recurring EU ePrivacy Directive questions on Article 5(3), terminal-equipment access, cookie consent, exemptions, analytics, direct marketing, GDPR interplay, national enforcement, and evidence.

*EU ePrivacy Directive FAQ* *Cookies, consent, marketing*

## EU ePrivacy Directive FAQ

Standalone answers for product, privacy, engineering, analytics, and marketing teams working through EU ePrivacy questions.

Covers terminal-equipment access, consent and exemptions, cookie-banner risks, direct marketing, GDPR overlap, national-law caveats, and evidence records.

Use this FAQ to answer concrete EU ePrivacy Directive questions before launching cookies, SDKs, pixels, analytics, communications-data processing, or electronic direct marketing. The Directive is implemented through Member State law, so these answers describe the EU baseline and flag where local law or regulator guidance must be checked. The rules apply to the electronic communications sector across the EU baseline, and in practice can affect EU-based and non-EU services that offer communications or tracking services to users in the EU.

## Browse sub-FAQ modules

### [Are cookie walls allowed under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cookie-walls.md)

FAQ answer on cookie walls under the EU ePrivacy Directive, covering freely given consent, refusal and withdrawal paths, banner evidence, and national-law caveats.

- 2 items

### [Do Analytics Cookies Require Consent under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md)

FAQ answer on analytics cookies under Article 5(3) ePrivacy, limited analytics exemptions, configuration evidence, consent logs, and national-law caveats.

- 4 items

### [EU ePrivacy soft opt-in FAQ for email marketing](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md)

When Article 13(2) soft opt-in can support EU customer email marketing, including existing-customer, similar-offer, opt-out, sender-identity, suppression-list, and national-law checks.

- 3 items

### [Is a reject-all button required for EU ePrivacy cookie consent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md)

Standalone FAQ answer on EU ePrivacy reject-all and refuse options for cookie banners, including equal prominence, deceptive UX, consent evidence, withdrawal, and national-law caveats.

- 4 items

### [Strictly Necessary Cookies under the EU ePrivacy Directive](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md)

FAQ answer on when EU ePrivacy Article 5(3) allows cookies without consent, with grounded examples, analytics caveats, evidence records, and national-law cautions.

- 3 items

### [What should CMP consent logs retain under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md)

FAQ answer on CMP consent logs for EU ePrivacy cookie consent: retained fields, consent validity signals, banner versioning, refusal and withdrawal events, proof limits, and national-law caveats.

- 4 items

Browse all indexed questions: [/artifacts/eu/eprivacy-directive/faq/items](/artifacts/eu/eprivacy-directive/faq/items.md)

## All FAQ items

*Page 1 of 1. Showing 20 of 20 items.*

### [Are cookie walls allowed under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cookie-walls.md#are-cookie-walls-allowed-under-the-eu-eprivacy-directive)

*Module: [Are cookie walls allowed under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cookie-walls.md)*

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.

- Do not set optional cookies before consent; the Cookie Banner Taskforce records that cookies requiring consent must not be set by default and consent needs a positive user action.
- Separate strictly necessary functionality from analytics, advertising, personalization, social plug-ins, affiliate tracking, pixels, and other tracking purposes.
- Offer a refusal route that is visible enough for the average user to understand; hiding refusal behind weak links, unreadable contrast, or deeper layers can undermine valid consent.
- If access depends on consent, document the alternative offered, such as access without optional cookies, a non-tracking route, or another access model, and explain why it provides a real choice.
- Keep the withdrawal path as easy to find and use as the consent path; the taskforce describes withdrawal at any time and withdrawal as easy as consent as cumulative consent conditions.

Sources for this answer:

- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports the cookie-wall consent test: consent must involve control, genuine choice, no detriment for refusal, informed purposes, and easy withdrawal.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports banner checks for default consent, accept and reject options, misleading design, essential-cookie classification, and withdrawal access.
- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports the technical scope review for storage or access to information on terminal equipment, including cookies, pixels, identifiers, and client-side instructions.

### [What evidence should a cookie-wall review keep?](/artifacts/eu/eprivacy-directive/faq/cookie-walls.md#what-evidence-should-a-cookie-wall-review-keep)

*Module: [Are cookie walls allowed under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cookie-walls.md)*

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.

- Screenshots or exports for the first-layer banner, second-layer settings, preference center, and withdrawal control.
- A scan or inventory showing cookies, local storage, SDKs, pixels, tracked links, identifiers, vendors, purposes, expiry, and whether each item runs before consent.
- Strictly necessary analysis for each exempted item, tied to the service or functionality explicitly requested by the user.
- Proof that reject, continue-without-accepting, and withdrawal routes are understandable, accessible, and not visually suppressed compared with acceptance.
- Country scope, national-law reviewer, product owner, CMP version, release date, and reassessment triggers for new vendors, purposes, layouts, or access models.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports retaining banner and CMP evidence for refusal, misleading design, essential-cookie classification, and withdrawal controls.
- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Supports the strict-necessity and explicitly-requested-service tests used to justify cookies that do not require consent.
- [European Commission ePrivacy factsheet](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - Supports the broader ePrivacy policy context that users should control information on their devices and consent before tracking cookies are stored.

### [Do analytics cookies require consent under Article 5(3)?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md#do-analytics-cookies-require-consent-under-article-53)

*Module: [Do Analytics Cookies Require Consent under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md)*

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.

- Treat analytics consent as required when the tool tracks users across sites, shares identifiers with advertising or attribution systems, uses third-party cookies or common identifiers, combines analytics with customer files, or uses the same tracer for multiple non-exempt purposes.
- Do not rely on legitimate interests as the basis for the placement or reading of consent-required cookies; the EDPB cookie-banner taskforce states that Article 5(3) compliance must come first.
- Where consent is required, set the analytics category off by default, avoid pre-ticked choices, provide a real reject path, and make withdrawal accessible from a visible privacy or cookie-settings control.
- Keep GDPR analysis separate but connected: ePrivacy governs the placement or reading of the cookie or similar technology, while later personal-data processing may also need a GDPR legal basis, transparency, retention, and processor or controller analysis.

Sources for this answer:

- [Directive 2002/58/EC, Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32002L0058&ref=sorena.io) - Primary ePrivacy Directive text for storage or access to terminal-equipment information and the narrow transmission or strictly necessary exceptions.
- [EDPB Guidelines 2/2023 on Article 5(3) technical scope](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports classifying analytics scripts, pixels, URLs, local processing, and identifiers by the actual storage or access operation, not by product label.
- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Explains why first-party analytics cookies are not generally covered by the Article 5(3) strictly necessary or transmission exemptions.

### [When can a limited analytics exemption apply?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md#when-can-a-limited-analytics-exemption-apply)

*Module: [Do Analytics Cookies Require Consent under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md)*

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.

- Require product evidence: the exact analytics property, tag or SDK version, cookie names, storage locations, event schema, identifier behavior, IP handling, retention settings, and whether any advertising, remarketing, attribution, or product-improvement integrations are enabled.
- Require configuration evidence: screenshots or exports showing IP truncation, disabled data sharing, disabled cross-domain tracking where relevant, independent publisher property separation, tracker expiration, and the user opt-out control.
- Require supplier evidence: processor terms or technical documentation showing that the supplier does not reuse the analytics data for its own purposes and keeps one publisher's data and trackers independent from another publisher's data and trackers when the exemption depends on that separation.
- Block exemption claims for broad analytics suites where the grounding cannot support the claim; CNIL notes that most large audience-measurement offerings do not fall within its exemption perimeter regardless of configuration.

Sources for this answer:

- [CNIL Sheet 16: Use analytics on your websites and applications](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications?ref=sorena.io) - National regulator guidance for a limited audience-measurement exemption, including purpose limits, opt-out, IP truncation, tracker lifetime, supplier separation, and national-variation caveats.
- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Provides the Article 5(3) exemption framework and cautions that first-party analytics were not exempt under the two Directive criteria, though low-risk safeguards were discussed.
- [European Commission ePrivacy factsheet](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - Commission material explaining the device-control policy context for cookie consent and the continued relevance of national fragmentation in ePrivacy rules.

### [What evidence should teams keep?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md#what-evidence-should-teams-keep)

*Module: [Do Analytics Cookies Require Consent under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md)*

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.

- Cookie and storage inventory: cookie names, local-storage keys, SDK identifiers, pixel URLs, tracked URL parameters, expiration, domain, party status, and firing condition.
- Tag-control proof: tag manager exports, network traces, automated test reports, and screenshots showing no analytics storage or access before consent when consent is required.
- Consent-log fields: user or pseudonymous consent ID, timestamp, country or locale, banner version, purpose category, accept or reject state, withdrawal state, and downstream tag state.
- Exemption file: national source, product configuration, opt-out mechanism, IP truncation evidence, purpose limitation, retention or tracker lifetime evidence, and supplier separation terms.
- Review triggers: new analytics vendor, new domain or app, cross-domain measurement, advertising linkage, customer-file enrichment, A/B testing change, consent-banner redesign, or Member State guidance change.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports keeping evidence for no pre-consent firing, reject options, classification of essential cookies, withdrawal access, and the split between ePrivacy cookie access and GDPR downstream processing.
- [EDPB Guidelines 05/2020 on consent](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports consent-log evidence because controllers must be able to demonstrate valid, granular, informed consent and provide withdrawal mechanisms.
- [EDPB Guidelines 2/2023 on Article 5(3) technical scope](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports the technical inventory for cookies, JavaScript, tracking pixels, tracked URLs, local processing, IP-related tracking, and unique identifiers.
- [CNIL Sheet 16: Use analytics on your websites and applications](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications?ref=sorena.io) - Supports keeping configuration evidence for any CNIL-style audience-measurement exemption claim.

### [What caveats should be documented?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md#what-caveats-should-be-documented)

*Module: [Do Analytics Cookies Require Consent under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/analytics-cookies.md)*

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.

- State whether the decision is EU-level Article 5(3) scope, CNIL-specific exemption guidance, or a local-law conclusion for a named Member State.
- State whether the analytics tool is consent-based, exemption-based, or blocked pending evidence from the vendor or local guidance.
- State which facts would reverse the decision, especially advertising reuse, cross-site identifiers, data sharing, customer-file matching, longer tracker lifetime, missing opt-out, or pre-consent firing.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Grounds the national-law caveat and the need to assess cookie placement or reading under national ePrivacy transposition rules.
- [CNIL Sheet 16: Use analytics on your websites and applications](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications?ref=sorena.io) - Grounds the caveat that analytics guidance may be subject to national variation and should be checked against the local data protection authority position.
- [European Commission ePrivacy factsheet](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - Provides Commission context for ePrivacy device-control policy and the relationship between ePrivacy confidentiality and GDPR personal-data rules.

### [When does the ePrivacy soft opt-in apply?](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md#when-does-the-eprivacy-soft-opt-in-apply)

*Module: [EU ePrivacy soft opt-in FAQ for email marketing](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md)*

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.

- Confirm the contact is an existing customer from a sale, not a bought-in lead, scraped address, event badge scan, newsletter-only signup, trial list, or abandoned form.
- Confirm the sending entity is the same legal or natural person that collected the electronic mail details.
- Map the promoted offer to the product or service originally sold and explain why it is similar.
- Show the opt-out text or control used at collection and the unsubscribe or objection route in each message.
- Block the send where the customer has objected, unsubscribed, or appears on a suppression list.

Sources for this answer:

- [Directive 2002/58/EC, Article 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32002L0058&ref=sorena.io) - Article 13(2) supplies the EU-level soft opt-in conditions for customer electronic mail direct marketing.
- [Directive 2009/136/EC amendments to Directive 2002/58/EC](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02009L0136-20201221&ref=sorena.io) - The 2009 amendment source is the grounded consolidated amendment material for the current ePrivacy Article 13 framework.

### [What campaign evidence should teams keep?](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md#what-campaign-evidence-should-teams-keep)

*Module: [EU ePrivacy soft opt-in FAQ for email marketing](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md)*

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.

- Customer-source evidence: order, subscription, or service record showing the email address was obtained in the context of a sale.
- Sender evidence: legal-entity name, brand presentation, reply domain, and sender authentication that match the entity relying on Article 13(2).
- Similarity evidence: short mapping from the purchased product or service to the promoted offer.
- Collection opt-out evidence: checkout, account, or order-flow copy showing the clear and distinct objection opportunity.
- Each-message opt-out evidence: final email template with unsubscribe link, preference-center path, or valid reply address.
- Suppression evidence: timestamped objection records and pre-send exclusion checks across CRM, ESP, CDP, and regional campaign tools.

Sources for this answer:

- [Directive 2002/58/EC, Article 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32002L0058&ref=sorena.io) - Article 13(2) and 13(4) support the evidence checklist for opt-out timing, sender identity, and a valid stop route.
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - The consent guidance supports fallback analysis where a campaign does not fit the Article 13(2) soft opt-in route and needs valid opt-in consent.

### [When should teams escalate instead of sending?](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md#when-should-teams-escalate-instead-of-sending)

*Module: [EU ePrivacy soft opt-in FAQ for email marketing](/artifacts/eu/eprivacy-directive/faq/soft-opt-in.md)*

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.

- Use consent review for prospects, purchased lists, partner lists, affiliate sends, group-company sends, or unrelated offers.
- Escalate where the message disguises or conceals the sender identity, uses a misleading sender name, or lacks a valid address or route for stopping further messages.
- Check local implementation before relying on soft opt-in for B2B recipients, legal-person subscribers, mixed channels, SMS, automated calls, or voice calls.
- Recheck the GDPR layer for any personal-data processing that sits outside the ePrivacy special rule, such as profiling, segmentation, analytics, or enrichment.

Sources for this answer:

- [Directive 2002/58/EC, Article 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32002L0058&ref=sorena.io) - Article 13(3), 13(4), and 13(5) ground the escalation points for national-law choices, sender identity, valid stop addresses, and legal-person protections.
- [Commission factsheet on stronger privacy rules for electronic communications](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - The Commission material explains the policy reason for replacing national ePrivacy Directive implementations with a directly applicable Regulation.

### [Is a reject-all button required?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md#is-a-reject-all-button-required)

*Module: [Is a reject-all button required for EU ePrivacy cookie consent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md)*

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.

- Treat "reject all", "refuse", and "continue without accepting" as acceptable only when the action is clear and actually blocks consent-based storage or access.
- Do not set consent-required cookies or similar technologies by default; consent must be expressed through a positive user action.
- Do not rely on legitimate interest for the placement or reading of cookies where Article 5(3) requires consent.
- Keep strictly necessary storage separate from analytics, advertising, social-media, personalisation, and measurement purposes.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports the majority authority position on missing reject/refuse options, the minority caveat, deceptive design concerns, and national-law implementation caveats.
- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports the scope test for storage of, or access to, information on terminal equipment and confirms Article 5(3) is not limited to cookies.
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports the need for freely given, specific, informed, unambiguous consent and controller evidence of consent.

### [What makes the refusal option equivalent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md#what-makes-the-refusal-option-equivalent)

*Module: [Is a reject-all button required for EU ePrivacy cookie consent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md)*

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.

- Place accept and reject/refuse controls in the same decision layer for consent-based purposes.
- Use plain labels that identify the action, such as "Reject all" or "Continue without accepting".
- Avoid paragraph-embedded refusal links, misleading colour hierarchy, unreadable contrast, and wording that implies consent is required for ordinary site access.
- Test desktop and mobile banners because mobile-first rendering, overlays, and small screens can hide or demote refusal controls.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports the warnings on deceptive link design, misleading colours or contrast, and banners that clearly push users to consent.
- [European Commission ePrivacy factsheet](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - Supports the policy context that users should control information on their devices and be asked for consent before tracking cookies are stored.

### [What evidence should teams keep?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md#what-evidence-should-teams-keep)

*Module: [Is a reject-all button required for EU ePrivacy cookie consent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md)*

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.

- Cookie, SDK, pixel, local-storage, and fingerprinting inventory mapped to purposes and whether each item is strictly necessary or consent-based.
- CMP configuration exports showing accept, reject, granular settings, default states, and country or language variants.
- Network and browser-storage test logs proving consent-required technologies do not fire before consent or after rejection.
- Evidence of the exact banner text, visual state, consent information, session event, and version shown when consent was requested.
- Withdrawal testing showing users can reopen settings and withdraw consent as easily as they gave it.

Sources for this answer:

- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports retaining consent workflow records, session information, user-facing information, and withdrawal mechanisms without collecting excessive evidence.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports maintaining cookie lists, documenting essentiality, and providing accessible withdrawal solutions.

### [What are the main caveats?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md#what-are-the-main-caveats)

*Module: [Is a reject-all button required for EU ePrivacy cookie consent?](/artifacts/eu/eprivacy-directive/faq/reject-all-button.md)*

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.

- Check Member State law and regulator guidance before treating a single banner pattern as valid across all EEA markets.
- Separate the Article 5(3) storage/access question from later GDPR processing purposes and lawful bases.
- Do not classify analytics or advertising as strictly necessary merely because the business needs measurement or revenue.
- Do not silently switch from withdrawn consent to another lawful basis for the same personal-data processing without the required transparency analysis.

Sources for this answer:

- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports the broad technical scope of Article 5(3), including information beyond personal data and similar technologies beyond cookies.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports the caveat that cookie placement and reading are assessed under national ePrivacy-transposition laws and local regulator guidance.
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports the rule that withdrawal must be as easy as giving consent and that consent-based processing must stop after withdrawal unless another lawful basis applies.

### [When can a cookie be treated as strictly necessary?](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md#when-can-a-cookie-be-treated-as-strictly-necessary)

*Module: [Strictly Necessary Cookies under the EU ePrivacy Directive](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md)*

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.

- Transmission exemption: routing, ordered data exchange, or error/loss detection needed to carry the communication over the network.
- Service-request exemption: a cookie needed to deliver a specific feature the user requested, such as a multi-page form, shopping basket, authenticated session, or user-centric login security.
- Purpose separation: if the same cookie supports both essential and non-essential purposes, the exemption applies only if every distinct purpose independently qualifies.
- Technical scope: Article 5(3) is not limited to classic cookies; storage or access through local storage, pixels, client-side code, identifiers, or other terminal-equipment techniques can also fall in scope.

Sources for this answer:

- [Directive 2009/136/EC amendment to ePrivacy Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02009L0136-20201221&ref=sorena.io) - Provides the Article 5(3) consent rule and the two exemptions for transmission and strictly necessary user-requested services.
- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Explains the high threshold for the transmission and user-requested service exemptions, including the user-perspective test.
- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Shows that Article 5(3) covers storage or access to terminal-equipment information beyond classic cookies.

### [Which examples are grounded as usually essential?](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md#which-examples-are-grounded-as-usually-essential)

*Module: [Strictly Necessary Cookies under the EU ePrivacy Directive](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md)*

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.

- Shopping basket or multi-page form cookies: keep only the input or basket state needed for the user-requested transaction.
- Session authentication cookies: use them for the authenticated service, not for advertising, profiling, or behavioral monitoring.
- User-centric security cookies: limit them to protecting the requested login or account service from abuse.
- Persistent login or remember-me cookies: do not assume exemption; WP29 distinguishes them from ordinary session authentication and points to consent for persistence.

Sources for this answer:

- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Grounds the shopping basket, user-input session, authentication, persistent login, and user-centric security examples.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Warns against classifying cookies as essential when their purposes are not strictly necessary and highlights the need to demonstrate essentiality.

### [How should analytics and evidence records be handled?](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md#how-should-analytics-and-evidence-records-be-handled)

*Module: [Strictly Necessary Cookies under the EU ePrivacy Directive](/artifacts/eu/eprivacy-directive/faq/strictly-necessary-cookies.md)*

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.

- Keep a cookie inventory with name, provider, domain, first-party or third-party status, purpose, duration, storage/access method, and data sent from the terminal equipment.
- For each claimed exemption, record the requested user action, the exact service feature, why the feature fails without the cookie, and why the duration is no longer than needed.
- Separate essential purposes from analytics, ads, social plug-ins, A/B testing, personalization, attribution, fraud measurement for advertising, and product-improvement purposes.
- Keep evidence of banner behavior for non-essential cookies: no consent-required cookies before consent, no pre-ticked boxes, a real reject path, and consent withdrawal that is as easy as giving consent.
- Refresh the assessment when cookie features, vendors, retention periods, domains, user journeys, Member State coverage, or terminal-equipment access techniques change.

Sources for this answer:

- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Supports the analytics caveat and the principle that doubts should be resolved by seeking consent rather than stretching an exemption.
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Grounds the quality standard for consent where a cookie does not fit an Article 5(3) exemption.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Grounds evidence expectations for essentiality, banner behavior, reject options, legitimate-interest confusion, withdrawal, and national-law caveats.
- [European Commission ePrivacy overview](https://digital-strategy.ec.europa.eu/en/library/eprivacyeu-towards-future-proof-legal-framework-online-privacy?ref=sorena.io) - Commission context for the ePrivacy framework and protection of privacy in electronic communications.

### [What should CMP consent logs retain?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md#what-should-cmp-consent-logs-retain)

*Module: [What should CMP consent logs retain under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md)*

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.

- Keep affirmative consent, refusal, no-choice/default state, later preference changes, and withdrawal as separate events.
- Store the banner and preference-centre version that presented the choice, including the accept, reject, settings, and withdrawal routes available at that time.
- Link each consent purpose to the live vendor, cookie, pixel, SDK, local-storage, or identifier inventory used by the site or app.
- Record whether strictly necessary items were separated from analytics, advertising, personalisation, and other optional purposes.
- Retain only the proof needed to demonstrate the consent workflow; avoid expanding the consent log into a separate behavioural tracking dataset.

Sources for this answer:

- [Directive 2002/58/EC, Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32002L0058&ref=sorena.io) - Grounds the need to connect CMP records to storage of, or access to, information in user terminal equipment.
- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports including non-cookie technologies such as pixels, local storage, identifiers, and similar terminal-equipment access in the consent-log scope.
- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Supports keeping enough records to demonstrate valid consent without excessive additional data collection.

### [Which validity signals should the log preserve?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md#which-validity-signals-should-the-log-preserve)

*Module: [What should CMP consent logs retain under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md)*

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.

- Consent was recorded by a clear affirmative action for named purposes rather than by inactivity or a preselected default.
- Purpose-level and vendor-level choices match the CMP configuration and the cookie or tracker inventory active at the timestamp.
- Reject, continue-without-consenting, or equivalent refusal handling was available where the banner requested consent.
- Withdrawal was available through a visible, accessible route and was not materially harder than the original consent action.
- The CMP blocked or suppressed optional tags, pixels, SDK calls, and storage until the relevant consent state allowed them.

Sources for this answer:

- [EDPB Guidelines 05/2020 on consent](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Grounds the validity checks for freely given, specific, informed, unambiguous consent and easy withdrawal.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports checking reject options, pre-ticked boxes, misleading banner design, essential-cookie classification, and withdrawal routes.
- [CJEU Planet49 judgment](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62017CJ0673&ref=sorena.io) - Supports treating pre-ticked cookie consent as insufficient and preserving the information provided to users for cookie consent.

### [How should consent logs connect to vendor and cookie inventories?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md#how-should-consent-logs-connect-to-vendor-and-cookie-inventories)

*Module: [What should CMP consent logs retain under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md)*

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.

- Keep inventory version, CMP configuration version, tag-manager container version, and banner text version in the same evidence trail.
- Map each optional vendor or tracker to purpose, category, storage/access type, data recipient, and consent dependency.
- Document why each strictly necessary item fits the narrow exemption instead of placing it in the consented-purpose bucket.
- Run periodic scans or deployment checks, but require owner documentation for purposes because scanner output alone cannot prove essentiality.
- Trigger review when a vendor, purpose, country rollout, cookie lifetime, SDK behaviour, or withdrawal flow changes.

Sources for this answer:

- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports maintaining cookie lists and documenting purpose and essentiality rather than relying only on scanning tools.
- [WP29 Opinion 04/2012 on Cookie Consent Exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Supports separating strictly necessary cookies from cookies that need consent under Article 5(3).
- [EDPB Guidelines 2/2023 on Article 5(3) ePrivacy Directive](https://www.edpb.europa.eu/system/files/2023-11/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_en.pdf?ref=sorena.io) - Supports covering tracking pixels, tracked URLs, unique identifiers, local processing, and IP-based tracking scenarios where Article 5(3) can apply.

### [What are the limits of CMP consent-log proof?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md#what-are-the-limits-of-cmp-consent-log-proof)

*Module: [What should CMP consent logs retain under the EU ePrivacy Directive?](/artifacts/eu/eprivacy-directive/faq/cmp-consent-logs.md)*

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.

- Do not treat a consent string as proof that the banner was clear, balanced, or granular.
- Do not use consent logs to justify setting optional cookies before the user chooses.
- Do not infer country-specific penalties or regulator positions from the EU-level sources alone.
- Escalate for national-law review when deploying in a new Member State, changing refusal or withdrawal design, or relying on an exemption.
- Delete or aggregate proof when it is no longer needed for accountability, dispute handling, audit, or legal limitation purposes.

Sources for this answer:

- [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://www.edpb.europa.eu/sites/default/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Supports the distinction between national ePrivacy rules for terminal-equipment access and GDPR assessment of later personal-data processing.
- [EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Supports the caveat that taskforce positions are a minimum threshold and do not replace case-by-case authority analysis or national requirements.
- [European Commission factsheet, Stronger privacy rules for electronic communications](https://ec.europa.eu/digital-single-market/en/news/eurobarometer-eprivacy?ref=sorena.io) - Provides Commission context that device information and electronic-communications privacy are complementary to GDPR personal-data protection.

*Recommended next step*

*Placement: before sources*

## Convert ePrivacy answers into product, marketing, and consent controls

Sorena can help map cookies, SDKs, pixels, marketing sends, consent flows, national-law caveats, and evidence records against the cited ePrivacy sources.

- [Open Research Copilot for EU ePrivacy Directive](/solutions/research-copilot.md): Ask source-linked questions about Article 5(3), consent banners, exemptions, direct marketing, and GDPR interplay using the cited sources on this page.
- [Talk through EU ePrivacy implementation](/contact.md): Review your cookie inventory, consent evidence, direct-marketing controls, and country-law validation queue with Sorena.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/faq/items