Cookies

GDPR vs ePrivacy: which one actually governs cookies?

GDPR did not invent the cookie banner. ePrivacy did, fifteen years earlier. Understanding which framework requires what is the difference between a defensible CMP setup and a banner that fails on first inspection.

By Veracly Compliance Team6 min read

A reader of European compliance content could be forgiven for thinking GDPR invented the cookie banner. It did not. The cookie banner predates GDPR by a decade, was created by a different framework, and survives if GDPR is ever repealed. Understanding which regulation does what is the foundation of a defensible cookie setup.

The two frameworks

ePrivacy Directive 2002/58/EC, amended in 2009 (Directive 2009/136/EC). Article 5(3) — the so-called “cookie law” — requires informed consent before any storage of information on, or access to information already stored on, a user’s terminal equipment. The exception is storage “strictly necessary” for a service the user has requested.

GDPR (Regulation (EU) 2016/679), in force since May 2018. Article 4(11) defines consent stringently. Article 6 lists the six lawful bases for processing personal data. Article 7 sets the conditions for consent. The data subject rights (Articles 15–22) apply to any personal data, including cookie-derived.

The two work in series, not in parallel. ePrivacy 5(3) governs the moment data enters the user’s device or is accessed from it. GDPR governs what happens to the data after collection. A site needs both lawful: a valid ePrivacy 5(3) consent for the storage event, and a valid GDPR Article 6 basis for the processing.

The 5(3) trigger

Article 5(3) fires on any “storing of information” or “gaining of access to information already stored” on terminal equipment. This is broader than cookies:

  • HTTP cookies (first-party and third-party)
  • localStorage and sessionStorage
  • IndexedDB
  • Service Worker caches
  • Pixel and beacon requests that write client identifiers
  • Browser fingerprinting techniques that read device characteristics

The German DSK guidance (December 2021) and the EDPB Guidelines 2/2023 on the scope of Article 5(3) make this explicit. A site that swaps cookies for localStorage does not escape consent; the storage rule is technology-neutral.

The “strictly necessary” exception

ePrivacy 5(3) allows storage without consent when it is “strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.” The exception is narrower than most CMPs label it:

  • Yes: session cookies that track a logged-in user’s authenticated state. CSRF tokens. Load balancer session affinity. Shopping cart state during a checkout.
  • Yes (qualified): security cookies for fraud prevention on a payment flow — EDPB has accepted these as strictly necessary in narrow contexts.
  • No: any analytics, anywhere on the spectrum from “privacy-friendly” to invasive. The EDPB has been consistent: analytics is helpful to the service operator, not strictly necessary for the service.
  • No: “user preferences” cookies that persist beyond the session. Language preference, theme — these enhance the service, they are not strictly necessary.
  • No: any third-party advertising, retargeting, social, or fingerprinting cookie.

Where the conflation goes wrong

Two common failure modes in cookie-consent writing:

  1. “GDPR requires a cookie banner.” No, ePrivacy 5(3) does. GDPR tightens the definition of consent the banner relies on.
  2. “If we have legitimate interest, we do not need consent.”GDPR Article 6(1)(f) (legitimate interest) is a lawful basis for processing personal data. It does not override ePrivacy 5(3) consent for the storage event. The EDPB has explicitly rejected the “legitimate interest for cookie storage” argument multiple times.

A third, more subtle one: the assumption that the EU-US Data Privacy Framework (DPF, adequacy decision 10 July 2023) fixed cookie compliance. It did not. The DPF addresses GDPR Chapter V (international transfers). ePrivacy 5(3) consent is unaffected. A site that consent-gates GA4 properly is fine under both frameworks; a site that fires GA4 pre-consent is in breach of ePrivacy regardless of whether the resulting data ends up in a DPF-certified Google data center.

The ePrivacy Regulation that has not arrived

The European Commission proposed a new ePrivacy Regulation in 2017, intended to replace the 2002 Directive and harmonize cookie rules across member states. As of 2026 it remains in trilogue. Until it passes, the existing ePrivacy Directive applies — which means member-state implementations diverge in detail (France has very specific banner-design rules; Germany has stricter analytics positions; Italy has its own enforcement focus). A multi-country deployment must check each jurisdiction’s national transposition.

How Veracly applies the two frameworks

Veracly’s rules engine evaluates both. The cookie-audit module checks for ePrivacy 5(3) violations (pre-consent firing, missing banner, banner without a reject path). The privacy-policy module checks for GDPR Article 13/14 disclosure completeness. Reports flag each finding under the framework it actually breaches — so a regulator follow-up gets the right legal citation, not a generic “cookie issue.”

See also: Cookies, localStorage, IndexedDB: which require consent? · Do I need a banner if I only use essential cookies?

Common questions

Which law actually requires the cookie banner?+

ePrivacy Article 5(3), originally from the 2002 ePrivacy Directive and amended in 2009. It requires consent for any non-essential storage on a user device — including cookies, localStorage, and IndexedDB. GDPR does not require a cookie banner; it tightens the definition of consent that ePrivacy already required.

What does GDPR add for cookies?+

Three things. First, a stricter consent standard — Article 4(11) defines consent as freely given, specific, informed, and unambiguous. Second, the data subject rights (access, erasure, portability) that apply to data collected via cookies. Third, the lawful-basis framework in Article 6 that governs the processing once data is collected.

Why does the distinction matter in practice?+

Because the GDPR adequacy regime (DPF, SCCs, Schrems II) addresses Chapter V transfers — it does not displace ePrivacy 5(3). A site that has the perfect GDPR posture but fires a tracking pixel pre-consent has not complied with ePrivacy. The fines are separate.

See where your site stands.

Run a free Veracly scan and get a multi-jurisdiction report — EAA, GDPR, ADA, UK Equality Act, AODA — with copy-paste developer fixes.

Run a free scan

Keep reading

Cookies on veracly.app

We set strictly-necessary cookies to keep the site running. Analytics cookies help us understand which pages convert — only with your permission. Read our cookie policy