Consent is the most visible element of GDPR compliance for most consumers and the most operationally complex to implement correctly. The cookie banners, marketing opt-ins, and privacy checkboxes that data subjects encounter daily are the user-facing surface of consent management programmes that must, behind the scenes, capture individual consent decisions, version them against the notice shown, record withdrawal, and enable per-user, per-purpose consent state management across all processing systems.
Done properly, consent management creates a defensible record of individual authorisation for every consent-based processing activity. Done poorly, it generates consent that GDPR does not recognise as valid, creates withdrawal obligations the organisation cannot fulfil, and produces an accountability gap that supervisory authority investigations quickly expose. This article covers the full consent management lifecycle, from collection mechanism design through record-keeping and withdrawal to the infrastructure that supports it at scale.
Before Consent: Is Consent the Right Basis?
The most important consent management decision is whether consent is the right lawful basis for a given processing activity in the first place. As Article 2.2 discusses, consent is appropriate for genuinely optional processing where data subjects have a real choice. It is inappropriate — and often counterproductive — for processing that could be justified on contract, legal obligation, or legitimate interests grounds.
CONSENT VS. OTHER BASES — DECISION GUIDE
| Processing Scenario | Appropriate Basis | Why Not Consent |
|---|---|---|
| Processing necessary to deliver the service the user signed up for | Contract (Art. 6(1)(b)) | The user cannot refuse without losing the service; consent is not freely given |
| Statutory reporting to tax or employment authorities | Legal obligation (Art. 6(1)(c)) | Obligation exists regardless of consent; consent creates false impression of choice |
| Security monitoring and fraud prevention | Legitimate interests (Art. 6(1)(f)) | Consent withdrawal would undermine security; LI more appropriate and stable |
| Marketing emails to opted-in subscribers | Consent (Art. 6(1)(a)) | Genuinely optional; individual has real choice; withdrawal is reasonable |
| Optional personalisation features (e.g. tailored recommendations) | Consent (Art. 6(1)(a)) | Genuinely optional; service works without it; consent is meaningful |
| Non-essential website analytics / advertising cookies | Consent (Art. 6(1)(a)) | ePrivacy Directive requires consent for non-essential cookies regardless of GDPR basis |
Consent Collection Mechanism Design
The consent collection mechanism — the interface through which a data subject gives consent — must satisfy GDPR’s conditions simultaneously. It must be clear, accessible, and present a genuine choice. The EDPB’s Guidelines on Consent and the Transparency guidelines together provide the standard against which collection mechanisms are assessed.
CONSENT MECHANISM — DESIGN REQUIREMENTS
| Requirement | Design Implication | Common Violation |
|---|---|---|
| Freely given | No service access conditioned on consent to non-necessary processing; equal prominence for accept/reject options; no penalty for refusal | Cookie wall blocking content unless consent given; greyed-out reject button; consent bundled with T&Cs |
| Specific | Separate consent per purpose; granular controls for each processing activity; no blanket consent covering multiple uses | Single checkbox covering analytics, marketing, and personalisation together |
| Informed | Clear description of processing before consent is requested; controller identity stated; specific purposes explained; right to withdraw explained | Vague ‘improve our services’ description; no mention of third-party sharing; withdrawal instructions absent |
| Unambiguous indication | Active affirmative action required (click, tap, or explicit signature); no silence, scrolling, or inactivity as consent | Pre-ticked boxes; ‘by continuing to use the site you agree’ statements; scroll-to-accept mechanisms |
| Withdrawable | Withdrawal mechanism as prominent and accessible as consent mechanism; withdrawal takes immediate effect; no additional obstacles | Withdrawal requires navigating to buried account settings; multi-step withdrawal process; withdrawal not effective across all channels |
Cookie Consent and the ePrivacy Directive
Cookie consent deserves separate treatment because it is governed by two overlapping legal frameworks: GDPR and the ePrivacy Directive (implemented in national law across EU member states). The ePrivacy Directive requires prior informed consent for accessing or storing information on a user’s terminal equipment — which includes cookies, tracking pixels, and similar technologies — unless the cookie is strictly necessary for a service explicitly requested by the user.
Strictly necessary cookies — those essential for the website to function (session cookies, security cookies, load balancing) — do not require consent. All other cookies, including analytics cookies, advertising cookies, personalisation cookies, and social media pixels, require prior consent regardless of the GDPR lawful basis that might otherwise apply to the data processing.
COOKIE CATEGORIES — CONSENT REQUIREMENTS
| Cookie Category | Examples | Consent Required? | Consent Standard |
|---|---|---|---|
| Strictly necessary | Session ID; authentication token; CSRF protection; load balancer cookie | No | Not applicable |
| Functional (non-necessary) | Language preference; saved items; accessibility settings | Yes (ePrivacy) | Standard consent; explain purpose clearly |
| Analytics / performance | Google Analytics; Matomo; Hotjar; heatmap tools | Yes (ePrivacy) | Standard consent; explain analytics purpose; opt-out available |
| Marketing / advertising | Google Ads; Meta Pixel; LinkedIn Insight; retargeting cookies | Yes (ePrivacy) | Standard consent; list third parties; explain profiling |
| Social media | Share buttons; embedded social feeds; login with social provider | Yes (ePrivacy) | Consent before loading third-party scripts; list providers |
A compliant cookie consent banner must: present the categories clearly; provide equally prominent accept and reject options; allow granular selection by category; not fire any non-necessary cookies before consent is given; and record the consent decision per user per category. Banners that fire analytics cookies on page load and only ask for consent in the banner that appears seconds later are non-compliant — the cookies have already been set before consent was obtained.
The Consent Management Platform (CMP)
At any significant scale, consent management requires a dedicated technical infrastructure — a Consent Management Platform. A CMP manages the consent lifecycle: it presents the consent interface to users, records their decisions, stores per-user consent state, synchronises consent state across systems, and provides a withdrawal mechanism. Without a CMP, managing consent at scale — particularly across multiple channels, multiple purposes, and multiple systems — is operationally impractical.
CMP — CORE FUNCTIONAL REQUIREMENTS
| Function | What It Must Do |
|---|---|
| Consent presentation | Display consent interface with all required information; present genuine accept/reject choices with equal prominence; support granular per-purpose selection |
| Pre-consent blocking | Block all non-necessary tags, scripts, and cookies from firing until consent is obtained; not fire on page load before banner interaction |
| Consent recording | Capture per-user, per-purpose consent decision; record timestamp; record version of notice shown; store in persistent, retrievable record |
| Consent state management | Maintain current consent state per user; propagate state to all downstream systems (analytics, marketing, personalisation); handle returning users correctly |
| Withdrawal mechanism | Allow withdrawal as easily as consent was given; process withdrawal immediately; propagate withdrawal across all systems; retain withdrawal record |
| Consent proof / audit trail | Produce per-user consent record on request; evidence consent action (click event, session ID, IP); enable demonstration of compliance to DPA |
| IAB TCF compliance (for advertising) | Where used for programmatic advertising, implement IAB Transparency and Consent Framework; pass consent signals to ad tech vendors |
| Re-consent management | Identify and trigger re-consent when consent notice changes materially; manage version transitions; retire consent obtained under outdated notices |
Consent Records: Individual-Level Evidence
Article 7(1) requires the controller to demonstrate that the data subject has consented. This is an individual-level obligation — for every person whose data is processed on the basis of consent, the controller must be able to produce a record showing that valid consent was obtained from that specific individual.
MINIMUM CONSENT RECORD PER INDIVIDUAL
| Record Field | Purpose | Retention Period |
|---|---|---|
| User identifier (e.g. email, user ID) | Links the consent record to the individual’s data | Duration of processing + 3 years |
| Consent decision per purpose (granted/denied) | Evidence of scope of consent; prevents overreach | Duration of processing + 3 years |
| Timestamp of consent | Evidence of when consent was given; starts retention clock | Duration of processing + 3 years |
| Notice version shown at consent | Proves individual saw the notice they consented under | Duration of processing + 3 years |
| Consent channel (cookie banner, email opt-in, paper form, etc.) | Evidence of affirmative action mechanism used | Duration of processing + 3 years |
| Technical evidence (IP address, session ID, click event) | Corroborating evidence of consent action | Duration of processing + 3 years |
| Withdrawal timestamp and channel (if withdrawn) | Evidence that withdrawal was received and processed | 3 years post-withdrawal |
| Re-consent events (if notice materially changed) | Shows consent was refreshed when required | Duration of processing + 3 years |
Managing Consent Withdrawal
Article 7(3) requires that withdrawal of consent be as easy as giving it. This is both a design requirement and an operational requirement. The withdrawal mechanism must be as accessible and as simple as the consent mechanism — if consent was given through a single checkbox on a form, withdrawal cannot require navigating through five settings screens. If consent was given by clicking ‘Accept all’ on a cookie banner, withdrawal must be achievable by a similarly straightforward interaction.
Withdrawal takes effect immediately and prospectively — processing must stop from the moment of withdrawal. It does not affect the lawfulness of processing that occurred before withdrawal. The organisation must also ensure that withdrawal propagates to all systems that were processing the data on the basis of the withdrawn consent: if analytics consent is withdrawn, the analytics tags must stop firing; if marketing consent is withdrawn, the email system must suppress the individual.
| IMPORTANT | Withdrawal of consent cannot be made conditional or penalised. An organisation that degrades its service, charges a fee, or applies friction to the process of withdrawing consent is violating the freely-given requirement retroactively — undermining the validity of the original consent. Withdrawal must be unconditional, immediate, and consequence-free. |
Re-Consent: When Consent Must Be Refreshed
Consent does not have an automatic expiry date under GDPR. But consent becomes invalid in several situations that require the controller to seek fresh consent before continuing to process.
RE-CONSENT TRIGGERS
| Trigger | Why Re-Consent Is Required | Action Required |
|---|---|---|
| Material change to the privacy notice | Consent was given under a specific notice; processing under a materially different notice has not been consented to | Identify individuals consented under the old notice; present updated notice; seek re-consent before processing under new terms |
| New processing purpose added | Original consent was specific to stated purposes; new purposes are outside its scope | Seek fresh consent for the new purpose before processing; old consent does not extend to it |
| Consent obtained by third party transferred to new controller | Consent was given to a specific controller; processing by a different controller was not consented to | New controller must obtain its own consent; transferred consent is invalid |
| Extended retention beyond original scope | Data subject was not informed of indefinite or extended retention when consenting | Seek re-consent for extended retention; delete data from individuals who do not re-consent |
| Children reach age of digital consent threshold | Parental consent was valid during minority; individual consent required once threshold is reached | Seek individual consent at age threshold; cannot continue on parental consent basis |
Consent management is one of the most technically and operationally demanding elements of a GDPR compliance programme. Organisations that invest in a well-designed CMP, robust consent records infrastructure, and clear withdrawal mechanisms create a defensible position that can withstand DPA scrutiny. Those that rely on legacy cookie banners, undocumented consent assumptions, and manual opt-out management carry consent compliance risks that typically surface at the worst possible moments — in supervisory authority investigations or high-profile data subject complaints.
| BITLION INSIGHT | The most common consent management gap identified in DPA investigations is not the absence of a consent mechanism — it is the absence of individual-level consent records. An organisation can demonstrate it had a consent banner, but if it cannot demonstrate that a specific individual consented on a specific date to a specific processing activity under a specific version of the notice, it cannot meet Article 7(1)’s burden of proof. Consent records are not optional metadata — they are the accountability evidence for every consent-based processing activity. |