GDPR vs ePrivacy: which one actually governs cookies?

A reader of European compliance content could be forgiven for thinking GDPR invented the cookie banner. It did not. The consent requirement arrived with the 2009 amendment to the ePrivacy Directive, nine years before the GDPR became applicable in May 2018. It came from a different framework, and it survives if the 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. There are twoexemptions, not one: storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, and storage strictly necessary for a service the user has explicitly requested. The transmission limb is the one almost every article forgets; it is also the narrower of the two in practice.

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 to 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 02/2023 on the technical scope of Article 5(3) both confirm the rule is technology-neutral. One caveat worth having, because plenty of articles get it wrong: the Guidelines do not contain a list of APIs. The words “IndexedDB”, “sessionStorage”, “Service Worker” and “Cache API” appear nowhere in the adopted text. What the Guidelines supply is the test — built on the statutory terms information, terminal equipment, and gaining access — and that test is what catches all of them. A site that swaps cookies for localStorage does not escape consent.

The “strictly necessary” exception

The second of the two exemptions is the one CMPs actually invoke: 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.” It 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.
• Usually no, with one real exception: analytics. The default position is the right one to plan around — analytics serves the site operator, not the user who asked for the page, so it needs consent. But “any analytics, anywhere” overstates the law, and the overstatement is not the EDPB’s. WP29 Opinion 04/2012 (WP194) recommended a first-party analytics exemption, and the CNIL actually operates one: audience measurement strictly limited to producing anonymous statistics for the site itself, first-party, no cross-site tracking, no data sharing and no other use of the data, is exempt from consent in France, and the CNIL publishes configuration guides naming specific tools including Matomo. Two things to hold onto: this is a national position, not an EU-wide one, and the configuration conditions are strict enough that most default installs fail them. Check your own jurisdiction before relying on it.
• 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 never arrived, and now never will

The European Commission proposed a new ePrivacy Regulation in January 2017, intended to replace the 2002 Directive and harmonise cookie rules across member states. It never cleared the Council. The Commission announced its intention to withdraw the proposal on 11 February 2025, formally adopted the withdrawal on 16 July 2025, and the withdrawal was published in the Official Journal on 6 October 2025. No successor proposal exists.

That settles a question a lot of compliance planning had been leaving open. The 2002 Directive as amended in 2009 is the law, indefinitely, and it is a Directive — so Article 5(3) reaches you through a national statute, not a single EU text: §25 TDDDG in Germany, art. 82 of the Loi Informatique et Libertés in France, art. 122 Codice Privacy in Italy, art. 11.7a Telecommunicatiewet in the Netherlands, art. 397 PKE in Poland. The detail-level divergence between them is permanent rather than transitional. A multi-country deployment has to check each transposition, and anyone deferring a decision until “ePrivacy lands” is waiting for a train that was cancelled.

How Veracly applies the two frameworks

The cookie-audit module lives on the ePrivacy 5(3) side, and that is where it is strongest. It records the cookies, Web Storage and IndexedDB entries written before any banner interaction, the third-party requests that fire pre-consent, whether a banner exists at all, and whether a reject control is present alongside accept. Every such finding ships with a DevTools recipe so you can reproduce it yourself rather than take our word for it.

The GDPR side is much thinner than the marketing for this class of tool usually admits. Veracly does not check Article 13/14 disclosure completeness. It checks whether a privacy policy is reachable; it does not read it. No content analysis exists anywhere in the product — nothing verifies that a controller, a legal basis, a retention period, a DSAR contact, a DPO or a transfer mechanism is disclosed. Acceptance is a keyword test against a 2xx page on your own host, which also means a policy hosted on your CMP vendor’s domain is not seen at all. Article 13/14 completeness is a document review and it needs a person.

What the reports do get right is the citation: each finding is flagged under the framework it actually engages, so a regulator follow-up gets the correct legal reference rather than a generic “cookie issue.”

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