Consent Records: How Long to Keep Them and What Proof Actually Looks Like

Saving a consent string is not the same as being able to prove consent. Here is what a defensible consent record contains, how long teams keep it, and where the gaps show up in an audit.

When a regulator or a platform asks about consent, the question is never did a banner exist. It is: for this user, on this date, what exactly were they shown, what did they choose, and which tags fired afterwards. A consent record answers that, or it is just a timestamp in a database with confidence around it.

Consent mode signals, CMP logs, and server logs each hold a piece. The audit failure mode is consistent: the pieces exist in three systems, with three clocks and no shared identifier, so nobody can line them up when it matters. Retention and proof have to be designed together, while the banner still works, not reconstructed during an enquiry.

Related reading on this site: Free consent audit, A Practical Audit Checklist for Consent Mode Signals, Consent for Email Capture Popups: Keeping the Ask and the Record Honest.

What belongs in the record

User identifier or cookie identifier, timestamp, the consent state per purpose, banner or notice version, the text or policy version shown, geography as determined at the time, and the source: banner, preference centre, or an imported offline consent. Version is the field everyone drops and everyone needs, because consent given under one wording is not automatically consent under the next.

Keep the choices granular in storage even if the interface groups them. Collapsing marketing and analytics into one stored yes makes later proof impossible when the purposes are treated differently by law, and they often are, from cross context behavioural advertising under US state laws to purpose based consent under GDPR style regimes.

Retention: long enough to defend, not forever

Teams commonly keep consent records for the life of the customer relationship plus the limitation period relevant in their markets, and document that choice in a retention schedule with an owner. Indefinite retention by neglect is its own privacy problem: consent data is personal data, and hoarding it past its purpose contradicts the same laws the banner exists to respect.

Whatever period you choose, the deletion has to work in the CMP export, the warehouse copy, and the backups cycle, or it is a policy sentence rather than a practice. Auditors test the joins between systems. So should you, once a year, with one sample user and a stopwatch.

Prove the negative too

The strongest consent record proves a no as well as a yes: this user rejected marketing, and here are the tags that consequently did not fire. That means consent state and tag behaviour need to be checkable together, in production, not in a staging environment where every tag behaves politely.

Run that check after every tag manager change. A new tag added outside the consent template can fire before consent and invalidate months of tidy banner records in an afternoon, and the consent log will still look perfect while it happens.

Frequently asked questions

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.