Consent Receipts: What Proof of Consent You Actually Need to Keep
Ask a team to prove a specific visitor consented and the answer is usually a screenshot of the banner and a dashboard graph showing an acceptance rate. Neither proves anything about that visitor. Regulators and complainants ask about one person, one moment, one choice. The artifact that answers them is the consent receipt: a durable record of the interaction, stored where the business controls it, not only inside the tool that collected it.
This guide covers what a receipt needs to contain to be worth anything, the storage mistakes that quietly void it, and a retention rule you can defend. It also covers withdrawal, because a receipt that cannot show the choice was later revoked, and honored, is only half a record.
What belongs in a receipt
Four fields carry the weight. First, an identifier for the visitor that is strong enough to retrieve the record later, usually the consent ID stored in the first party cookie plus any account ID once known. Second, the timestamp and the version of the notice and category list that was displayed, because consent to version three says nothing about version five. Third, the exact state chosen, per category, in the visitor's own action, not an inferred default. Fourth, the method: banner click, settings save, or a renewal prompt. A record missing the notice version is the most common failure; teams log the choice faithfully and the text of what was agreed to not at all.
Where the record should live
Vendor dashboards are a view, not an archive. Platforms purge logs on their own schedules, contracts end, and migrations lose history. Export receipts to storage the business owns, on a schedule, in a format that survives the vendor. That does not require a data warehouse; a daily export to durable storage with the consent ID as the key is enough for most sites. What matters is that you can still produce the record eighteen months from now, after the banner tool has changed twice. Test retrieval the way you would test backups: pick a random consent ID from last quarter and time how long it takes to produce the full receipt.
Retention: as long as the processing, then a margin
Keeping receipts forever is its own problem, since the receipt is personal data too. The workable rule is to retain the receipt while the processing it justified is ongoing, and for a defined margin after it ends or consent is withdrawn, covering the window in which complaints and limitation periods typically run. Write the rule down per category, because analytics consent and marketing consent end at different times. When the margin expires, delete the receipt and log the deletion. A receipt you can show was destroyed on schedule is better evidence of discipline than a warehouse of receipts nobody can explain.
Withdrawal is part of the receipt
The record is not complete at acceptance. When a visitor withdraws, append the withdrawal event to the same receipt: timestamp, method, and the state after withdrawal. Then be able to show the downstream effect, which tools stopped receiving data and when. Audits of withdrawal usually fail in the gap between the two systems: the consent platform recorded the change, but a tag loaded earlier in the session kept firing, or a synced audience list was never refreshed. Keep the receipt and the propagation check together, and the story you tell an auditor is short and consistent.
Related reading
These earlier guides cover connected questions in more depth: Consent Drift: How Quiet Site Changes Break the Banner You Audited Last Quarter, Sampling Consent Records: How to Audit a Week of Choices Without Reading Every Log, and Consent Banners on Small Screens: When Truncated Choices Stop Being Choices.
Frequently asked questions
Is a banner screenshot plus an accept rate enough proof?
No. Those show a banner existed and that visitors generally accepted. They cannot establish what a specific person was shown or chose. A receipt ties the notice version, the per category choice, and the timestamp to one retrievable identifier.
What if our consent platform only keeps logs for 90 days?
Then export on a shorter cycle than the purge window. Most platforms offer scheduled exports or an API. The export target should be storage you control, and someone should verify quarterly that the exports are complete and readable.
Do we need consent receipts for strictly necessary cookies?
Strictly necessary processing does not rest on consent, so it does not need a consent receipt. It does need a documented justification: what the cookie does, why the service fails without it, and why no less intrusive option works. Keep that justification with the same care.
Should the receipt store the visitor's IP address?
Only if you have a reason. An IP can help corroborate a record but it also makes the receipt richer personal data with its own retention questions. Most sites are better served by the consent ID and, once the visitor logs in, the account ID.