What is the single most important field in a consent record?

The notice version is the one most often missing and most often decisive. Without it, you can show a choice was recorded but not what wording, purposes, or vendors the choice referred to, which weakens the record badly in a dispute.

How long should consent records be retained?

Tie the period to the relationship length plus the applicable limitation period for claims in your markets, write it into a retention schedule, and apply deletion across every copy, including warehouse exports and backups, when the period ends.

Does a consent banner log prove tags behaved?

No. The log proves the choice as recorded. Proving behaviour needs a production check that tags fired or stayed silent according to that state. Keep evidence of both, and repeat the behaviour check after tag manager changes.

Should rejected consent be stored with the same care as accepted?

Yes. A recorded refusal, with timestamp and version, is what stops a team from re prompting aggressively or accidentally enabling a purpose later. It also demonstrates that refusal was honoured, which regulators treat as part of valid consent design.

Storing Consent: Timestamps, Policy Versions, and Proving a Choice Later

November 3, 2026

A consent record that says yes with no date, no version, and no scope is not proof of anything. What a defensible consent record contains and how long to keep it.

Ask a site to prove that a specific visitor consented to marketing cookies on a specific day and you often get a database row that says true. No timestamp the team trusts, no record of what the banner said that day, no note of which categories were offered or chosen. If the question is being asked, it is usually being asked by someone with a deadline, and true is not an answer that survives it.

A consent record is evidence, and evidence has a structure. Who, what they were told, what they chose, when, and by what mechanism. Build the record to that standard while nothing is wrong, because reconstructing what a banner said eight months ago, after two redesigns and a change of consent provider, is close to impossible.

Five fields that make a record useful

At minimum, a record should carry a timestamp from a reliable clock, an identifier that can be associated with the visitor or device without storing more than necessary, the categories presented and the state chosen for each, the version of the banner text and privacy notice shown, and how the choice was made, banner button, preference centre, or a Global Privacy Control signal where that applies.

Version is the field teams omit and later regret. Consent is agreement to a specific description of processing. If the notice has changed since, and it will have changed, the record needs to point at the version the visitor saw. Keep old versions of the banner text and the notice, dated, in the same place the records live. A version number pointing at a document nobody retained proves very little.

Withdrawal has to be as recordable as consent

A record system that logs opt ins in detail and withdrawals vaguely will misstate the current position for a growing share of visitors. Log a withdrawal with the same care: timestamp, categories affected, mechanism, and the resulting state. Then check that the resulting state is what the site actually does. A preference centre that records a refusal while a tag still fires is not a record keeping problem, it is a false record, which is worse than a missing one.

Retention cuts the other way. Consent records should be kept long enough to demonstrate compliance for the period the processing they authorised continued, and not kept indefinitely by default. Set a retention period, document the reasoning, and delete or anonymise on schedule. A consent database that becomes a permanent, detailed history of individual browsing choices creates the kind of dataset the rules exist to discipline.

Test the record, not just the banner

Once a quarter, run the exercise nobody runs. Pick a consent state in production, change it through the preference centre, refuse through the banner, and then pull the record for that device and read it as an outsider would. Does it show the sequence correctly, with times that make sense and versions that can be retrieved? Does the site's behaviour match the final state on a fresh page load?

That test catches the failures that a banner visual check never will: records written in one timezone and displayed in another, version numbers that stopped incrementing after a provider update, and withdrawals logged to a system the tag configuration no longer reads. None of them are visible on the page. All of them are what a record is for.

Frequently asked questions

What should a consent record contain?

A reliable timestamp, an identifier for the visitor or device, the categories offered and chosen, the version of the banner and notice that was shown, and the mechanism by which the choice was made.

Why does the policy version matter in a consent record?

Because consent is agreement to a specific description of processing. If the notice later changes, the record must show which version the visitor agreed to, and that version needs to be retained and retrievable.

How long should consent records be kept?

Long enough to demonstrate compliance for the period the authorised processing continued, under a documented retention period. Keeping them indefinitely by default creates an unnecessarily detailed history of individual choices.

How do you test whether consent records work?

By exercising the live system: make and change choices through the banner and preference centre, then retrieve the record and check the sequence, timestamps, and versions, and confirm the site's actual behaviour matches the recorded final state.