GDPR Article 13 and ePrivacy Article 5(3): The Two Laws Behind Every Cookie Banner

Every cookie banner in Europe sits on top of two different laws that are routinely confused with each other — including by vendors selling compliance software. The ePrivacy Directive's Article 5(3) governs the *act of storing or reading anything on a visitor's device*. The GDPR's Article 13 governs *what you must tell people when you collect their personal data*. They overlap on a cookie banner, but they are not the same rule, they are not triggered by the same things, and you can comply with one while violating the other. This guide takes each in turn, shows how they combine on a real banner, and ends with what the EU's Digital Omnibus proposal may change.

The division of labour

Think of it as two gates a tracking cookie has to pass: Gate 1 — ePrivacy Art. 5(3): may you store this cookie (or read this value) on the device at all? This gate exists *regardless of whether personal data is involved*. A randomly-generated A/B-test bucket ID with no personal data in it still needs to pass Gate 1. Gate 2 — GDPR: once data flows, is the *processing* lawful, transparent, and limited? This is where Article 13's disclosure duties, Article 6's lawful bases, and Article 7's consent conditions live. The practical consequence: "we don't process personal data" is not an exemption from the cookie consent requirement, and "we have consent for the cookie" is not an exemption from the privacy-policy disclosure duties.

ePrivacy Article 5(3), properly read

The text is one sentence with three load-bearing phrases: storing information, or gaining access to information already stored, in the terminal equipment of a user, is only allowed with consent, having been provided with clear and comprehensive information, unless the storage or access is strictly necessary for a service explicitly requested by the user. What falls inside the scope is broader than the word "cookie" suggests. The EDPB's Guidelines 2/2023 on the technical scope of Art. 5(3) confirmed it covers localStorage and sessionStorage, IndexedDB, identifiers derived from device APIs, pixel-based tracking, and — in many configurations — fingerprinting techniques that read information from the device. If your consent tool blocks cookies but lets a vendor stash the same identifier in localStorage, you have not complied; you have relocated the violation.

