Cookie Consent: 6 Proven Rules Article 5(3) Sets

Cookie consent is governed by a single sentence of European law that never uses the word “cookie”, never mentions personal data, and sets a test most banners fail before anyone clicks anything.

Reading the cookie consent rule properly changes what you are arguing about — because the argument is almost never really about cookies.

What the cookie consent law actually says

Article 5(3) of the ePrivacy Directive, as amended in 2009, requires Member States to ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information about the purposes of the processing.

Two omissions carry the whole point.

It does not say cookies. The trigger is storing or accessing information on a device. Local storage, session storage, tracking pixels, SDKs in a mobile app, device fingerprinting scripts and anything that reads what is already on the device are all caught by the same words. A cookie consent programme scoped to cookies is scoped to a fraction of its subject.

It does not say personal data. Article 5(3) applies whether or not the information is personal. That is why “we only store an anonymous identifier” is not an answer to it — the GDPR question sits alongside, not instead.

The two cookie consent exemptions, read literally

The Article exempts technical storage or access:

• for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
• as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

The second is the one everyone reaches for and few read to the end. It is not “necessary for our business”, not “necessary for our commercial model”, and not “necessary to understand our users”. It is strictly necessary to deliver the thing this user just asked for.

A shopping basket passes. A login session passes. A security token that prevents request forgery passes. Analytics does not, because the user did not request measurement — however much you need it, and however first-party it is. That is an uncomfortable conclusion, and it is what the sentence says.

Note also “sole purpose” in the first exemption. A cookie that does something necessary and something else is not exempt.

Where the cookie consent standard comes from

The ePrivacy Directive requires consent but takes its meaning from data protection law. Under GDPR Article 4(11), consent is any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement.

Each adjective removes a common banner pattern. Freely given rules out consent extracted as the price of access where the processing is not necessary. Specific rules out one switch covering analytics, advertising and personalisation together. Informed requires the purposes before the click. Unambiguous, with a clear affirmative action, rules out pre-ticked boxes, scroll-as-consent and continued browsing.

The provision that decides most cookie consent banners

GDPR Article 7(3): the data subject may withdraw consent at any time, they must be informed of that before giving it, and it shall be as easy to withdraw as to give consent.

Apply that to your own cookie consent banner. If accepting is one click on the banner, and withdrawing means finding a link in the footer, opening a preference centre and toggling five categories, the two are not equally easy. That asymmetry is visible from outside without any investigation, which is precisely why it is the thing regulators and complainants look at first.

Article 7(4) adds that when assessing whether consent is freely given, utmost account is taken of whether performance of a contract is made conditional on consent to processing that is not necessary for that contract.

What this means in practice

Three consequences fall out of the text, and they are the ones worth taking to whoever owns the site:

• Base cookie consent on storage, not on cookies. Your record needs every mechanism that writes to or reads from a device, including the ones your tag manager loads and the ones inside third-party SDKs.
• Justify each exemption individually, against the service the user explicitly requested — and write the justification down, because you are asserting it.
• Make refusal and withdrawal as cheap as acceptance. If that costs you consent rates, the rates you had were not consent.

National implementations differ, because ePrivacy is a directive. Some supervisory authorities have published detailed expectations on banner design, and those are the operative rules in their territory. The Article 5(3) test above is the floor everywhere in the Union, not the whole of the law anywhere.

How cookie consent connects

Where to start

1. Scan for storage and access, not for cookies, including inside third-party tags and app SDKs.
2. Write a purpose for each one, in the words you would use to a user.
3. Test each exemption claim against “strictly necessary for the service explicitly requested”.
4. Separate the categories, because specific consent cannot be bundled.
5. Match reject to accept, and withdrawal to giving, in the same number of clicks.
6. Check your national regulator’s guidance, since ePrivacy is transposed and banner expectations vary.

This guide reflects Directive 2002/58/EC as amended by Directive 2009/136/EC, and Regulation (EU) 2016/679, as published on EUR-Lex, read at 16 August 2026. ePrivacy is transposed nationally — your operative rules are your Member State’s.

The GDPR Toolkit provides 100+ editable templates covering the records of processing, the consent records, the privacy notices and the transparency documentation a cookie consent mechanism has to be built on.