Consent Logging & Audit Requirements: How to Prove Consent Under GDPR

Collecting Consent Is Not the Same as Proving It

Most website owners think of cookie consent as a one-way street: show a banner, let the visitor click, and move on. But the General Data Protection Regulation does not stop at obtaining consent — it places the burden of proof squarely on you. Article 7(1) is unambiguous: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented."

That single word — demonstrate — turns consent from a UI interaction into a record-keeping obligation. If a data protection authority opens an investigation, a disgruntled user files a complaint, or your organisation is acquired and the buyer runs due diligence, "we have a banner" is not an answer. You need to produce, for a specific visitor at a specific moment, evidence of what they were shown and what they chose. This guide explains exactly what that evidence looks like, how to store it, and how long to keep it. If you are still working out the basics of lawful processing, start with What Is GDPR? and GDPR Requirements for Websites.

What a Defensible Consent Record Must Contain

A consent log is only useful if it can reconstruct the moment of consent in enough detail to satisfy a sceptical regulator. Guidance from the European Data Protection Board makes clear that a bare timestamp is not enough — you must be able to show what the user agreed to, not merely that they clicked. A complete record captures the following:

• A pseudonymous user or session identifier — enough to tie the record to a visitor without storing unnecessary personal data.
• Timestamp — the exact date and time the choice was registered, ideally in UTC.
• The consent choices themselves — granular, per-purpose decisions (analytics: granted, marketing: denied, preferences: granted), not a single all-or-nothing flag.
• The banner version or configuration shown — which text, which purposes, and which vendor list the user actually saw.
• Proof of the action taken — accept all, reject all, or a custom selection saved from the preferences panel.
• The legal/region context — which framework applied (for example GDPR for an EU visitor versus a US opt-out regime), since the standard of consent differs by jurisdiction.

The granularity point matters most. Because valid GDPR consent must be specific and unbundled, your log has to prove the user could refuse one purpose while accepting another. A record that only stores "consented: true" cannot demonstrate this, and a regulator may treat it as no proof at all.

The Consent Receipt: A Portable Proof Format

The cleanest way to think about a consent record is as a consent receipt — a structured, machine-readable snapshot issued at the moment of consent, much like a payment receipt documents a transaction. The Kantara Initiative formalised this idea, and the concept now underpins how mature consent management platforms store proof. A receipt-style record is self-contained: it bundles the identifier, the timestamp, the purposes, the controller's identity, and the choices into a single immutable object.

The advantage of a receipt over a row scattered across application tables is integrity. A well-designed consent log is append-only: each new choice creates a new record rather than overwriting the old one, so the full history of a user's decisions — including withdrawals and re-grants — is preserved. This history is itself evidence. If a user claims they never consented to marketing, an append-only log can show the exact sequence: granted on one date, withdrawn on another, never re-granted. To understand how granular per-purpose choices feed into analytics, see How Consent Mode v2 Affects GA4 Reporting.

Withdrawal Must Be Logged Too

Article 7(3) gives every data subject the right to withdraw consent at any time, and crucially, it must be "as easy to withdraw as to give." Many websites build a polished accept flow and then forget the other half: the withdrawal event needs the same rigorous logging as the grant. When a user re-opens your preferences panel and turns off marketing, that action is a data point a regulator will want to see honoured.

Two failures recur here. First, the withdrawal is recorded in the database but never actually propagated — tags keep firing, scripts keep loading, and the user's stated preference is ignored in practice. Second, the withdrawal overwrites the original grant, destroying the audit trail. The fix for both is the same discipline: treat consent as an event stream, log every transition, and ensure your tag-loading logic reads the current state on every page load. The mechanics of actually blocking scripts until consent is covered in How to Block Scripts Until Cookie Consent.

How Long Should You Keep Consent Logs?

GDPR sets no fixed retention period for consent records, which trips up a lot of teams. The governing principle is storage limitation (Article 5(1)(e)): keep the data only as long as it serves its purpose. For consent logs, the purpose is demonstrating compliance, so the practical answer is tied to liability windows rather than a number handed down by the regulation.

The widely accepted approach is to retain a consent record for as long as the processing it authorises continues, plus a buffer to cover the limitation period for legal claims after the relationship ends. In practice many organisations settle on retaining proof for a period in the range of the statute of limitations in their jurisdiction. There is a second, separate clock: many regulators and CMPs recommend re-asking for consent periodically — commonly every six to twelve months — so that consent does not go stale. Re-prompting generates a fresh record and keeps your evidence current. Whatever periods you choose, document the reasoning in your records of processing, because an arbitrary retention window is itself a compliance weakness.

Surviving an Actual Audit

When a supervisory authority or a customer's procurement team asks you to prove consent, the request is almost always specific: "Show us the consent record for this user, or for visitors during this campaign." The difference between a stressful scramble and a five-minute export is whether your logging was designed for retrieval. Three properties make a consent log audit-ready.

First, it must be queryable by identifier and date range, so you can isolate the exact records requested without exporting your entire database. Second, it must be tamper-evident: if anyone can quietly edit a record after the fact, the whole evidentiary value collapses, which is why append-only storage and access controls matter. Third, it must be exportable in a human-readable form, because the people reviewing it — lawyers, auditors, regulators — are not going to read your raw schema. A consent management platform that issues structured receipts gives you all three out of the box. For a broader view of how laws differ on what "valid consent" even means, compare regimes in GDPR vs CCPA vs PECR.

Building It Right From the Start

Consent logging is cheap to design in and painful to retrofit. The teams that struggle bolt on logging after launch, then discover their banner never versioned its configuration or that withdrawals overwrote grants for a year. The teams that breeze through audits treated proof-of-consent as a first-class requirement: append-only records, per-purpose granularity, versioned banners, and a documented retention policy.

A consent management platform handles this layer so you do not have to build an evidence pipeline by hand — but the principles above are what you should verify any platform actually delivers. Consent is a legal relationship, and it is only as strong as the records that document it. To see where logging sits in the wider picture, read What Is a CMP? and the official text of GDPR Article 7, alongside EDPB guidance on consent.