Storing Consent Proof: Logs, Receipts, and Records That Survive an Audit
Consent proof is boring right up until the day it is the only thing that matters. A regulator asks what a specific person was told in March two years ago, or a customer disputes ever agreeing, and the team discovers the banner has been redesigned four times and the consent tool contract ended last spring.
This guide covers what proof to keep, the difference between vendor logs and your own records, version control for notices and banners, and retention that balances proof against the duty not to keep personal data forever.
A receipt is data, not a screenshot
Screenshots show what a banner looked like generally. A receipt shows what a specific person was offered and chose: the timestamp, the notice version in force, the categories presented, the choice made, and whether it came from a banner, a settings page, or a browser signal. Store that as structured fields in a system you control, because structured records can be searched per person and per period, and survive the departure of any single vendor. If your consent tool is the only place receipts live, the contract with that tool is part of your compliance posture whether you planned it or not.
Version everything the person saw
A choice is only interpretable against the text that produced it. Keep dated versions of your privacy notice, cookie policy, banner wording, and category definitions, and record which versions each receipt references. When wording changes materially, that is both a design event and a records event: old receipts point at the old text, and you should be able to show both. Teams that overwrite policy pages in place lose the ability to prove what anyone agreed to before the edit, which is precisely the period disputes usually cover.
Exports you have actually tested
An export feature nobody has run is a hope, not a control. Test exports on a schedule: pull every receipt for a test identifier, confirm the notice versions resolve, and confirm the file opens without the vendor console. When you change consent tools, migrate receipts with their original timestamps and versions intact, and run the same test against the migrated data before the old contract ends. Migration is also the moment to reconcile duplicates, because the same person often exists in the old and new systems with overlapping histories.
Keep proof, delete data, on purpose
Receipts are personal data too, so they need a retention rule rather than immortality. The usual shape is to keep receipts for as long as the data they justify is processed, plus a defined tail for complaints and audits, then delete or anonymise them and log that deletion. The trap to avoid is the opposite pair: analytics records purged while their receipts were deleted earlier by a different system, or receipts kept forever in an untouched export. One retention schedule, owned by one team, applied across tools, is what makes the proof story hold together.
Related reading
These earlier guides cover connected questions in more depth: Consent and Push Notifications: The Browser Prompt Is Not the Whole Story, Debugging Consent Mode Signals When Numbers Do Not Match, and Cookie Scanner False Positives: A Triage Routine That Keeps Notices Accurate.
Frequently asked questions
What is the minimum a consent receipt should contain?
An identifier for the person or device, the timestamp, what was asked including notice and banner version, the categories offered, the choice made, and how it was made. Anything less becomes hard to interpret later.
Can we rely on our consent vendor to keep records for us?
You can use their storage, but the duty stays yours. Contract for export rights and retention, test the exports, and plan the migration before you need it, because vendors change terms, get acquired, and shut products down.
Should receipts be kept after a customer deletes their account?
Usually yes for a defined tail period, because the receipt is your proof the earlier processing had a basis. It should be minimised, access controlled, and deleted on the schedule your policy states.
How do we handle receipts from before our current system?
Keep them readable. Migrate them with versions and timestamps intact where possible, or archive them in an open format with a note of what each field meant, so a future audit can still use them.