How Long to Keep Consent Records: A Practical Retention Schedule
Teams usually ask two opposite questions about consent records. Legal worries about deleting proof too early, and privacy teams worry about keeping personal data forever. Both worries are valid, and the way through them is a written retention schedule that ties each receipt to the data it covers instead of a single blanket period for everything.
This guide sets out how to build that schedule: what a receipt contains, which clocks should drive retention, how to handle receipts for people who never became customers, and how deletion should work so the schedule is real rather than aspirational.
Tie retention to the data, not the calendar alone
A consent receipt exists to prove the basis for processing specific data. While that data is still being processed, the receipt clearly needs to survive. Once the underlying data is deleted, the receipt enters a tail period whose job is only to answer complaints or audits about past processing. Schedules that ignore this link produce two failure modes: receipts deleted while the marketing data they justify is still in use, and receipts for long deleted data kept for a decade because nobody wrote a rule for them. Map each receipt type to its data type first.
Set the tail period from real risk
The tail should reflect how long a person or regulator can plausibly question the processing. That usually means looking at complaint patterns, contract terms, and limitation periods in your main markets, then picking a defensible period and writing down the reasoning. A few years after processing ends is a common shape, but the number matters less than the justification and consistent application. Inconsistent retention, where old receipts survive randomly in backups and exports, is harder to defend than a shorter period applied evenly.
Prospects and short lived receipts
Receipts from people who never converted pile up quietly: contest entries, newsletter signups who never confirmed, and banner interactions from one visit. These deserve shorter schedules than customer receipts, because the processing itself was brief and the relationship ended. Set a specific period for unconfirmed and one time interaction receipts, and automate their deletion. The same applies to receipts superseded by a newer choice. The newer receipt becomes the operative record, and the older one only needs to cover the processing done under it.
Make deletion provable
A schedule that lives in a policy document but not in your systems will drift. Build deletion into the same jobs that purge the underlying data, log what was deleted and when, and keep that log itself free of the personal data it describes. Backups need a rule too: receipts in backups expire when the backup rotates, and a restore should reapply pending deletions. Review the schedule once a year alongside your records of processing, and adjust it when products, markets, or complaint patterns change.
Related reading
These earlier guides cover connected questions in more depth: Consent in Connected TV Apps: Choices on the Big Screen, Consent Audit Trails: Exporting Records a Regulator Can Actually Read, and Consent Renewal Prompts: When to Re-Ask and When to Leave People Alone.
Frequently asked questions
Can we keep consent receipts indefinitely just in case?
Indefinite retention conflicts with storage limitation principles and creates its own risk in a breach. A defined period tied to processing plus a justified tail is easier to defend than keeping everything forever.
What if a user asks us to delete their consent receipt?
Deleting the receipt while you still process their data removes your proof, so most teams stop the processing, delete the data, and then handle the receipt under the schedule, explaining that sequence to the user.
Do we need receipts for rejected consent too?
Yes. A record that someone said no, and that you honoured it, is valuable proof. Keep rejection receipts on the same schedule as acceptance receipts for the same data type.
Who owns the retention schedule?
Privacy or legal usually drafts it, but engineering and data teams own its execution. A schedule nobody has implemented is a liability, so assign each rule to a system and an owner.