GDPR Consent Records: What You Must Log, How Long, and What Auditors Ask For
Under GDPR, a working consent banner isn't proof of anything — the record behind it is. This guide sets out the exact GDPR consent records requirements: the fields you must log, how long to keep proof of consent (including after you delete the data), and what a supervisory authority actually asks for when a complaint lands.
GDPR consent records requirements come from Article 7(1): where you rely on consent, you "shall be able to demonstrate that the data subject has consented." That means keeping a per-person, retrievable record of who consented, when, what they were shown, how they signalled agreement, and whether they later withdrew.
Keep that proof for as long as you rely on the consent, plus a further period to defend a legal claim — then delete it. This is general information for DPOs and site owners, not legal advice.
If you're a DPO or a site owner relying on consent as your lawful basis, one uncomfortable question decides whether you're compliant: can you produce, for a specific individual, proof that they consented — and reconstruct what they saw when they did? Not "do you have a banner." Not "do you have a privacy policy." Can you produce the record. That single capability is what the GDPR consent records requirements are really about, and it's where a surprising number of otherwise-careful organizations fall short.
Why the record — not the banner — is the proof
The whole obligation rests on one sentence. Article 7(1) GDPR: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented." That flips the usual burden — you don't wait for a regulator to prove you lacked consent; you must be able to prove you had it, on demand, for any individual.
This is an accountability obligation, and it's easy to under-build. The instinct is to invest in the collection side — the banner, the preference center, the policy — and treat logging as a byproduct. In regulatory reality it's the reverse: the banner is the collection mechanism; the log is the compliance output. A beautifully designed banner with no retrievable record behind it demonstrates nothing. Conversely, a plain banner backed by complete, versioned records is defensible.
The ability to show, for any individual, that they gave a freely given, specific, informed, and unambiguous indication of agreement (Article 4(11)) — and to reproduce the circumstances in which they gave it: the wording, the notice version, and the workflow live at that exact moment.
The EDPB is explicit about what this looks like in practice. In its Guidelines 05/2020 on consent, the Board states that a controller "may keep a record of consent statements received, so [it] can show how consent was obtained, when consent was obtained and the information provided to the data subject at the time." That sentence is effectively your record-keeping spec.
What a GDPR consent record must contain
Translating Article 7(1) and the EDPB guidance into concrete fields, a defensible consent record captures five things — with a sixth (the notice snapshot) that ties them together. These are the fields a regulator, and any competent auditor, will expect to see. (For the mechanics of collecting that consent in the first place — banners, granularity, prior blocking — see our guide to cookie consent.)
Who consented
A stable identifier for the data subject — a user ID, hashed email, or (for anonymous web consent) a pseudonymous consent ID tied to the session.
When they consented
A precise timestamp (ideally UTC) for the moment consent was captured — and a separate timestamp for any later change or withdrawal.
What they were told
The exact consent wording and the version of the privacy notice shown at that moment — not today's version. This is the field most often missing.
How they signalled it
The mechanism and the specific action — which toggles, which button, the workflow used. Silence, pre-ticked boxes, and scrolling never qualify.
What they agreed to
The specific, granular purposes consented to — analytics, marketing, personalization — each recorded separately, because consent must be purpose-specific.
Whether they withdrew
Any later withdrawal or change, timestamped — with a record that the withdrawal was honored and propagated downstream. Withdrawal doesn't erase the history; it adds to it.
It's not enough to log that someone clicked "accept." You must be able to show what they were accepting — the exact banner copy and privacy-notice version live at that timestamp. If your notice has changed six times since, a bare "consented: true" can't prove informed consent. Version your notices and bind each consent event to a version ID.
The anatomy of one consent event
Here's how those fields come together into a single, auditable record — the unit a regulator asks you to produce.
How long to keep consent records
This is the question that trips up nearly everyone, because the intuitive answer is wrong. The GDPR sets no fixed retention period for consent records — instead, the storage-limitation principle applies: keep personal data only as long as necessary. For consent proof, "necessary" resolves to a practical two-part rule:
- For as long as you rely on the consent — i.e. while you're still processing data on that basis. If a cookie or analytics consent underpins ongoing processing, the proof must live at least that long.
- Plus a further period to defend a legal claim — because a data subject or regulator can challenge the processing after it ends. This aligns with the limitation period for claims, which varies by member state (commonly around three years, sometimes up to five for civil claims).
In practice, supervisory authorities generally expect consent records to be available for at least three years, and many organizations retain versioned logs for up to five to cover the civil-claims window. There's also a renewal dimension: the CNIL recommends refreshing cookie consent roughly every 13 months, and the EDPB suggests reviewing other consent types periodically — each refresh generates a new record, so your log grows over time rather than being overwritten.
Over-retention is its own violation. Once the processing has ended and the limitation window has closed, the consent record no longer serves a purpose — and keeping it indefinitely conflicts with data minimization. The defensible posture is a defined retention schedule for consent proof, not "keep everything forever."
Can you see what fires before consent — right now?
The fastest way to find a records gap is to check what your site actually does: scan it free to see every tracker and cookie firing before a visitor consents — the exact thing a regulator or complainant points to first. About 10 seconds, no account needed.
Records after erasure and withdrawal
Two scenarios genuinely confuse teams, and getting them wrong creates risk in both directions.
When consent is withdrawn
Article 7(3) gives data subjects the right to withdraw consent at any time, and it must be as easy to withdraw as it was to give. Crucially for records: withdrawal is not retroactive — it doesn't make the earlier processing unlawful, and it doesn't erase the consent history. You should keep the record that consent existed and add a record that it was withdrawn, with a timestamp and confirmation the withdrawal was honored downstream. That withdrawal log is itself evidence you respected the right.
When the underlying data is erased
Here's the counterintuitive part: the retention clock for consent proof is not the retention clock for the underlying data. The EDPB indicates proof of consent should be kept even after processing ends — for as long as strictly necessary to defend a legal claim — then deleted. So you may erase a customer's personal data on request, yet legitimately retain a minimized record that consent was obtained and later withdrawn, precisely so you can demonstrate you acted lawfully. The consent proof you keep should be data-minimized itself: enough to prove the event, not a copy of everything you deleted.
What auditors and DPAs actually ask for
When a complaint or audit lands, the questions are remarkably consistent — and they're all variations of "produce the record." Being ready for these specific asks is what separates a smooth response from a scramble.
- "Show us consent for this individual." Can you retrieve one person's complete consent history — grants, changes, withdrawals — from a single identifier?
- "What did they see?" Can you reproduce the exact banner wording and privacy-notice version that was live at their consent timestamp?
- "How was consent captured?" Can you show the mechanism and action, and demonstrate it wasn't a pre-ticked box, silence, or a cookie wall?
- "Show granular purposes." Can you prove they consented to these purposes and not others — separately, not bundled?
- "Prove the withdrawal was honored." For anyone who withdrew, can you show when, and that downstream processing actually stopped?
- "Show your retention schedule." Can you explain how long you keep consent proof and why — and show you're not keeping it forever?
- "Demonstrate integrity." Can you show the records weren't altered after the fact — ideally tamper-evident and timestamped?
Notice what unites them: every question is answerable only from a record, never from the banner or the policy. An organization that can answer all seven from a retrievable, versioned, tamper-evident log is in a fundamentally different position from one that says "we've always shown a banner."
Where a CMP fits — and where it fails
A consent management platform (CMP) is the standard way to generate and store these records at scale, and for most sites it's the right tool. But "we use a CMP" is not the same as "we're compliant," and DPOs should probe three specific gaps:
- Does it version the notice? Many CMPs log the click but not the exact copy shown. If it can't bind each event to a notice version, Field 03 is missing.
- Does it prove the record's integrity? A log you could have edited later is weak evidence. Tamper-evident, timestamped records — like an immutable consent log — are far stronger in front of a regulator.
- Does it actually block until consent? This is the one that undoes everything else. If tags fire before the banner is answered, your records prove consent for processing that already happened without it — which is worse than no records, because it documents the violation.
That last point is where consent records meet the technical reality of your site. A record saying "consented at 09:12:04" means little if analytics fired at 09:12:01. This is exactly the gap ConsentPixel — Privacy · Verified is built to close: it blocks third-party trackers until a visitor consents, logs each decision with the notice version as tamper-evident proof, honors withdrawal, and continuously scans what fires — so your records reflect a site that actually waited for the yes. It's a consent-management and detection tool, not legal advice, and not a substitute for your DPO's judgment on retention specifics.
Common consent-record mistakes (and the fines behind them)
The failure modes are consistent, and regulators have acted on them. France's CNIL fined Criteo €40 million in 2023 (Deliberation SAN-2023-001), where the problems included pre-ticked-style consent issues, weak withdrawal mechanisms, and an inability to demonstrate that valid consent had been obtained for all individuals — i.e. incomplete consent records. The recurring mistakes:
- Logging the click but not the context — "consented: true" with no notice version, so you can't prove informed consent.
- Overwriting instead of appending — updating a record on withdrawal so the history disappears, when you need both states.
- Bundled purposes — one "I accept" covering everything, when consent must be granular and separable.
- Records that outlive their purpose — keeping consent proof indefinitely, breaching storage limitation.
- Banner-first, log-never — treating the visible banner as the deliverable and never verifying a retrievable record exists behind it.
- Consent after the fact — tags firing before the choice, so the record documents a violation rather than preventing one.
Key takeaways
- Article 7(1) puts the burden on you — you must be able to demonstrate consent, per individual, on demand. The record is the proof; the banner is just collection.
- Log six things: who, when, what they were told (notice version), how they signalled it, which granular purposes, and any withdrawal.
- The notice snapshot is the field most often missing — bind every consent event to the exact wording and version live at that moment.
- Retention isn't fixed: keep proof while you rely on the consent, plus the limitation period — expect a ~3-year floor, up to ~5 for civil claims — then delete.
- Proof outlives the data: you can erase a customer's data yet keep a minimized record that consent existed and was withdrawn.
- Auditors ask you to "produce the record" seven different ways — versioned, granular, tamper-evident, and retrievable per person.
The bottom line
GDPR consent records requirements come down to a single test a regulator will apply without sympathy: can you produce the record? Everything else — the banner, the preference center, the policy — exists to generate that record and means little without it. Get the six fields right, version your notices, keep proof for the right window (and no longer), and treat withdrawal as an addition to the history rather than an erasure of it.
The organizations that handle a DPA audit calmly aren't the ones with the prettiest banner. They're the ones who, from a single identifier, can show exactly who consented, to what, when, having seen which notice — and prove the record hasn't been touched since. Build for that, and the audit is a retrieval task, not a crisis.
Make your consent records match what your site actually does
Records only hold up if your trackers genuinely wait for consent. Scan any site free to see what fires before opt-in — then close the gap with a pixel that blocks until consent, logs each decision with the notice version as proof, and honors withdrawal.
Scan your site free →ConsentPixel — Privacy · Verified helps controllers and agencies make consent provable — blocking third-party trackers until a visitor genuinely consents, logging each decision with the notice version as tamper-evident evidence, honoring withdrawal, and continuously scanning what fires. This article is general educational information for DPOs and site owners, not legal advice, and retention specifics vary by jurisdiction — confirm yours with qualified counsel. ConsentPixel is not a law firm.
Frequently asked questions
What are the GDPR consent records requirements?
They flow from Article 7(1) GDPR, which states that where processing is based on consent, the controller must be able to demonstrate that the data subject consented. In practice that means keeping a per-individual, retrievable record capturing five to six things: who consented (a stable identifier), when (a precise timestamp), what they were told (the exact consent wording and privacy-notice version shown at that moment), how they signalled agreement (the mechanism and action), which specific purposes they agreed to (granular, not bundled), and whether they later withdrew. The EDPB's Guidelines 05/2020 describe keeping a record of consent statements showing how and when consent was obtained and the information provided at the time. This is general information, not legal advice.
How long do you have to keep GDPR consent records?
GDPR sets no fixed retention period for consent records; the storage-limitation principle applies, so you keep them only as long as necessary. In practice that means two things: for as long as you rely on the consent (while you're still processing data on that basis), plus a further period to defend a potential legal claim, which aligns with the limitation period for claims in your member state — commonly around three years, sometimes up to five for civil claims. Supervisory authorities generally expect consent records to be available for at least three years. You should not keep them indefinitely, as over-retention conflicts with data minimization. Define a retention schedule for consent proof rather than keeping everything forever.
Do I keep consent records after deleting the customer's data?
Often yes — and this surprises people. The retention clock for consent proof is separate from the retention clock for the underlying personal data. The EDPB indicates proof of consent should be kept even after processing ends, for as long as strictly necessary to defend a legal claim, then deleted. So you can honor an erasure request and delete a customer's personal data while legitimately retaining a minimized record that consent was obtained and later withdrawn — precisely so you can demonstrate you acted lawfully if challenged. The retained proof should itself be data-minimized: enough to evidence the consent event, not a copy of the data you erased.
Is a consent banner or CMP enough to prove consent?
No. A working banner or CMP is the collection mechanism, not the proof. Article 7(1) requires you to be able to demonstrate consent for a specific individual, which only a retrievable record can do. When evaluating a CMP, DPOs should check three things it may not do well: whether it versions the notice (binds each consent event to the exact wording shown), whether it produces tamper-evident records whose integrity you can prove, and — most importantly — whether it actually blocks non-essential tags until consent is given. If tags fire before the banner is answered, your records document processing that happened without consent, which is worse than having no records at all.
What do auditors and data protection authorities ask for?
The questions are consistent and all amount to "produce the record." Expect to be asked to: retrieve one named individual's full consent history from a single identifier; reproduce the exact banner wording and notice version live at their consent timestamp; show how consent was captured (and that it wasn't a pre-ticked box, silence, or cookie wall); prove they consented to specific granular purposes rather than a bundled "accept"; demonstrate that any withdrawal was honored and propagated downstream; explain your retention schedule for consent proof; and show the records are tamper-evident and weren't altered after the fact. An organization that can answer all of these from a versioned, retrievable log is in a far stronger position than one relying on the existence of a banner.
Do I need to record when someone withdraws consent?
Yes. Article 7(3) gives data subjects the right to withdraw consent at any time, and withdrawal must be as easy as giving consent was. For records, keep both states: the original record that consent existed, and a new timestamped record that it was withdrawn, with confirmation the withdrawal was honored and downstream processing stopped. Withdrawal is not retroactive — it doesn't make earlier processing unlawful or erase the consent history — so you append to the record rather than overwriting it. That withdrawal log is itself evidence that you respected the data subject's rights, which is exactly what a regulator will want to see.