How Long to Keep Consent Logs: Retention That Survives the Data It Covers
Audits of consent rarely start with the banner. They start with a sample. An auditor, a regulator, or a customer's privacy team picks a set of records and asks the only question that matters: show me what this person agreed to, and show me it has not changed since.
Most teams can produce the first half from the consent platform and then stall on the second. The notice was edited in the CMS. The banner template was updated by the vendor. The purpose list grew a new entry in March. Which version did a February user see? The trail answers that, if it was ever built.
Connected TV apps gather viewing history, device identifiers, and household level advertising data, usually under one account holder's agreement on a shared screen. A defensible flow separates the account holder's choices from household viewing, records which profile consented to what, and makes advertising data controls reachable with a remote, not buried behind a phone app.
Consent logs should be kept for as long as the data collected under that consent is held and used, plus the period in which a complaint, claim, or audit about that processing could realistically arrive. A fixed short retention that deletes the proof while the data lives on is the common failure; the log's retention follows the processing it evidences.
The proof has to outlive the processing
The logic is direct. While you hold and use data on the basis of consent, you may be asked to show that consent existed and what it covered. If the log rotated out after twelve months and the audience built on it is still being mailed in month eighteen, the position is unprovable by design. Nobody made a dramatic error; a default retention setting made it quietly, which is how most of these gaps form.
The opposite failure is real too. Consent logs contain identifiers, timestamps, and choice histories. Keeping every log forever, unreviewed, in a platform nobody audits, turns the evidence store into its own liability. Retention needs an end tied to the end of processing and the relevant claim windows, not infinity.
Setting the schedule per record type
Start from the processing inventory: for each purpose, when does the data actually get deleted or anonymised in normal operations? The consent log for that purpose should persist at least that long, plus a margin for requests and complaints arriving after deletion. Different purposes will land on different periods, which is correct; a single platform wide number is usually a sign nobody did this mapping.
Include the awkward records. Withdrawn consents need retention too, because the withdrawal record is what proves you stopped, and honoured opt outs have to persist as suppression data or the person gets re-added by the next import. Deleting an opt out record entirely is how suppressed people reappear in campaigns.
Reviewing retention like the rest of the record
Put consent log retention in the same review cycle as the processing inventory: annually, and whenever a purpose ends or a platform changes. When a purpose is retired, its logs enter their end of life count instead of being forgotten in place. When a platform migration happens, retention settings are part of what gets verified in the new system, not assumed to have carried over.
Document the schedule and the reasoning in the privacy record. A retention period with a written rationale tied to processing lifetimes reads as governance. The same period with no rationale reads as a default nobody chose, because it usually was.
Keep reading: Consent for Connected TV Apps: The Living Room Screen Nobody Audits, Reject All Parity: When the Decline Button Is Harder to Find Than Accept, and Proving Consent in an Audit: The Trail Behind the Banner, Field by Field cover the nearby cases in this series.
Frequently asked questions
Is there a standard number of years for consent log retention?
No universal figure. It follows how long the underlying data is held and used, plus the window for complaints and claims in your jurisdictions. Anyone selling a single standard number is selling a default, not an analysis.
Should withdrawn consent records be deleted?
The record of withdrawal should be kept, and the opt out itself must persist as suppression so the person is not re-added. What changes after withdrawal is the processing, which stops; the evidence that it stopped is exactly what the record provides.
What happens when we migrate consent platforms?
Export the logs with their retention logic, verify the import preserves timestamps and change history, and keep the old export for the remainder of its retention period. Migrations are where retention quietly resets to a new vendor default.
Can consent logs be anonymised instead of deleted?
Partially, once the period where an individual record might be requested has passed. Aggregate statistics about consent rates do not need identifiers. Timing that transition is a documented decision, not a storage cleanup.