Skip to main content
Category: Consent Principles

Specific Consent

Also known as: Specificity of Consent, Specific Consent Requirement
Simply put

Specific consent means agreeing to a clearly defined, particular use of your data rather than giving a blanket approval that covers many different purposes at once. In a cookie context, this generally means a person should be able to say yes (or no) to each separate purpose, such as analytics or advertising, rather than being asked to accept everything together. Saying yes to one purpose does not imply agreement to others.

Formal definition

Specificity is one of the core conditions of valid consent under the GDPR, which requires consent to be freely given, specific, informed, and unambiguous. In most EU jurisdictions, 'specific' is generally interpreted to mean that consent must be tied to each distinct processing purpose and gathered on a granular, purpose-by-purpose basis, so that agreement to one purpose (for example, functional or analytics cookies) cannot be construed as agreement to unrelated purposes (for example, advertising or profiling). Note that the placing of and access to cookies and similar technologies is primarily governed by the ePrivacy Directive and its national implementations, while the specificity standard as a consent condition derives from the GDPR where personal data is processed; the two frameworks operate together but are distinct. The evidence packet does not address how specificity is applied to cookie consent under UK or US state privacy frameworks, which may adopt different approaches (including opt-out models), so the scope of this definition is limited accordingly. The precise degree of granularity required and how bundled purposes are assessed can depend on facts, evolving supervisory authority guidance, and the design of a given consent interface, and are not fully resolved by the sources provided.

Why it matters

Specificity is one of the load-bearing conditions of valid consent under the GDPR, alongside the requirements that consent be freely given, informed, and unambiguous. If a cookie banner bundles distinct purposes together, forcing a user to accept analytics, advertising, and profiling in a single click, the consent obtained may fail the specificity standard in most EU jurisdictions, meaning the underlying processing of personal data could lack a valid legal basis. For privacy officers and legal counsel, this is not a cosmetic design point: a defect in specificity can undermine the lawfulness of the entire consent-based data flow that follows.

The requirement also shapes how consent interfaces are built. Because saying yes to one purpose cannot be construed as agreement to unrelated purposes, consent management must allow users to make separate choices on a purpose-by-purpose basis. This has direct implications for web developers and marketing compliance teams who design and deploy cookie banners, as well as for the vendors and tags that fire only after consent is recorded for their specific purpose.

It is important to keep the two applicable frameworks distinct. The placing of and access to cookies and similar technologies is primarily governed by the ePrivacy Directive and its national implementations, while the specificity standard as a consent condition derives from the GDPR where personal data is processed. The sources provided do not address how specificity is applied under the UK or US state privacy frameworks, which may take different approaches, including opt-out models; readers should not assume the EU interpretation described here transfers directly to those regimes.

Who it's relevant to

Privacy officers and data protection professionals
Specificity is a core condition of valid consent under the GDPR, so it directly affects whether consent-based processing has a sound legal basis. Privacy teams should assess whether their consent mechanisms tie agreement to each distinct purpose, and should treat the exact granularity required as fact-dependent and subject to evolving guidance rather than settled.
Legal counsel and compliance teams
Counsel evaluating cookie practices need to keep the ePrivacy and GDPR frameworks distinct, since the specificity standard as a consent condition derives from the GDPR while the placing of and access to cookies is primarily governed by the ePrivacy Directive and its national implementations. Counsel should also flag that the EU interpretation described here may not transfer to the UK or US state frameworks, which may rely on opt-out models.
Web developers and consent interface designers
Because agreement to one purpose cannot be construed as agreement to unrelated purposes, interfaces generally need to present purposes separately and record each choice individually. Developers should note that pixels, local storage, SDKs, and fingerprinting fall within the same rules as cookies and should be gated to their specific consented purpose.
Marketing and advertising compliance teams
Marketing teams relying on advertising or profiling purposes should be aware that these generally cannot be bundled with, or inferred from, consent given for other purposes such as analytics. Tags and vendors tied to advertising should fire only where consent has been recorded for that specific purpose.

Inside Specific Consent

Purpose-level granularity
Specificity requires that consent be sought separately for each distinct purpose of processing rather than bundled into a single blanket request. Under the GDPR, consent that lumps together unrelated purposes (for example, analytics and advertising) is generally not considered specific.
Separation of cookie categories
Consent should typically be capable of being given or withheld per category of technology, such as analytics, advertising, and functional cookies. Strictly necessary or essential cookies are generally exempt and are not part of what a user consents to, whereas non-essential categories usually each require their own consent choice under EU law.
Link to the ePrivacy and GDPR dimensions
Specific consent operates across two regimes: the ePrivacy Directive (and its national implementations) governs the placing of and access to information on a device, while the GDPR governs any subsequent processing of personal data. Specificity is a GDPR consent standard, and satisfying one regime does not automatically satisfy the other.
Coverage of cookie-adjacent technologies
The specificity requirement extends beyond literal cookies to similar technologies such as pixels, local storage, SDKs, and fingerprinting, which generally fall within the same rules where they involve storing or accessing information on a device or processing personal data.
Relationship to the other consent conditions
Specificity is one of several GDPR conditions for valid consent, alongside being freely given, informed, and unambiguous. It works together with the requirement for a clear affirmative action, so a specific choice must still be actively made by the user.
Jurisdictional scope
The specific-consent standard as described here is primarily an EU/EEA GDPR concept, closely mirrored in the UK. US state frameworks such as the CCPA and CPRA in California often rely on opt-out mechanisms rather than opt-in specific consent, so the granularity expectations differ by jurisdiction.

