“Proof of consent” regularly appears in CMP comparisons. Some solutions provide a registry in which every consent is recorded, sometimes with an identifier, date and various details about the choice that was made.
This can create the impression that a website must store a database row for every visitor who clicked “accept”.
The reality is more interesting. An organization relying on consent must indeed be able to demonstrate that valid consent was collected, but that does not necessarily mean individually identifying and recording every visitor in a centralized registry.
I am not a lawyer and this article obviously does not replace the analysis of a DPO or legal adviser when the context requires it. I am mainly looking at the practical recommendations provided by the French data protection authority for cookies and other trackers.
Yes, consent must be demonstrable
The principle is clear: data controllers must be able to demonstrate that users gave their consent when consent is the basis being relied upon.
For cookies and other trackers, this notably means being able to show that the mechanism being used was actually capable of collecting valid consent.
The important nuance lies in the word “demonstrate”.
Demonstrating that consent was correctly collected is not necessarily the same as storing the identity and click of every person who used the website.
Examples of evidence provided by the CNIL
The French data protection authority provides several examples of mechanisms that can contribute to this proof.
These include preserving different versions of the code used to collect consent, potentially with a mechanism capable of demonstrating their authenticity and date.
It also mentions timestamped screenshots of what was displayed to users, regular audits of the consent mechanism and preserving successive CMP configurations.
These examples are interesting because they focus mainly on how the mechanism worked: what did the user see and how did the system behave when the choice was collected?
Why preserve different versions of the banner?
Imagine that a website is reviewed two years after its banner was changed.
The version currently visible does not necessarily show how consent was collected two years earlier. Text may have changed, buttons may have moved and the services present on the website may have evolved.
Preserving successive configurations makes it possible to reconstruct that situation.
A screenshot of the banner, its deployment date, its configuration and the version of the code being used may then be far more useful than a simple database row saying that an anonymous identifier clicked “accept” at 2:32 p.m.
A recorded click does not by itself prove valid consent
This is probably the most important point.
A database may perfectly demonstrate that a visitor clicked “accept”. But if the interface did not make rejection equally easy, if purposes were not properly explained or if trackers had already loaded before that click, the record does not solve the problem.
It proves that a technical event occurred. By itself, it does not prove that the conditions required for valid consent were met.
The quality of the consent mechanism therefore remains fundamental.
Remembering the choice in the browser is a different issue
It is also important to distinguish proof of consent from remembering the user’s choice.
A CMP generally needs to remember that a visitor accepted or rejected certain services. Without this, the banner would reappear on every page and the choice could not be applied throughout navigation.
This choice can be stored locally in the browser. It does not automatically need to be transmitted to a central database operated by the CMP.
The French data protection authority recommends remembering both acceptance and rejection for an appropriate period so users are not continuously asked again. It generally considers six months a good practice, depending on context.
tarteaucitron remembers the choice without creating a central registry
tarteaucitron obviously needs to remember the choices required for its operation in the browser. This is what allows it to know which services may load on subsequent pages.
However, tarteaucitron.io does not maintain a central database containing an individual history of visitors across all websites using the CMP.
This is deliberate. I do not want to receive additional information about visitors simply because a website uses tarteaucitron.
The banner and service-control mechanism do not require this centralization.
What can a publisher actually preserve?
To document a consent mechanism, I would first preserve the elements that make it possible to understand how it operated at a particular date.
- The CMP version being used.
- The configuration applied during that period.
- The list of declared or controlled services.
- A screenshot of the first banner layer and preference panel.
- The text presented to visitors.
- The date of significant configuration changes.
- Where relevant, audit or technical test results showing tracker behaviour before and after consent.
This documentation can demonstrate the website’s actual operation far more precisely than a general statement that “a CMP was installed”.
A Git history can already provide useful evidence
For a website maintained by developers, part of this evidence may already exist.
A Git repository can reveal the code used at a particular date. Commits are dated and show successive changes to the integration.
If CMP configuration is itself versioned, the exact settings used at the time can also be recovered.
The French data protection authority explicitly includes preserving code and its different versions among the mechanisms that can contribute to demonstrating how consent was collected.
Screenshots are useful too
Code does not always make it easy to see what the user actually saw.
A timestamped screenshot can preserve the appearance of the banner, visible text and presentation of the available choices.
For a significant change to banner design or behaviour, preserving a desktop and mobile screenshot therefore seems like a very simple precaution.
It can notably document how acceptance and rejection were presented at the same point in time.
Technical tests complete the evidence
A perfectly designed banner can still be incorrectly integrated.
It is therefore useful to preserve evidence of technical checks as well: no relevant trackers before consent, loading after acceptance, continued blocking after rejection and the ability to withdraw consent.
These checks can be performed manually with DevTools or included in more formal audits.
I explain the verification process in my article about checking whether trackers are actually blocked.
An individual registry can still address a real requirement
None of this means that consent registries are useless.
An organization may have a particular context, internal processes or other forms of processing for which individual traceability is desirable. Some CMPs therefore provide this functionality and it can be a genuine selection criterion.
I simply disagree with the idea that a CMP which does not centralize every click is, by definition, incapable of contributing to proof of consent.
The recommendations from the French data protection authority themselves demonstrate that several mechanisms can contribute to that proof.
Be careful about collecting data to prove that you minimize data
There is also a paradox worth considering.
Adding a central registry may involve transmitting and storing additional information about visitors: an identifier, choices, date, technical context or other data depending on the solution.
If that registry addresses a genuine requirement, such collection can of course be properly justified and organized.
But I do not think a new visitor database should automatically be created simply because a commercial feature list presents a “consent log” as essential to every CMP.
The best proof starts with a correct mechanism
Before considering how to prove consent, the first priority is making sure the consent being collected is valid.
Visitors must receive the necessary information, be able to accept or reject freely and the relevant services must actually respect their choice.
Preserving configuration versions, the screens presented to visitors and audit results can then document how that mechanism operated over time.
A database containing millions of clicks will never compensate for a banner or integration that was incorrect in the first place.
