Cookie Consent Under GDPR and the ePrivacy Directive

Cookie consent sits on two laws at once: the ePrivacy Directive requires consent before non-essential cookies are set, and the GDPR defines what valid consent must look like. Here is how the two fit together and what a compliant banner actually has to do.

Two laws, one banner: where the cookie rules actually come from

Most people call them "the GDPR cookie rules," but the requirement to ask before you drop a cookie does not originate in the GDPR at all. It comes from the ePrivacy Directive (Directive 2002/58/EC, as amended), and specifically Article 5(3). That provision says that storing information, or gaining access to information already stored, on a user's device is only allowed if the user has given consent — having been provided with clear and comprehensive information about why. Cookies are the obvious case, but the rule is technology-neutral: it also reaches local storage, pixels, SDKs, fingerprinting, and similar techniques that read from or write to the device.

The GDPR's job in this picture is different. It does not create the consent requirement for cookies; it defines what "consent" has to mean. The ePrivacy Directive borrows the GDPR's definition of consent, so when Article 5(3) says you need consent, the standard you must meet is the GDPR standard. In short: the ePrivacy Directive tells you when consent is required, and the GDPR tells you what valid consent looks like.

That split matters in practice because it explains why a banner can satisfy one law and fail the other. You can correctly identify that a cookie needs consent (ePrivacy) and still gather that consent in a way the GDPR does not accept — for example, by assuming agreement from continued browsing. Getting cookie consent right means getting both halves right at the same time. This is general information, not legal advice; how these rules apply to your site depends on your specific facts and is the kind of judgment a privacy professional should confirm.

What 'valid consent' has to look like

The GDPR sets a deliberately high bar. Valid consent must be freely given, specific, informed, and unambiguous, and it must be expressed through a clear affirmative action. Each of those words does work. "Freely given" means the user has a genuine choice and is not penalized for declining. "Specific" and "informed" mean you tell people, in plain language, what categories of cookies you use and for what purposes before they decide. "Unambiguous" plus "clear affirmative action" means silence, inactivity, or a pre-checked box does not count — the user has to do something positive, like clicking an "Accept" button.

This is exactly what the Court of Justice of the European Union settled in the Planet49 case (Case C-673/17, judgment of 1 October 2019). The court held that consent given by a pre-ticked checkbox — one the user has to deselect to refuse — is not valid consent for storing or accessing cookies. Consent has to be active. The same ruling confirmed that the GDPR-level consent standard applies to cookies and that users must be told how long the cookies last and whether third parties can access them.

Two more requirements follow from the GDPR. First, consent must be granular: bundling everything into a single "I agree" is generally not specific enough where you set cookies for genuinely different purposes. Second, withdrawing consent must be as easy as giving it — so if one click turned cookies on, the user needs an equally simple way to turn them back off, and you must tell them how before they consent. Crucially, all of this has to happen before non-essential cookies are set. Loading your analytics or advertising tags the instant the page opens, and only then showing a banner, defeats the purpose.

The 'strictly necessary' exemption — and what it does not cover

Not every cookie needs consent. Article 5(3) of the ePrivacy Directive contains two narrow exemptions: cookies used for the sole purpose of carrying out the transmission of a communication, and cookies that are strictly necessary to provide a service the user has explicitly requested. The second of these is the one most sites rely on, and the key word is "strictly." The test is whether the cookie is essential to deliver something the user actively asked for — not whether it is useful to you.

In practice the exemption covers a small set of functional cookies: the session token that keeps a user logged in, the cookie that remembers items in a shopping cart, a load-balancing cookie that keeps the service running, or one that stores a user's consent choices themselves. These you may set without asking, because the service would not work without them.

What the exemption does not cover is the category that causes most banners to exist in the first place. Analytics cookies — including first-party and third-party web analytics that measure traffic and behavior — are not strictly necessary in the legal sense, so they require consent. Marketing, advertising, retargeting, and social-media tracking cookies plainly require consent. The fact that a tool is "first-party" or that the data feels low-risk does not change the analysis; the question is purely whether the cookie is essential to a service the user requested. When in doubt, treat a cookie as non-exempt and ask, and confirm the borderline cases against the current regulator guidance that applies to you.

Building a compliant cookie banner

A compliant banner is mostly a series of "don'ts" that follow directly from the rules above. Start by not setting non-essential cookies before the user has chosen — your analytics and marketing tags should be held back until consent is recorded, with only the strictly necessary cookies firing on load. This usually means deploying tags through a consent layer rather than hard-coding them into the page.

Give a real choice at the first layer. The accepted pattern is to make rejecting as easy as accepting: if there is an "Accept all" button, there should be a "Reject all" button of equal prominence on the same screen, not buried two clicks deep behind "Manage settings." Offer granular controls so users can accept some purposes and refuse others — typically a settings panel grouped by category (necessary, analytics, marketing, and so on), with non-essential categories off by default and no pre-ticked toggles. Provide the information the GDPR and Planet49 require: what each category does, who the recipients are, how long cookies persist, and how to withdraw consent later (a persistent link or icon to reopen the settings is the usual solution).

Be cautious with "cookie walls" — designs that block all access to a site unless the user accepts cookies. Because consent must be freely given, conditioning access on consent is problematic in most ordinary cases, and several regulators treat blanket cookie walls as invalid. There are limited, fact-specific exceptions, but a small business should not assume it qualifies for one. Finally, keep a record of the consents you collect, since the GDPR expects you to be able to demonstrate that valid consent was obtained.