Common questions

Answers to the questions practitioners most commonly ask about Specific Consent.

Does a single 'Accept All' click count as specific consent for every cookie category?
Not on its own. Specificity under the GDPR generally requires that consent be given separately for distinct purposes, so a user should be able to consent to, for example, analytics without also being required to consent to advertising. An 'Accept All' button may be offered, but where it is the only easy option and there is no equally accessible way to accept individual categories or reject non-essential cookies, the consent obtained is widely considered not to meet the specificity standard in most EU jurisdictions. The precise expectations can vary by national data protection authority guidance.
If I obtained specific consent once, can I rely on it for new purposes I add later?
Generally no. Because consent must be specific to the purposes presented at the time it is given, adding a new processing purpose or a materially different use typically falls outside the scope of the original consent. In most EU jurisdictions you would need to seek fresh consent for the new purpose rather than extending the existing consent. Whether a change is significant enough to require renewed consent depends on the facts, and this can be a contested judgment.
How granular do consent options need to be in practice?
Consent should generally be separable by distinct purpose rather than bundled into a single all-or-nothing choice. In practice this often means presenting categories such as analytics, functional, and advertising separately, and in some cases allowing choices at the level of individual purposes or vendors. The appropriate level of granularity is not fixed and depends on the purposes involved and applicable regulatory guidance; frameworks such as the IAB TCF structure choices at both purpose and vendor level, though using such a framework supports but does not by itself guarantee compliance.
Should strictly necessary cookies be included in the specific consent choices?
Strictly necessary or essential cookies are generally exempt from the consent requirement under EU rules, so they typically are not presented as an opt-in choice. It is common practice to inform users about these cookies for transparency, but they should not be mixed in with categories that require consent in a way that implies the user is consenting to them. Whether a given cookie truly qualifies as strictly necessary is a fact-specific assessment and can be narrower than assumed.
How should specific consent be recorded to demonstrate accountability?
Consent records should generally capture enough detail to show what the user was asked and what they agreed to, which typically includes the specific purposes or categories consented to, the time of consent, and the state of the choices made. A consent management platform can help log this information, but the record should reflect the granular, purpose-level choices rather than a single undifferentiated consent flag. Record-keeping obligations and expectations may vary by jurisdiction and by regulatory guidance.
How can withdrawal be handled so it respects the specificity of the original consent?
Because consent is given per purpose, users should generally be able to withdraw consent for individual purposes as easily as they gave it, without being forced to withdraw everything at once. In practice this usually means providing an accessible way to revisit and change category-level choices at any time. The mechanics of making withdrawal as easy as granting consent can vary in interpretation, and this remains an area where authority expectations continue to develop.

Common misconceptions

A single 'Accept all' or 'I agree' button, on its own, provides specific consent.
In most EU jurisdictions, a single accept action that bundles multiple distinct purposes is not generally regarded as specific. Users typically need the ability to consent to purposes or categories separately, though the exact expectations depend on evolving guidance from data protection authorities and the facts of each implementation.
Obtaining specific consent under the ePrivacy rules automatically covers all downstream data processing.
The ePrivacy Directive governs the storing of or access to information on a device, while the GDPR governs the processing of any personal data that follows. Consent framed around one dimension does not necessarily satisfy the specificity and other requirements of the other, and the two should be considered separately.
Specific consent applies only to cookies.
Similar technologies such as pixels, local storage, SDKs, and fingerprinting generally fall within the same rules. The specificity requirement can apply to these technologies too, so a definition limited to browser cookies understates the scope.

Best practices

Design consent interfaces so that users can accept or reject each purpose or cookie category independently, rather than presenting only a single bundled option.
Map each category (analytics, advertising, functional) to its purpose and present these distinctly, while excluding strictly necessary cookies from the consent request since they are generally exempt under EU law.
Treat cookie-adjacent technologies such as pixels, local storage, SDKs, and fingerprinting under the same specificity expectations where they store or access information on a device or process personal data.
Consider the ePrivacy and GDPR dimensions separately when assessing whether consent is specific, and do not assume that satisfying one regime satisfies the other.
Tailor consent flows to the jurisdictions you operate in, recognizing that EU/EEA and UK specific-consent expectations differ from opt-out-oriented US state frameworks such as the CCPA and CPRA.
Use a CMP and consent-logging to record what specific choices users made per purpose, while relying on legal review rather than assuming any tool guarantees compliance.