Consent Receipts: The Six Fields That Make a Yes Provable Later
Somewhere in your database there is probably a row that says consent: true, with a timestamp. That row feels like evidence. Put it in front of a regulator, or a judge, or an angry customer with a screenshot of a different banner than the one you run now, and it turns into a claim you cannot support.
The burden sits with the controller. Under GDPR Article 7, the organisation relying on consent has to be able to demonstrate that the person gave it. Demonstrate is a records problem, not a design problem, and the receipt is where most consent programmes are thinnest, because the banner got the budget and the log got whatever the default settings kept.
Field by field: what the receipt holds
Identity first, at the level the service actually has. For an account holder that is the account ID. For an anonymous visitor it is the consent identifier stored on the device, which means the receipt only works while that identifier survives, and the limits of that should be admitted rather than papered over. Next, the timestamp, in a form that cannot drift: UTC, with the local offset the user saw if the notice made time sensitive promises.
Then the two fields teams most often skip. The notice version: which text, in which language, attached to which banner configuration. And the purpose list as it stood at that moment, purpose by purpose, with the state of each one. Purposes added later do not inherit an old yes, and a receipt that cannot show the original list cannot prove they did not.
The interface is evidence too
How the choice was presented changes whether it was valid, so the receipt, or the audit file behind it, should be able to reconstruct the interface: banner version, button labels, whether reject sat on the first layer, whether any purpose arrived pre ticked. Vendors rotate templates silently. If your receipt points at a configuration that the vendor has since overwritten, your proof has a hole in it that only appears when someone asks.
Keep a dated copy of the notice text and a screenshot or build reference for each banner version you ship. Storage is cheap. Reconstructing a retired template from a vendor support ticket, eighteen months after the fact, is not.
Withdrawal belongs in the same ledger
A receipt system that logs grants and hides withdrawals is worse than an incomplete one, because it misrepresents the current state. Withdrawal should append an event with its own timestamp and channel: settings page, email link, account control, Global Privacy Control signal where you honour it. The original grant stays in the record. Deleting it would destroy the history that shows processing between grant and withdrawal was based on a consent that existed then.
Retention cuts the other way as well. Keep receipts while the processing they justify continues, and for a defensible period after it ends, because complaints arrive late. Keeping them forever, attached to a marketing profile you also kept forever, turns a compliance record into a liability of its own. Name the period. Tie it to the limitation periods you actually face.
Related reading
These earlier guides cover connected questions in more depth: Age Gates and Children's Data: Where a Birthday Box Stops Being Consent, Privacy Notice Version Control: Why Editing in Place Breaks Your Proof, and Audit-Ready Consent Records: The Fields a Regulator Actually Asks For.
Frequently asked questions
Is a timestamp and an IP address enough to prove consent?
Usually not on their own. An IP address identifies a connection, often a shared one, and a timestamp says nothing about what was agreed to. Without the notice version and the purpose states, the record cannot show the content of the consent.
Do consent receipts need to be given to the user?
Some frameworks and standards treat a user facing receipt as good practice, and account based services can show consent history in the privacy dashboard. What is mandatory in most regimes is that the controller can demonstrate consent on demand, to the person or to a regulator.
What happens when purposes change after consent was stored?
New or materially changed purposes need a fresh consent. The old receipt covers the purposes in the version the person accepted, which is exactly why the receipt has to preserve that list rather than pointing at the current one.
How long should consent records be kept?
At least while the processing based on that consent continues, plus a period matched to complaint and limitation windows in the jurisdictions you operate in. The period should be written down in a retention schedule, not left to database defaults.