Proof of Consent Under GDPR: What Records You Need and How to Keep Them

The Burden of Proof Sits With You, Not the User

Article 7(1) of the GDPR is one sentence and it changes everything: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented." That word -- demonstrate -- is an evidentiary obligation. During any DPA inquiry, the regulator doesn't need to prove you lacked consent. You need to prove you had it.

If you can't produce a record that reconstructs who consented, when, to what, and under which version of your notice, the consent is treated as if it never existed. This guide is for DPOs preparing for audits: what fields a defensible record must contain, the technical schema, what regulators actually request, documentation failures that lead to fines, and cross-border complications. For the foundational mechanics of consent logging, see our companion guide on consent logging and audit requirements. This article goes deeper on proof as evidence.

What "Demonstrate" Actually Requires

The EDPB's Guidelines 05/2020 on consent flesh out what "demonstrate" means operationally. Three requirements emerge:

1. Specificity. You must show the data subject consented to each distinct purpose -- not merely that they interacted with a banner. A single boolean is almost certainly insufficient.
2. Contemporaneity. The record must have been created at the time consent was given. Retroactive logs carry no evidentiary weight.
3. Context preservation. You must reconstruct what the user was shown: banner wording, purposes, vendors, and cookie policy version. Without this, you can prove that something was clicked but not what was agreed to.

Together these mean a consent record is an evidence package, not a log entry. Storing only a timestamp or a user ID and a flag will not satisfy the accountability principle under Article 5(2). For the broader framework, see GDPR requirements for websites. The full text of GDPR Article 7 and the EDPB consent guidelines are the primary sources.

Anatomy of a Defensible Consent Record

A consent record that can withstand regulatory scrutiny needs to capture eleven categories of data. Our consent logging guide covers the basics; here's the complete evidentiary set:

• Consent ID -- a unique pseudonymous identifier (UUID) for this event, not tied to the user's real identity.
• Timestamp (UTC) -- exact date and time the choice was registered. UTC avoids cross-timezone ambiguity.
• Per-purpose consent state -- individual choices for each category (necessary, analytics, marketing, preferences). "All accepted" is weaker proof than per-category records.
• Consent method -- how consent was collected: accept-all button, reject-all, individual toggles, or regional auto-grant. This proves deliberate action versus defaults.
• Banner/configuration version -- a version identifier or timestamped snapshot of the exact text, purpose descriptions, and vendor list displayed. Without the ability to reconstruct which version was shown, you can't prove informed consent.
• IP address -- truncated or pseudonymised. Corroborates the event and helps establish geographic context.
• TC String -- if operating under IAB TCF, the encoded per-vendor and per-purpose consent string. See TCF for publishers.
• Consent mode / legal framework -- which regime applied: GDPR, UK GDPR, LGPD, CCPA, etc.
• Country and region -- detected visitor location, corroborating that the correct framework was applied.
• Page URL and referrer -- where consent was collected, relevant when different pages present different consent contexts.
• Privacy signal state -- whether GPC or DNT was active. Under US state laws and GDPR guidance, recording these signals documents awareness and response.

What Regulators Actually Ask For During Audits

Based on enforcement decisions from CNIL, the Irish DPC, the ICO, and the Bavarian DPA, regulators follow a predictable pattern:

Phase 1: Specific-user request. "Produce the consent record for visitor [identifier] on [date]." Tests whether records are queryable by individual and time range.

Phase 2: Version reconstruction. "Show us what this visitor was shown." The regulator wants the banner text, purposes, and vendor list from the date of consent -- not your current banner.

Phase 3: Technical verification. "Demonstrate that non-essential cookies were not set before consent." Auditors compare consent timestamps against network traces. See how to block scripts until consent.

Phase 4: Withdrawal test. "Show the withdrawal record. Then show processing stopped." Tests both logging and operational enforcement.

Phase 5: Retention justification. "Explain your retention period and legal basis." No fixed statutory period exists; the regulator wants documented reasoning, not an arbitrary number.

Technical Schema for Consent Records

Below is a reference schema for a consent log table designed for regulatory defensibility:

consent_logs
├── id                  UUID        -- unique consent event identifier
├── banner_id           UUID        -- FK to the banner configuration
├── consent_method      TEXT        -- 'accept_all' | 'reject_all' | 'custom'
├── consent_given       JSONB       -- per-category choices + consentId
├── purpose_choices     JSONB       -- US opt-out specifics
├── tc_string           TEXT        -- IAB TCF consent string (nullable)
├── ip_address          TEXT        -- truncated/hashed visitor IP
├── user_agent          TEXT        -- browser identification
├── page_url            TEXT        -- URL where consent was collected
├── country / region    TEXT        -- geolocation at consent time
├── event_type          TEXT        -- 'consent_given' | 'consent_changed'
├── consent_mode        TEXT        -- 'gdpr' | 'uk_gdpr' | 'ccpa' | ...
├── privacy_signal      TEXT        -- 'gpc' | 'dnt' | null
├── variant_id          UUID        -- A/B test variant (if applicable)
└── created_at          TIMESTAMP   -- server-generated UTC timestamp

Three design decisions make this audit-ready: it's append-only (every action creates a new row, preserving full history), the event_type field creates a clean timeline of grants and withdrawals, and consent_given stores per-purpose choices inline so granularity is met at the storage level.

The Consent Receipt: A Portable Proof Standard

The Kantara Initiative's Consent Receipt Specification (v1.1) formalises the idea that every consent event should produce a self-contained, machine-readable record -- a receipt identifier, jurisdiction, timestamp, controller identity, processing purposes, and consent status per purpose, bundled into one retrievable object.

