Proof of cookie consent: what to store and for how long

21 March 2026 · FlowConsent

TL;DR

Proof of cookie consent is the set of records that demonstrate a user has given (or refused) their consent freely, informedly and unambiguously. The GDPR requires the data controller to be able to demonstrate, at any time, that consent was validly obtained. The CNIL recommends storing user choices for 6 months and keeping records of the banner code versions, the timestamp of the choice, and the categories accepted or refused.

What is proof of cookie consent?

Proof of consent is the documented record that shows a visitor has actually consented (or refused) to cookies being placed on their device. This obligation stems from Article 7, paragraph 1 of the GDPR, which states that the controller must be able to demonstrate that the data subject has consented to the processing of their personal data.

In practice, displaying a compliant cookie banner is not enough. You must also be able to prove, in the event of an audit or complaint, that the banner was functioning correctly and that user choices were recorded.

Proof of cookie consent is a timestamped record that documents the user's choice (acceptance, refusal, or customization), the information presented at the time of the choice, and the technical consequences of that choice (which scripts were activated or blocked).

What does the GDPR say about proof of consent?

Article 7.1 of the GDPR is clear: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data." The burden of proof lies with the website publisher, not the user.

Article 82 of the French Data Protection Act, which transposes the ePrivacy Directive into French law, reinforces this requirement specifically for cookies. Organizations using trackers must be able to provide, at any time, proof that valid consent was obtained.

In the event of a CNIL audit or a user complaint, it is up to you to prove that consent existed and was compliant. Without proof, consent is presumed absent.

What exactly should you store?

The CNIL, in its 2020 cookie recommendation (article 48), proposes several methods for storing proof. Here are the elements to record for each consent interaction.

User or device identifier

A unique identifier (usually a UUID generated by the CMP) that links a consent choice to a device or browser. It does not need to identify the person (no name or email required). The consent cookie identifier itself is sufficient in most cases.

Timestamp of the choice

The exact date and time when the user made their choice. This timestamp verifies that consent was obtained before cookies were placed and allows calculation of its validity period.

The choice made

The detail of what the user accepted or refused: global consent ("accept all" / "reject all") or category-level consent (analytics accepted, marketing refused, etc.). The more granular the record, the stronger the proof.

Banner version presented

The CNIL recommends keeping the different versions of the code used to collect consent. If you modify the text, design, or behavior of your banner, you must be able to demonstrate which version the user saw at the time of their choice.

Information presented to the user

The banner content (text, options, links to the cookie policy) as it was displayed at the time of the choice. This demonstrates that consent was "informed."

How long should you keep proof of consent?

There is no fixed legal duration imposed by the GDPR or the ePrivacy Directive for storing proof of cookie consent. However, the CNIL provides clear guidance.

The CNIL recommends storing user choices (consent or refusal) for a period of 6 months. After this period, the banner should reappear to request consent again. This 6-month duration is a best practice, not a strict obligation. It can be adapted on a case-by-case basis depending on the nature of the site and its audience.

For audience measurement cookies exempt from consent, the CNIL recommends a maximum tracker lifespan of 13 months and a maximum data retention period of 25 months.

Regarding the proof itself (consent logs), it is recommended to keep it for as long as necessary to demonstrate compliance in the event of an audit. In practice, this means at least for the duration of consent validity (6 months), and ideally longer to cover potential complaints or subsequent audits. A retention period of 3 to 5 years for logs is common practice in the industry.

How does a CMP manage proof of consent?

A consent management platform (CMP) like FlowConsent automates the collection, storage, and retrieval of proof of consent. Here is what a CMP should do.

For each banner interaction, the CMP automatically records a consent log containing the device identifier, timestamp, choice made (by category), and banner version. These logs are stored securely with timestamps.

The CMP must also scan cookies on the site to ensure that scripts for non-consented categories are actually blocked. Proof is worthless if cookies are placed before or despite refusal.

In the event of an audit, the CMP must allow exporting consent logs in a usable format (CSV, JSON) and reconstructing the state of the banner at a given date.

