Proof of consent: keeping audit-ready consent records

Proof of consent is a record showing who consented, when, to what and how, so you can demonstrate valid consent if a regulator or a visitor asks. Under GDPR Article 7(1), that burden sits with you. A good record links a pseudonymous ID to a timestamp, the exact banner version shown, choices per category, the method used and the regional rules applied.

Why do you need proof of consent?

Because the GDPR puts the burden of proof on the organization, not the visitor. Article 7(1) says that where processing is based on consent, the controller must be able to demonstrate that the person consented, and Article 5(2) makes you accountable for showing compliance more generally.

For cookies, the duty to ask comes from Article 5(3) of the ePrivacy Directive, while the standard of consent comes from the GDPR. The EDPB’s consent guidelines leave the method up to you, but expect you to be able to show how and when consent was obtained and what information the person received at the time.

Consent records come up more often than teams expect: regulator inquiries, user complaints, data subject access requests and due diligence during funding or acquisitions. As past enforcement actions show, regulators look closely at what the banner actually did, and a clean log is the fastest way to answer.

What should a consent record contain?

At minimum: who (pseudonymously), when, what they saw, what they chose, how they chose and which rules applied. Each field answers a question an auditor is likely to ask.

Field	Example	Why it matters
Consent ID	Random UUID stored in a first-party cookie	Links the record to a browser without naming the person
Timestamp	2026-09-15T09:42:17Z (UTC)	Shows consent came before any tracking started
Banner version	banner-v14	Proves which wording, buttons and layout were shown
Policy version	cookie-policy-2026-08	Shows what information the person was given
Choices per category	Preferences on, analytics on, marketing off	Demonstrates specific, granular consent
Method	Accept all, reject all, saved preferences, GPC signal	Shows an affirmative action rather than silence
Region and rule set	EU, GDPR opt-in	Shows which legal regime your banner applied
Language	de-DE	Confirms the information was shown in the visitor’s language
Site	shop.example.com	Keeps records separate across domains and properties
Account link (optional)	Internal user ID after login	Syncs choices across devices and helps answer access requests

The method field matters because consent must come from a clear affirmative act. The CJEU confirmed in Planet49 (C-673/17) that pre-ticked boxes do not count, so a record showing a deliberate click is far stronger than one that merely says “consented.”

Log every change as a new event instead of overwriting the old one. A withdrawal is an event too, and so is a refresh when you ask again after a policy change.

Leave out what you don’t need. Store the derived region rather than the full IP address, and keep names and email addresses out of the consent log. Data minimization (Article 5(1)(c)) applies to your evidence as much as to anything else.

How do you prove what the visitor actually saw?

Version and archive every banner configuration and cookie policy. A record that says banner-v14 is only useful if you can produce banner-v14 exactly as it appeared, including button labels, categories, vendor lists and every language variant.

Practical rules that make this work:

• Treat banner text and settings as versioned content with a changelog and a named approver.
• Keep a rendered snapshot of each version in each language.
• Keep the scan results that fed your cookie list at the time; a regular cookie audit produces them.
• Bump the version whenever purposes, vendors or wording change, and ask again when the change is material.

Why does tamper-evidence matter?

A consent log you can silently edit is weak evidence. If records can be changed after the fact, an auditor can’t tell a genuine log from one tidied up just before an investigation.

Tamper-evident logs make edits detectable. The common technique is a hash chain: each record stores a cryptographic hash of the previous record, so changing or deleting any entry breaks every hash that follows it.

import { createHash } from 'node:crypto';

type Category = 'necessary' | 'preferences' | 'analytics' | 'marketing';

interface ConsentRecord {
  consentId: string;
  timestamp: string;
  bannerVersion: string;
  region: string;
  method: 'accept_all' | 'reject_all' | 'save_preferences' | 'gpc';
  choices: Record<Category, boolean>;
  prevHash: string; // hash of the previous record in the chain
}

function hashRecord(record: ConsentRecord): string {
  // Use a canonical serialization in production so key order can't change the hash
  return createHash('sha256').update(JSON.stringify(record)).digest('hex');
}

Pair the chain with append-only storage and tightly restricted write access. Periodically copy the latest hash to a separate system or a signed export, so even an administrator can’t rewrite history without the mismatch showing up.

How long should you keep consent records?

Keep each record for as long as you rely on that consent, plus a limited period afterward. The GDPR sets no fixed number of years.

The EDPB’s guidelines say the duty to demonstrate consent lasts as long as the processing does. Once the processing ends, keep the proof only as long as you need it for legal obligations or possible legal claims. Write your chosen period into your retention policy and apply it automatically.

Also decide how often you will ask again. Relying on a single click indefinitely is hard to defend, and some regulators publish guidance on refresh intervals, so check what applies in your markets.

Audit-readiness checklist

Run through these questions before an auditor does:

1. Given a consent ID, can you retrieve every event for it in order?
2. Can you produce the exact banner and policy version the person saw?
3. Can you show that non-essential scripts didn’t run before consent?
4. Are rejections and withdrawals logged as clearly as acceptances?
5. Would you detect an edited or deleted record, and who can write to the log?
6. Is the log minimized, access-controlled and covered by a retention rule?
7. Can you export one person’s records in a readable format for an access request?

If you can’t answer all seven, start with the gaps nearest the conditions for valid consent: what the person saw and how they acted.

Bottom line

Proof of consent is about being able to tell a complete, believable story about any visitor’s choice: what they saw, what they did, when, and under which rules. Minimize what you store, version what you show and make the log tamper-evident. Tools like Cookiesh can automate the record-keeping with immutable, hash-chained consent logs.

This article is general information, not legal advice. For decisions about your specific situation, consult a qualified privacy professional.