Cookie consent management: proof, withdrawal and consent records

A cookie consent system must do more than display a banner. A business should later be able to explain which purpose a person selected, which information was available and how a withdrawal was processed in the actual system. The key is the connection between the consent text, the choice, the log and the technical behaviour.

This article examines consent management for website operators under the GDPR. It focuses on freedom of choice, granularity, information, proof, withdrawal and blocking of purposes that were not approved. The dedicated page on marketing, cookies and tracking provides the wider marketing context.

Article 4(11) GDPR describes consent as a freely given, specific, informed and unambiguous indication of a person’s wishes. It can be given by a statement or another clear affirmative action. For a consent system, this means that the interface must enable a concrete decision for a defined purpose.

Consent is a legal basis under Article 6(1)(a) GDPR. It is therefore suitable only for processing for which such a decision is intended. A banner does not replace an assessment of the data flow. Before designing it, the business should understand the purpose, data categories, providers and technical activation.

Consents for several purposes should not be turned into an opaque overall choice. The glossary entry on consent explains the terms freely given, informed and unambiguous. This article develops the evidence and withdrawal layer.

A choice is free when the person can make a genuine decision. The EDPB consent guidance stresses that refusal or later withdrawal must not lead to a disadvantage. In a banner, refusal and acceptance should therefore be clearly accessible. A design that hides or unnecessarily delays one option weakens the quality of the consent.

Granularity requires purposes to be recognisable separately. Analytics, personalisation and advertising may concern different decisions. A single button for several independent purposes leaves the scope of consent uncertain. Purpose labels, providers and data categories should be stated in terms that let a person understand the consequence of the choice.

Pre-ticked boxes, silence or mere inactivity are not clear affirmative action. The choice must be active. Changes to the banner, purposes or technologies can require a renewed assessment of the consent.

Before consenting, a person should be able to identify the controller and understand why the data is processed. The EDPB consent summary also identifies the type of data and the right to withdraw as important information. A technical product name rarely explains enough. The purpose should be described in language that does not require knowledge of a tag manager.

The information must match the choice and the actual activation. If the banner describes one broad purpose while a service activates several separate functions, there is a gap. The information text, configuration and privacy notice should be versioned together and compared after changes.

Information about withdrawal belongs in the decision process. A person should know before choosing that the selection can later be changed. A lasting link to settings supports the practical exercise of that right.

Article 7(1) GDPR requires a controller to demonstrate consent where processing is based on it. Article 5(2) GDPR also requires the controller to demonstrate compliance with the principles. A useful record therefore connects the concrete choice with the information version and the technical implementation that applied at the time.

The business should define which information is needed for that connection. This will generally include the time, selected purposes, consent information version and the consent system used. Depending on the architecture, additional technical information may be required to locate an individual choice. A general counter of accepted banners is not enough.

Records need consistent versioning. If purposes, providers or blocking behaviour change, the start of the new version should be identifiable. Ownership, access and retention of evidence belong in privacy governance. The page on privacy compliance and governance explains how evidence can be connected with organisational processes.

Article 7(3) GDPR gives a person the right to withdraw consent at any time. Withdrawal must be as easy as giving consent. A banner with a prominent acceptance and a hidden settings path falls short of this practical requirement.

Withdrawal takes effect for the affected purpose from the time it is exercised. The lawfulness of processing before withdrawal is not affected. The business should therefore record the time and scope of withdrawal in a traceable way. Historical proof must not be confused with an ongoing permission.

Withdrawal needs a technical consequence. Affected scripts, tags and downstream systems must receive the new state. Check whether a loaded function is stopped, further storage is prevented and the next session reflects the changed choice. The dedicated marketing, cookies and tracking topic places withdrawal in the wider data flow.

A consent system is coherent only when the choice controls actual activation. For every unapproved purpose, the business should know which scripts, storage or transmission processes are blocked. Technical documentation should use the same purpose structure as the banner and the records.

At a minimum, test the first page view without a choice, a specific acceptance, a refusal and a later withdrawal. Check which technologies load, which signal is stored and whether the change reaches every relevant system. Testing only the visible banner is insufficient.

Changes to a tag manager, website, analytics service or consent platform can alter the block silently. Assign an owner for configuration and document tests with date, version, result and follow-up. The page on processors and service providers helps allocate responsibility where external platforms are involved.

Refusal is hidden: Acceptance is prominent while refusal takes several additional steps. This makes the freedom of choice doubtful.

Several purposes are bundled: Analytics, personalisation and advertising are placed under an undefined heading. The person cannot relate the decision to an individual purpose.

The record stores only an aggregate: A counter or current banner view does not show which choice belonged to which information version. Proof remains incomplete.

Withdrawal changes only the interface: The settings dialogue shows a new state while scripts or platforms still use the earlier one. The block must follow the withdrawal.

Changes are not versioned: After a new provider or purpose, it is unclear which information applied at consent. Banner, records and configuration need a shared version logic.

Analytics: A business wants to understand which pages are visited. The consent should describe the analytics purpose clearly. The record and technical block must show that analytics starts only after the relevant choice.

Personalisation: A website wants to adapt content to earlier interactions. This purpose needs its own description and choice when it is separate from analytics or technical delivery. A general statement about a better user experience does not explain the processing sufficiently.

Several platforms: One consent system controls multiple providers. The business must check whether the choice, information version and withdrawal reach every relevant service. A central display is not enough if individual platforms keep separate states.

For a focused review, prepare the banner text, purpose and provider lists, technical configuration, a record extract and documented tests of acceptance, refusal and withdrawal. We compare the consent logic with the actual data flows and assess whether information, proof and technical blocking fit together. Contact us with the documents already available so that the next steps can be defined for your business.