Home / Blog / Consent record retention: how long to keep proof of consent, and how to honor deletion requests

Consent record retention: how long to keep proof of consent, and how to honor deletion requests

Published 2026-10-11

Every consent banner quietly builds a database: millions of rows recording who clicked what, when, and on which version of your notice. Regulators love this database, because it is the proof that consent was real. Privacy teams fear it, because it is also a trove of personal data with its own retention problem. Keeping consent records forever feels safe until a deletion request forces you to explain why you still hold data about someone who asked to be forgotten.

Why retention schedules matter for consent proof

A consent record is evidence, and evidence has a shelf life tied to its purpose. You keep the record to prove, if challenged, that a specific visitor consented to specific processing at a specific time. That purpose lasts as long as the underlying processing could plausibly be questioned, which in practice means the statute of limitations for the relevant regulation plus a safety margin. For most sites that lands somewhere between three and seven years, not forever.

The mistake is treating the consent database like application logs that roll over every 90 days, or like a data warehouse that keeps everything indefinitely. Too short, and you cannot prove consent when a complaint arrives two years later. Too long, and every deletion request becomes a negotiation about why you are still holding data the person wants gone. A written retention schedule, decided in advance and applied automatically, removes the argument from both directions.

What to store, and what to stop storing

A defensible consent record is small: a pseudonymous identifier, the timestamp, the exact choice per purpose, the version of the notice shown, and the consent string or signal transmitted to vendors. That is enough to reconstruct what happened. What you do not need is the full browsing session, the IP address in cleartext, or the device fingerprint attached to the same row. The leaner the record, the easier it is to defend keeping it, and the easier it is to delete on request.

Pseudonymization is the practical middle ground. Store a hashed identifier instead of a raw cookie ID, keep the mapping table under stricter access controls with a shorter retention of its own, and document the separation. When a deletion request arrives, you can delete the mapping and render the consent record anonymous rather than destroying evidence you may still need. Regulators accept this pattern when it is documented; they do not accept "we kept everything because storage is cheap."

Handling deletion requests against the consent database

Deletion requests create a genuine tension: the person wants their data gone, and you may need the record to prove you handled their data lawfully. The way out is sequencing. First, stop all processing based on the old consent and suppress the identifier across your vendors. Second, delete or anonymize the linkable identifiers. Third, retain only the minimum evidentiary stub, a timestamped record that a choice was made and later withdrawn, without identifiers that tie it to the person. Document each step with its own timestamp.

The edge case teams miss is the backup. If your consent records live in backups with a 90-day rotation, the deletion request is not complete until the backup cycle has rolled past the old data, and you need to say so in your response. "Deleted from production immediately, purged from backups within 90 days" is an honest answer that regulators respect. Promising instant deletion everywhere is a promise your infrastructure cannot keep.

A retention checklist you can adopt this week

Write down the schedule: consent records retained for a fixed period tied to your limitation window, identifier mappings retained for a shorter period, backups on a defined rotation. Apply it with automation, not calendar reminders, because manual deletion never happens. Review it annually alongside your data map, since new vendors and new purposes change what "minimum necessary" means. And keep the schedule itself as a record: when an auditor asks why you kept a consent record for five years, "here is the policy we followed" is the entire answer.

Get a free consent audit of your website

Free consent audit

Frequently asked questions

How do you prove a consent choice was actually honored?

By joining the record to behavior: the stored choice with its timestamp and banner version, plus evidence that tags and cookies matched that choice afterward. A consent log on its own shows what was clicked. The honoring is shown by scans and tag audits run against real choices, which is why both halves belong in the same audit file.

What should a consent monitoring routine include each month?

A site scan compared against the declared cookie list, a decline test in a clean profile, a sample pull of recent consent records, and a review of any new tools or tags added since the last check. Four items, under an hour on a tidy site, and the routine catches drift while it is still a settings fix rather than a disclosure problem.

Why do consent problems usually trace back to change, not setup?

Because most banners are configured correctly once, at launch, and then the site changes around them: new tags, new pages, new vendors. Nothing announces that the consent setup has gone stale. Monitoring exists to notice the divergence between the site as configured and the site as it actually behaves today.