The "strictly necessary" exemption is narrower than most sites assume. It reliably covers: session cookies for a logged-in area, a shopping cart, load balancing, security/fraud-prevention tokens, language choice the user just made, and — helpfully — the cookie that records the consent decision itself. It does not cover analytics (with narrow national nuances, e.g. CNIL's exemption conditions for strictly-audience-measurement setups), A/B testing, marketing pixels, session replay, or "we consider personalization essential to our business model." Necessity is judged from the *user's* perspective — the service they explicitly requested — not from yours.

"Prior" means prior. The consent must exist before the cookie is written or read. A banner that renders while GA4 is already firing in the background fails Art. 5(3) no matter how beautiful the banner is. This is the single most common failure we see in scans: published compliance sweeps of EU e-commerce have repeatedly found that roughly four in ten stores set non-essential cookies before any consent is given.

What "consent" means here is imported from the GDPR: freely given, specific, informed, unambiguous, by statement or clear affirmative action (Art. 4(11)), withdrawable as easily as it was given (Art. 7(3)). The CJEU's *Planet49* judgment killed pre-ticked boxes; CNIL's enforcement against Google and Facebook (combined fines of EUR 210M in 2022) established that rejecting must be as easy as accepting — the "reject parity" rule. Scrolling, continued browsing, and banner dismissal are not consent.

GDPR Article 13, item by item

• Identity and contact details of the controller — your legal entity, not just a brand name, plus a reachable contact. If you have an EU representative or DPO, them too.
• Purposes and lawful basis for each purpose — "analytics (consent)", "order fulfilment (contract)", "fraud prevention (legitimate interest)". One blended paragraph covering everything is the classic failure.
• Legitimate interests pursued, where that is the basis — named, not implied.
• Recipients or categories of recipients — this is where your tag stack lives. If Google Analytics, Meta Pixel, or Hotjar receive data from your pages, they are recipients. A privacy policy that never mentions Google while GA4 runs on every page is an Article 13 failure you can detect from the outside — which is exactly what automated sweeps (including ours) do.
• Third-country transfers and the safeguard relied on (adequacy, SCCs).
• Retention period or the criteria for determining it — "as long as necessary" alone is the phrase regulators love to quote back.
• Data-subject rights — access, rectification, erasure, restriction, portability, objection.
• The right to withdraw consent — and withdrawal must actually be reachable: a persistent cookie-settings link, not an email address.
• The right to lodge a complaint with a supervisory authority.
• Automated decision-making/profiling where it exists, with meaningful information about the logic.

The timing matters as much as the content: Article 13 applies when the data is obtained. That is why the banner's first layer must carry the essentials (who, what purposes, consent granularity, link to the full policy) rather than deferring everything to a document nobody opens until after the pixels fired.

How the two laws combine on a real banner

A compliant setup, layer by layer: 1. First layer (the banner): controller identity, plain-language purposes by category, equal-prominence Accept / Reject, a way into granular choices, links to the cookie and privacy policies. Nothing non-essential fires yet (Gate 1 closed). 2. Second layer (preferences): per-category toggles with honest descriptions, vendor-level detail where meaningful, all defaulting to off. 3. The cookie policy: the complete inventory — name, provider, purpose, duration — which must match what actually runs. The gap between declaration and reality is "cookie policy drift", and it accumulates every time marketing adds a tag. 4. The privacy policy: the full Article 13 disclosure set, naming the recipients your tags imply. 5. The consent record: Article 7(1) makes you able to *demonstrate* consent — store what was shown, what was chosen, when, and under which policy version. 6. Withdrawal: the persistent settings link, honoring the change immediately (and deleting what the withdrawn categories wrote).

Where enforcement actually bites

Patterns from CNIL, the Garante, AEPD, and the Irish DPC over the last few years are consistent: pre-consent firing, missing or buried reject options, consent walls without alternatives, dark patterns in the second layer (color-weighted buttons, exhausting toggles), analytics mislabeled as "necessary", and policies that do not match the observed tag behaviour. The through-line: regulators scan sites the way our tooling does — from outside, comparing what fires against what was consented and declared. If an automated scan can catch the gap, so can a regulator's.

What the Digital Omnibus may change

In November 2025 the European Commission published the Digital Omnibus package, which — among many other things — proposes moving the device-access rules out of the ePrivacy Directive and into the GDPR as a new Article 88a, with a companion Article 88b on how consent and refusal can be expressed through automated, machine-readable signals (think: a browser-level or agent-level signal your site must honor, in the spirit of Global Privacy Control). The proposal keeps consent as the default for device access but writes the exemption list into the law itself, including certain low-risk first-party analytics — which, if it survives negotiation, would be the biggest practical change to cookie banners since 2018. Two cautions. First, as of this writing the Omnibus is still in the legislative process; final text is expected around late 2026 or 2027, and the current rules remain fully in force until then — nothing in this guide is relaxed yet. Second, proposals change in trilogue; building your compliance posture on a draft is how sites end up non-compliant twice. The sensible preparation is architectural: make sure your consent infrastructure can honor machine-readable signals (if you already handle GPC properly, you are most of the way there) and keep your cookie inventory accurate so that any future exemption list is easy to apply. Track the milestones on our compliance calendar.

The checklist

1. Nothing non-essential fires before consent — verify in an incognito window with the network tab, not by reading your CMP's dashboard. 2. Reject is as prominent as Accept, on the first layer. 3. Every vendor your tags send data to appears in the privacy policy's recipients and the cookie policy's inventory. 4. Each purpose has a named lawful basis; consent purposes are granular. 5. Retention periods are concrete. 6. Withdrawal is one click from every page and takes effect immediately. 7. Consent records exist and can be produced. 8. Re-scan monthly — drift is not an event, it is a rate. ShieldPage automates the detectable parts: the monthly compliance sweep runs a real-browser cookie scan against every site, cross-references observed trackers against your published privacy policy, cookie policy, and subprocessor list, and flags undisclosed vendors with the specific article each gap touches. The parts no tool can do — deciding your purposes and lawful bases honestly — remain yours.