# What a Consent Record Has to Contain to Hold Up

Source: https://consentvigil.com/blog/2026-11-08-consent-record-five-fields.html

[Home](../index.md) / [Blog](index.md) / TCF v2.4 Is Past Its Deadline. Check What Your CMP Actually Sends / What a Consent Record Has to Contain to Hold Up


Published 2026-11-08

When a regulator asks for proof of consent, the question is never whether you had a banner. It is whether you can show, for one named visitor, what they agreed to, when they agreed, and to what exact text. GDPR Article 7(1) puts that burden on you: the controller has to demonstrate consent was given, not the visitor. A log line that says "accept, 14:02" demonstrates nothing.

Most consent records fail on the same gap. They record the outcome and lose the context. The banner changed three times since, the vendor list changed twice, and nobody can say which version the visitor actually saw. The record is accurate and useless at the same time.

## The five fields every record needs

First, who. Not a name, usually: a pseudonymous identifier tied to the browser or the account, stable enough that a deletion request can find the same record later. Second, when: a timestamp with a timezone, because consent given before a vendor was added cannot cover that vendor. Third, what: the purposes and the vendors the person agreed to, in the exact terms shown, not a summary written afterwards. Fourth, how: the banner version, the text, the button layout, and whether the choice came from the banner, a settings panel, or a signal like GPC. Fifth, the change history: every withdrawal, every re-prompt, and what the site did with each one.

That fifth field is the one teams skip, and it is the one an auditor reads first. Consent is not a single event. People withdraw it, vendors get added, purposes change. A record with no change history describes a consent that never moved, which is not how real visitors behave.

## Where most logs fall apart

The common failure is confusing the consent string with the consent record. The string is the encoded signal sent downstream: which purposes, which vendors, in a compact format the IAB framework defines. The record is the evidence around it. The string says yes to vendor 12. The record says vendor 12 was shown as an advertising partner under a banner version dated October 3, and the visitor clicked accept at 14:02. One without the other leaves a hole a regulator can put a finger through.

The second failure is versioning. Teams A/B test banners, swap vendor lists, and rewrite purpose descriptions, and the log keeps saying "accept" as if nothing changed. The fix is boring and cheap: freeze a copy of every banner version, give it a number, and put that number in every record collected while it ran. When a variant is retired, its records stay, because they describe real consent collected while it ran. What stops is new consent under it.

The third failure is retention without a rule. Records kept forever become a liability of their own, and records deleted after 30 days cannot answer a complaint that arrives in month six. Tie retention to the processing: keep the record while you rely on the consent, plus the limitation period for claims in your jurisdiction, then delete it. Write the rule down. "We keep them" is not a rule.

## How long to keep the record

There is no single number in the law, which is why teams guess. The defensible answer is tied to purpose: as long as the consent is the legal basis for processing that person's data, and long enough after that to answer a complaint. For most sites that means years, not weeks. The EDPB's Guidelines 05/2020 on consent make the expectation plain: you must be able to demonstrate that consent was obtained, and demonstration needs the record to survive until the question stops being askable.

Run the export test before you need it. Pick a real visitor identifier, ask your CMP for that person's full record, and time how long it takes. If the answer needs a vendor ticket and three days, the record keeping has already failed. The export test is the difference between having records and being able to show them.

Keep reading: [The Consent Record Export Test Every Team Should Run Once a Quarter](https://consentvigil.com/blog/2026-11-03-consent-record-export-test.md), [When Your CMP Vendor List Changes, Who Has to Re-Consent?](https://consentvigil.com/blog/2026-11-07-cmp-vendor-list-change-reconsent.md), and [A/B Testing a Consent Banner Without Breaking Your Consent Records](https://consentvigil.com/blog/2026-11-07-consent-banner-ab-test-records.md) cover the nearby cases in this series.

## Frequently asked questions

### Does GDPR say exactly what a consent record must contain?

No fixed form, but Article 7(1) puts the burden of proof on the controller, and the EDPB's Guidelines 05/2020 expect you to demonstrate consent was obtained. In practice that means who, when, what they agreed to, how the choice was presented, and the change history.

### Is the consent string the same thing as the consent record?

No. The string is the encoded signal sent downstream, listing purposes and vendors in a compact format. The record is the evidence around it: the banner version, the exact text shown, the timestamp, and what happened when the person withdrew or changed their choice.

### How long should I keep consent records?

As long as the consent is the legal basis for processing that person's data, plus the limitation period for claims in your jurisdiction. For most sites that means years, not weeks. Write the retention rule down and delete records when it expires.

### What happens if a vendor list change is not recorded?

Consent collected before the change may not cover the new vendor, and you cannot prove otherwise without the record. That is why the vendor list version belongs in every record, and why a list change can force a re-consent prompt.