blog · 5 September 2026 · 8 min read

Proof of consent under Article 7(1): what a consent record has to contain, and what ours does

A regulator or an enterprise customer asks how you got consent. “We have a banner” is not an answer. A file is. This is what has to be in it.

The burden is on you

Article 7(1) of the GDPR is one sentence: where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented. It puts the burden of proof on the site, not on the visitor and not on the regulator. In practice a supervisory authority asks a simple question, “show me the consent for this person on this day”, and the honest answers are either a record or a shrug. A banner that displayed a choice but stored nothing is a shrug.

The EDPB’s consent guidelines (05/2020) spell out what a demonstration looks like in an online context. The controller should keep information about the session in which consent was given, documentation of the consent workflow at that time, and a copy of the information that was shown to the person. Three things: the event, the process, the words. Most consent logs store the first, some store the second, almost none store the third, and the third is where a record falls apart under questioning: “what exactly did you tell them?”

Five questions a record answers

Boil the guideline down and a defensible record answers five questions: who consented, when, what they were told, how they signalled it, and whether they later withdrew. Here is a real record shape, field by field.

Every field answers one of the questions the EDPB says a controller must be able to answer: who, when, what they were shown, what they chose, and whether they withdrew.
  • Who. A pseudonymous identifier that links the record to the browser it came from, and to later withdrawals. Not an IP address, not a user agent, not a name: none of those is needed to prove consent, and each of them turns the log into a second set of personal data you now have to protect.
  • When. A timestamp with timezone, from the server, not from the browser clock.
  • What they were told. The banner version and a hash of the exact texts shown, in the language shown. With the version kept immutable, the hash is enough to reproduce the screen a year later.
  • How they signalled it. Accept all, reject all, or a custom choice, with the categories that resulted. The regime that applied (EU opt-in, US opt-out) and the country, because the same click means different things under different rules.
  • Whether they withdrew. A withdrawal is its own record, chained to the consent it revokes, so the history of a person’s choices reads in order.

How long to keep it

The EDPB’s position is that the obligation to demonstrate consent lasts as long as the processing it covers, and that afterwards the proof should be kept no longer than needed for a legal obligation or for the establishment, exercise or defence of legal claims. There is no fixed number in the GDPR. In practice that means: keep the record while you rely on the consent, and then for the limitation period in your country, which in Germany is three years from the end of the year in which a claim arose and in France five years. That is why a “12 months” log is thin for a business site and why paid CookieCrumbs plans keep records for 60 months. Free keeps 12, and every record is exportable before it ages out.

Why the record has to be tamper-evident

A log that its owner can edit proves only that its owner is honest. That is not what a regulator or a litigant is asking. The two mechanisms that make a consent log evidence rather than a claim are cheap and old: chain the records, and sign the export.

A tamper-evident log: each record carries the hash of the one before it, and exports are signed, so a third party can check a file rather than take our word.

Chaining means each record carries a hash of the record before it. Change or remove any record and every hash after it stops matching, which is detectable by anyone who holds the file. Signing means the export is accompanied by a signature over its contents, made with a key whose public half is published, so a third party can verify that the file left our systems in this exact form without trusting either you or us. Together they turn “we have logs” into “here is a file you can check”.

What CookieCrumbs stores, and refuses to

Every decision on a CookieCrumbs banner becomes a record with the fields above, chained to the one before it, in Frankfurt. Exports are signed and come as CSV or JSON, per site or per subject, from the dashboard, the CLI (cookiecrumbs logs export) or the API. Erasure requests are honoured with tombstones: the subject’s data is removed and the chain stays verifiable.

What we refuse to store is as important. No IP address beside a record, no user agent, no name. The consent id is pseudonymous and lives in the visitor’s browser. That keeps the log itself from becoming a liability, and it is the design choice that lets us say the records never need to leave the EU: there is nothing in them that would make a transfer worth arguing about. The consent records guide has the field list and the verification steps.

Sources

  1. GDPR Article 7, Conditions for consent
  2. EDPB, Guidelines 05/2020 on consent under Regulation 2016/679, version 1.1, adopted 4 May 2020
  3. ICO, “What is valid consent?”
  4. Securiti, “What is proof of consent under GDPR?”
  5. CookieCrumbs docs, Consent records

next step

See what your site loads before consent

The free scan reads your homepage and lists the trackers. No account, nothing stored.