No DPA mandates this format, but it solves the retrieval problem: when a regulator asks "produce the record for this visitor," a receipt-based system returns a single JSON document that answers every follow-up question without further queries. ISO/IEC 29184:2020 extends this with guidance on multi-language notices and linked privacy policies. For how TCF's TC String fits into this as a machine-readable proof layer, see TCF 2.2 vs Google Consent Mode v2.

Retention: No Fixed Period, But Not "Forever"

GDPR sets no retention period for consent records. The governing principle is storage limitation (Article 5(1)(e)): keep data only as long as it serves its purpose. For consent records, that purpose is demonstrating compliance, which creates two overlapping clocks:

1. The processing clock. Retain the record as long as you rely on it to justify processing.
2. The liability clock. After the relationship ends, retain long enough to cover limitation periods for legal claims -- typically three to six years in most EU jurisdictions.

Don't retain indefinitely (that's a storage-limitation violation) and don't delete prematurely (a complaint filed two years post-withdrawal requires the historical record). Document your retention period and reasoning in your ROPA. The reasoning matters more to a regulator than the specific number.

Handling Withdrawal and Re-Consent

The consent lifecycle is a sequence, not a single event. Your proof system must handle grants, withdrawals, and re-consents without losing or conflating records.

When a user withdraws, three things happen simultaneously:

1. A new record is created with event_type "consent_changed" and the withdrawn categories set to denied. The original grant record stays intact.
2. Processing stops. Tags gated by the withdrawn category cease firing on the next page load.
3. The timeline remains intact. A regulator should see: granted on date A, withdrew on date B. If date B is missing or the grant was overwritten, the proof chain is broken.

Re-consent after withdrawal is a fresh event -- not a "restore" of the original grant. It generates a new record referencing the current banner version, which may have changed since the original consent. If the vendor list or purpose descriptions changed, the user is consenting to different terms, and the record must reflect that.

Cross-Border Consent Records: What Each Jurisdiction Demands

When your website serves visitors across jurisdictions, your consent records must reflect which framework applied to each visitor and satisfy that framework's specific proof standard.

EU GDPR (EEA). Prior opt-in required. Proof must show affirmative action, per-purpose granularity, and informed notice. CNIL, the Irish DPC, and Italy's Garante are the most active enforcers and request the most granular evidence. Article 7(1) is the operative proof obligation.

UK GDPR + PECR. Substantively aligned with EU GDPR but enforced by the ICO. Record consent mode as "uk_gdpr" to demonstrate jurisdiction-appropriate treatment. See PECR and UK cookie law after Brexit.

Brazil (LGPD). Requires free, informed, and unambiguous consent. The ANPD's proof expectations mirror the GDPR model. See LGPD compliance guide.

United States (state laws). Most state laws follow an opt-out model. Proof means demonstrating that you provided and honoured an opt-out mechanism and respected GPC signals where required. Records should capture opt-out choices (sale/sharing, targeted advertising) and privacy signals. See US state privacy laws 2026.

Canada (PIPEDA). Requires meaningful consent appropriate to data sensitivity. Records should document the collection method and privacy notice version. See PIPEDA and cookie consent.

The common thread: your schema must include a jurisdiction field. A single undifferentiated log that treats all visitors identically is a vulnerability during any cross-border audit.

Making Records Tamper-Evident

If records can be modified after the fact, a regulator has no reason to trust them. Three measures harden a consent log:

1. Append-only storage. Allow INSERT but not UPDATE or DELETE. In PostgreSQL, enforce via a trigger or restrict the application's DB role to INSERT-only on the consent table.
2. Access controls. Only the consent-collection endpoint writes records. Admin interfaces get read-only access. Log all access separately.
3. Integrity verification. Hash each record at creation time. For high-assurance environments, chain hashes across sequential records so that altering one invalidates the chain from that point forward.

These measures address the implicit question behind every audit: "How do I know this record wasn't fabricated after the complaint?"

How CookieBeam Implements GDPR-Ready Proof of Consent

CookieBeam's consent logging was designed around the evidentiary requirements in this guide. Each consent event creates an immutable record containing:

• Consent ID (UUID) -- unique event identifier, queryable for regulator requests and DSARs.
• Per-purpose consent state -- individual choices for necessary, analytics, marketing, and preferences. A separate purpose_choices field captures US opt-out decisions (sale/sharing, targeted advertising, sensitive data).
• Event type -- tagged as consent_given or consent_changed (including withdrawals). Append-only: the full history is preserved.
• Banner versioning -- every published configuration is stored as a numbered, timestamped version with a full snapshot. The configuration active at the consent timestamp can be reconstructed by matching the consent record's timestamp against the version history.
• IP, user agent, and geolocation -- corroborating evidence including detected country and region.
• TC String -- when TCF is enabled, the encoded consent string is stored per event.
• Consent mode and privacy signals -- the applicable legal framework and any GPC/DNT signals detected at consent time.
• A/B test variant -- the exact banner variant shown, linking the consent record to the specific user experience.

Records are indexed for retrieval by banner, team, date range, and country -- optimised for the specific-user and date-range queries regulators make during audits.

Moving From Compliance Theatre to Actual Proof

A banner is a user interface. Proof of consent is an evidence system that must survive pointed questions months or years after the consent event. The organisations that pass audits cleanly treat consent records as first-class data, version everything the user sees, and can produce a specific visitor's history in minutes.

If you're a DPO reading this before an audit rather than during one, start with the checklist above, verify your schema covers the required fields, and confirm your CMP delivers this evidence depth in its actual records -- not just in marketing materials. The GDPR cookie compliance checklist covers the broader compliance picture; this guide is the deep cut on the proof layer.