Consent records are the least glamorous part of a consent program and the part most likely to be requested by name. Regulators ask for them. Platforms ask during reviews. Visitors exercising their rights ask what was collected under which permission. In each case the question arrives with a deadline, and the answer is whatever your logging quietly did or did not capture months earlier.
Most sites discover their record keeping the hard way: a banner that stored choices in the visitor's own browser and nowhere else, timestamps in three formats, and no way to connect a consent event to the person asking about it.
What belongs in the record
Capture the decision as it was actually presented: the choices per purpose, the timestamp, the version of the banner and policy text the visitor saw, and the mechanism, banner button, settings page, or preference center, that recorded it. Consent given to one text cannot be evidenced by another, so version history of what your banners said is part of the record, not documentation clutter.
Include the identifier the record attaches to, with care. A consent ID stored in the visitor's browser, backed by a server side log, lets you retrieve the event without warehousing unnecessary personal data. Names and account IDs belong in the record for logged in users, where the relationship already exists. For anonymous visitors, the consent ID is the thread, and your support process needs to know how to ask for it.
Server side copies or it did not happen
A choice stored only in a cookie is evidence the visitor controls and routinely deletes. When the question becomes formal, you need your own copy: a server side log written when the choice is made and when it changes. Changes matter as much as the first decision, because consent withdrawn in March says nothing about data collected under February's yes, and both halves may be examined.
Log the downstream events too: when signals were updated, and any sync failures to platforms that hold data under that consent. A record that shows a prompt withdrawal, signals updated the same minute, and platforms notified is a compliance story. A record with the withdrawal and silence after it is an open question with your name on it.
Retention: long enough to matter, not forever
Keep consent records at least as long as the data collected under them is retained and used, plus the window in which questions about that use can arrive. Deleting logs on a tidy annual schedule while the marketing data they authorize lives for five years leaves you holding data you can no longer justify. Retention schedules for logs and data must be designed together.
Indefinite retention is its own problem, since the log is itself stored information about a visitor's behavior and choices. Set a defined period tied to the life of the data and the legal exposure window, automate deletion at the end of it, and document the rule. Auditors are as interested in whether you follow your schedule as in what the schedule says.
Retrieval is a feature, test it like one
A record you cannot find is functionally a record you do not have. Build the lookup before you need it: given a consent ID, an email, or an account, one query returns the full consent history with versions and changes. Then test it with real lookups from your own team, timed. If retrieval takes a developer two days, your process, not your intentions, is what an inquiry will measure.
Extend the test to the awkward cases. The visitor who cleared cookies and has no ID. The customer who consented anonymously and later created an account. The withdrawal made on a phone that never synced. Each case needs a documented answer, because those cases are not edge cases in an inquiry. They are the inquiry.
Related reading
These earlier guides go deeper on connected questions: Consent for Embedded Video: Blocking Third Party Players Until a Visitor Agrees Embedded videos usually load trackers the moment the page renders, long before a consent choice. How to hold third party players until consent, what a click to play placeholder should do, and how to keep the page fast and usable., Consent Logs: What to Keep, What to Record, and How Long to Keep It A consent banner without a log is a claim you cannot prove. What a consent record should contain, how long to retain it, and the storage mistakes that turn logs into liabilities., and Alternatives to Cookiebot A practical guide to evaluating Cookiebot alternatives: what to compare, the honest trade-offs between open-source and enterprise options, and how to switch safely..
Frequently asked questions
What should a consent record contain?
The identifier it applies to, the choices made for each purpose, the timestamp, the version of the banner and policy text shown, and the mechanism that captured the choice. Changes and withdrawals are separate records in the same history, since data collected under an earlier yes may be examined alongside the later no.
How long should consent records be kept?
At least as long as the data collected under that consent is kept and used, plus the period in which questions about it can reasonably arrive. Deleting logs while keeping the data leaves you unable to evidence the permission. Set the period deliberately, tie it to data retention, and automate deletion at its end.
Is storing consent in a cookie enough?
No. A browser cookie is controlled and deletable by the visitor, and it cannot evidence a decision in a formal inquiry. Keep a server side log written when choices are made and changed, keyed by a consent ID, so your organization holds its own retrievable copy of the consent history.
How do we retrieve one visitor's consent record?
By consent ID for anonymous visitors, and by account or email for known customers, through a single lookup that returns choices, versions, timestamps, and changes. Build and test this before it is requested, including the awkward cases like cleared cookies and consent given before an account existed.