Consent records: the logging nobody does until the regulator asks

Under GDPR, consent is not valid unless you can demonstrate it. That means every consent choice needs a record: who consented, when, to what, and how. Most cookie banners collect the choice and log nothing, which means the business has a banner but no proof. When a regulator or a complainant asks, "show me the consent," silence is the answer that gets fined.

What a defensible record contains

A consent record needs six elements to hold up. The timestamp of the choice. The exact purposes consented to, in the wording the visitor saw, not a vague "accepted all." The version of the privacy notice and banner text in force at the time. The method of collection, such as banner click, preference center, or API. An identifier linking the record to the visitor, usually a pseudonymous consent ID rather than personal data. And a record of any later withdrawal or change, linked to the original.

The notice version is the one everyone forgets. If your banner text changed in March and the complaint concerns February, you need to show what the visitor actually saw. Version your consent strings and keep the old ones. Storage is cheap; reconstruction is impossible.

Where the records live

There are two sane architectures. The consent management platform stores the records server-side and exposes them per visitor, which is the default for most CMPs and the easiest to defend. Or the business logs consent events into its own systems, which gives more control but means owning the security, retention, and subject-access handling yourself.

What does not work: storing the only copy in the visitor's browser. A cookie on the user's device is not a record you can produce. It is a convenience for the return visit. If your entire consent evidence disappears when the visitor clears cookies, you have no evidence.

The withdrawal problem

Consent must be as easy to withdraw as it was to give, and the withdrawal has to be recorded with the same care as the grant. The failure mode is familiar: the banner offered "accept," the preference center buried "reject" three clicks deep, and withdrawals were never logged at all. Then the data kept flowing after the visitor opted out, and the logs cannot show otherwise.

Log every state change as an immutable event: granted, withdrawn, modified, with timestamps. Never overwrite the history. An auditor who sees a single "current status" field with no history will assume the worst, because from their perspective there is no evidence anything else happened.

Retention and the records paradox

Keep consent records as long as the processing they authorize continues, plus the limitation period for claims in your jurisdiction. For most businesses that means years, not months. This creates the paradox everyone asks about: you are storing data about people who told you not to process their data.

The resolution is purpose limitation. Consent records are processed for the legal obligation to demonstrate compliance, not for marketing, and they should be segregated accordingly: separate storage, separate access controls, no joining to analytics. A consent log that feeds your ad targeting is a violation wearing a compliance costume.

The 30-minute test

Pick a random visitor identifier from last month and try to reconstruct their full consent history: what they saw, what they chose, when, and what changed since. If you can do it in 30 minutes, your records work. If you cannot, neither can you when the regulator asks. Fix the logging before you need it, because by the time you need it, it is too late to create it.