Common mistakes (and how to avoid them)

Only storing consent, not refusal. The CNIL recommends also storing user refusals. If you only store acceptances, you cannot prove that users who did not consent did not receive cookies. Fix: systematically record refusals in the same log.

Not versioning the banner. If you modify your banner text or design without archiving previous versions, you cannot prove what content the user saw. Fix: archive each banner version with a version number and production date.

Confusing cookie lifespan with proof retention period. The consent cookie (which stores the user's choice in their browser) has a limited lifespan (6 months recommended). The proof of consent (server-side log) should be kept longer. Fix: separate the two and define a distinct retention policy for logs.

Not timestamping choices. Without timestamps, it is impossible to prove that consent was given before cookies were placed. Fix: each consent log must include a precise timestamp (date + time + timezone).

Storing unnecessary personal data in logs. Proof of consent does not require the user's email or name. A technical identifier (consent cookie UUID) is sufficient. Storing superfluous personal data in logs creates an additional data processing activity that must itself comply with the GDPR. Fix: limit logs to strictly necessary data.

Relying solely on the client-side cookie. The consent cookie in the user's browser can be deleted at any time. If that is your only proof, you have nothing left. Fix: supplement with a server-side log managed by your CMP.

Checklist: compliant proof of consent

  1. Every banner interaction (acceptance, refusal, customization) is recorded in a server-side log.
  2. The log contains: device identifier (UUID), timestamp (date + time + timezone), choice by category, banner version.
  3. Refusal is recorded with the same rigor as acceptance.
  4. Successive banner versions (text, design, behavior) are archived with production dates.
  5. The duration of choice storage in the browser (cookie) is 6 months (CNIL recommendation).
  6. Server-side consent logs are kept for a minimum of 3 to 5 years.
  7. Logs are exportable in a usable format (CSV, JSON) in the event of an audit.
  8. A regular audit verifies that scripts for non-consented categories are actually blocked.
  9. Logs do not contain superfluous personal data (no email, no name, UUID is sufficient).
  10. Consent withdrawal is recorded with the same level of detail as the initial consent.

Conclusion

Proof of consent is not a bonus. It is a legal obligation. The GDPR requires the data controller to be able to demonstrate, at any time, that consent was validly obtained. Without proof, consent is presumed non-existent, which amounts to placing cookies without a legal basis.

In practice, this means using a CMP that automatically records each interaction, stores logs securely, and archives banner versions. The CNIL recommends a 6-month retention period for choices and longer retention for logs to cover audits.

To verify that your site correctly collects and stores proof of consent, run a free scan with FlowConsent.

Frequently asked questions

How long should I keep proof of cookie consent?

The CNIL recommends storing user choices (consent or refusal) for 6 months in the browser. Server-side consent logs should be kept longer to cover potential audits. In practice, a retention period of 3 to 5 years for logs is common in the industry.

What information should a cookie consent log contain?

A compliant consent log contains at minimum a device identifier (UUID), the timestamp of the choice (date, time, timezone), the detail of categories accepted or refused, and the version of the banner that was presented to the user.

Do I need to keep proof of cookie refusal as well?

Yes. The CNIL recommends storing refusal with the same rigor as acceptance. Without proof of refusal, you cannot demonstrate that cookies were not placed for users who did not consent.

Is the consent cookie in the browser sufficient as proof?

No. The client-side cookie can be deleted by the user at any time. It is essential to supplement this with a server-side log stored and managed by your CMP. This server-side log constitutes the usable proof in the event of an audit.

Does the CNIL require a specific format for proof of consent?

No. The CNIL does not prescribe a specific technical format. It recommends that proof be timestamped, stored securely, and exportable in a usable format (CSV, JSON). The key is being able to reconstruct the consent state of a user at a given date.

Do I need to version my cookie banner for proof of consent?

Yes. The CNIL recommends keeping the different versions of the code used to collect consent. If you modify your banner, you must be able to demonstrate which version the user saw at the time of their choice. Archive each version with a number and a production date.