The UK position and the still-pending reform

If you have UK users, the cookie rules live in a slightly different place but say much the same thing. In the UK, the relevant law is the Privacy and Electronic Communications Regulations 2003 (PECR), which implemented the ePrivacy Directive into UK law and survived Brexit. PECR carries the consent-before-cookies requirement, and it now borrows the consent standard from the UK GDPR — so the substance, including the no-pre-ticked-boxes and reject-as-easy-as-accept expectations set out by the UK's Information Commissioner's Office, tracks the EU position closely. A site serving both EU and UK visitors generally builds to the same banner design for both.

For years, the expectation was that a new EU ePrivacy Regulation would replace the aging Directive and modernize the cookie rules. That reform was proposed back in 2017 but never agreed by the EU's co-legislators, and the European Commission ultimately withdrew the proposal as part of its 2025 work programme. The practical consequence is important: there is no ePrivacy Regulation, and the ePrivacy Directive (2002/58/EC) remains the law in force. Separately, the Commission has floated broader digital-law reforms that could touch cookie rules in future, but those are proposals under discussion, not enacted law.

The takeaway is to plan around what is actually in force today rather than a regulation that did not arrive. Because this area is still subject to legislative discussion and evolving regulator guidance, confirm the current rules and any UK-specific nuances against the official sources, and with privacy counsel, before relying on a fixed design.

Where your documentation fits

Getting cookie consent right is partly an engineering job — wiring up a consent layer, holding tags back, building the banner — and partly a documentation job. The documentation side is the part regulators, customers, and your own team will ask to see: a written explanation of which cookies you set and why, how consent is obtained and withdrawn, and how the whole thing maps back to the ePrivacy and GDPR requirements. Without that, a working banner is hard to evidence and easy to let drift out of date.

This is where an editable template helps. The ComplianceDocs GDPR Compliance Pack for Small Business includes a Cookies and Tracking Policy and a Consent Management Policy, alongside the wider privacy documentation set — a data protection policy, customer and employee privacy notices, a DSAR procedure, and a Records of Processing Activities workbook for Article 30. The cookies and consent documents give you a structured starting point that already references the right obligations, so you tailor them to your actual cookie inventory and banner rather than drafting from a blank page.

It is worth being precise about what that does and does not achieve. A policy is the documentation layer of a cookie-compliance program; it is not the program. No template makes you "GDPR compliant," and there is no certificate that confers cookie compliance. Compliance comes from how your site actually behaves — whether non-essential cookies really are held until consent, whether reject is as easy as accept, whether withdrawal works — combined with the records and policies that describe it. Used that way, a toolkit removes the slow drafting and gives counsel something concrete to review; treated as a finish line, it is a false sense of security. (Any cost or time savings are illustrative estimates, not quotes; actual figures vary.)

Frequently asked questions

Do cookie consent rules come from the GDPR or the ePrivacy Directive?

Both, in different roles. The requirement to obtain consent before storing or accessing information on a user's device — which covers most cookies — comes from Article 5(3) of the ePrivacy Directive (2002/58/EC), not the GDPR. The GDPR's job is to define what valid consent means, because the ePrivacy Directive borrows the GDPR's consent standard. So the ePrivacy Directive tells you when consent is needed, and the GDPR tells you what that consent has to look like. A compliant banner has to satisfy both at once.

Are pre-ticked cookie consent boxes ever allowed?

No. The Court of Justice of the European Union settled this in the Planet49 case (Case C-673/17, judgment of 1 October 2019), holding that a pre-ticked checkbox does not amount to valid consent for storing or accessing cookies. Consent must be a clear affirmative action — the user has to do something positive, such as clicking an accept button. Silence, inactivity, continued browsing, and pre-selected toggles all fail the standard. Non-essential cookies must wait until that active consent is given.

Do analytics cookies need consent, or are they exempt?

Analytics cookies generally require consent. The ePrivacy Directive's "strictly necessary" exemption is narrow: it covers only cookies essential to deliver a service the user has explicitly requested, such as a login session token or a shopping-cart cookie. Web analytics — including first-party analytics that measure traffic and behavior — are not strictly necessary in that sense, so they need consent before they are set. Marketing, advertising, and retargeting cookies clearly require consent. When a cookie is borderline, the safer course is to treat it as non-exempt and ask.

Can I block my site behind a cookie wall until users accept?

In most ordinary cases, no. Because the GDPR requires consent to be freely given, conditioning all access to a site on accepting non-essential cookies is problematic, and several regulators treat blanket cookie walls as invalid consent. There are limited, fact-specific exceptions, but a typical small business should not assume it qualifies. A safer design offers a genuine choice — including a reject option as easy to use as accept — without locking users out for declining. Confirm the position for your situation against current regulator guidance.

Did the ePrivacy Regulation replace the ePrivacy Directive?

No. A new EU ePrivacy Regulation was proposed in 2017 to modernize and replace the Directive, but the EU's co-legislators never reached agreement, and the European Commission withdrew the proposal as part of its 2025 work programme. As a result, the ePrivacy Directive (2002/58/EC) remains the law in force for cookie consent. In the UK, the equivalent rules sit in the Privacy and Electronic Communications Regulations 2003 (PECR), read together with the UK GDPR. Because reform discussions continue, verify the current rules against official sources before relying on a fixed approach.

Related guides: GDPR

Toolkits that help

← All articles