Proving consent: what a regulator actually asks for, and how to log it

Short answer: a consent record is only worth something if it captures five things — who consented, when, what they were told at the time, how they consented, and whether they've since withdrawn. That list is the ICO's, from How should we obtain, record and manage consent? (checked 30 July 2026). A standard cookie-banner log gives you three of them cleanly, fudges the fourth and rarely holds the fifth. Keep the record for as long as you're still relying on that consent, download it on a schedule instead of trusting your vendor's retention window, and download it again before you switch CMP: Cookiebot's terms delete each consent from its log after 12 months, and delete the whole log immediately if you cancel the account.

This is not legal advice. The ICO finalised its storage and access technologies guidance in April 2026 after two consultations, so the regulator's position on records is current rather than in flux — but PECR enforcement against tracking is still developing, and nothing below substitutes for your own legal read.

A consent record has five parts, and a cookie banner log gives you three

Article 7(1) of the UK GDPR says the controller "shall be able to demonstrate that the data subject has consented". The ICO translates that into an audit trail with five elements: who consented (a name or other identifier, including an online username or session ID), when, what they were told at the time, how they consented, and whether they have withdrawn consent and when.

Two of those are where cookie consent logs get thin.

The ICO is explicit that "consent should be specific and granular, so your records also need to be specific and granular". A row that says a visitor accepted "marketing" in April tells you nothing about which eleven vendors were on the banner in April.

Keeping the record is a different question from how long consent lasts

The ICO's rule for retention is short: keep the evidence "for as long as you are still processing based on the consent". There is no fixed period, because the period is set by your own processing, not by a calendar.

Your CMP's retention is set by its contract. Cookiebot's terms of service state that a consent is automatically deleted from its log after 12 months, after which it survives only in aggregated statistics (clause 2.2.8, checked 30 July 2026). The same terms say that when you cancel your account, your data — account information, invoices, scan reports and collected user consents — "will immediately be permanently deleted without further warning or any option to restore" (clause 5.3).

So if a complaint lands 14 months after the consent that matters, the log that would have answered it is gone, unless somebody downloaded it. Cookiebot's manager exports the log as CSV, per domain and per date range. Put that download in a quarterly calendar reminder and store it wherever you keep your other accountability records.

Three things trigger re-consent, and only one of them is a clock

The mandatory trigger is a change of purpose. The ICO is unambiguous: if you introduce new tags or cookies for a purpose different from the one you stated when consent was granted, you must obtain fresh consent. Adding a new third party counts — its worked example is a site that adds a social media plugin and correctly decides the old consent doesn't cover it.

The second trigger is a refusal. Neither PECR nor the UK GDPR sets a time limit on consent, and the ICO says you should not repeatedly prompt people as a matter of course, "particularly … when someone has refused consent". Its recommendation is to wait a reasonable period, and it gives six months as a suitable timeframe before asking someone again.

The third is your own review cycle. In the UK GDPR consent guidance the ICO suggests considering an automatic refresh "every two years", while noting you may be able to justify longer. Those two numbers answer different questions — six months before you re-ask someone who declined, two years as a general refresh interval — and neither is a statutory deadline.

What is not a trigger: the expiry of your preference cookie. Cookiebot's CookieConsent cookie stores the consent state for up to 12 months; OneTrust documents OptanonConsent at 365 days. The ICO's position on those defaults is that you must assess whether the default interval is right for your circumstances, change it if it isn't, and document the decision. A cookie expiring means a visitor gets asked again. It doesn't mean the original consent stopped being valid on that date, and it doesn't delete your obligation to still hold the record.

Google turns proof of consent into a contract term, including for UK traffic

Most write-ups treat consent records as a regulator problem. If you run Google Ads, they're also a supplier problem. Google's EU user consent policy requires anyone using its advertising products with end users in the EEA, the UK and Switzerland to "retain records of consent given by end users" and to give users clear instructions for revoking it. The sanction is not a fine: Google says it may limit or suspend your use of the product, or terminate the agreement.

Google's help page puts a floor under what those records contain: "at a minimum, these should include the text and choices presented to users as part of a consent mechanism and a record of the date and time of the user's affirmative consent" (checked 30 July 2026). That is the ICO's "what they were told at the time", restated by a commercial partner who can switch your ads off.

The detail worth pinning on the wall if you're a UK advertiser: the same help page says Google has no expectation that advertisers send a verified consent signal for UK or Swiss traffic — the requirement to send verified signals applies to EEA traffic. The record-keeping duty in the policy has no such carve-out. You can be outside the signalling requirement and still inside the retention requirement.

Logging without a backend works, as long as you know which field is missing

You don't need a database to keep proof of consent. Two mechanisms already do it, and each drops something.

The CMP's own log. Cookiebot records the consent state with a random encrypted key, a timestamp, the user agent, the URL the consent came from, and — per its logging article — the visitor's IP with the last bits removed. Its newer data-processing article lists only the URL, user agent and consent state for the same step. Both pages were live on 30 July 2026; they don't quite agree, which is a fair thing to raise with any vendor before you rely on a field being there. Retrieval is the part people miss: to prove one specific visitor's consent, that visitor has to hand you the key from their browser, and you look it up. The banner wording they saw comes from the dated scan report, not the log row.

The TC String, if you're on the IAB framework. It's a self-describing record living in the visitor's browser: which CMP wrote it (CmpId, CmpVersion), which screen consent was given on (ConsentScreen), the language the interface was in, and which Global Vendor List and TCF policy version were in force. That last field is the closest thing to "what they were told", because it pins the vendor list. The catch is in the spec: since the December 2021 change, Created and LastUpdated hold the same day-level value, so the string tells you when the choice was last updated, never when it was first given.

Both mechanisms live partly in the visitor's browser, and browsers get cleared. Cookiebot's FAQ argues that a user who can't produce the cookie can't prove they visited, so "there is no case". Treat that as a vendor's reasoning, not a regulator's — the ICO's burden sits on you to demonstrate the consent, and your server-side export is what does that.

Consent records don't follow you to a new CMP, and the reasons are boring

The migration trap has two halves, and one of them is worse than it looks.

The visitor half: every CMP reads its own storage key and nobody else's. Cookiebot writes CookieConsent, OneTrust writes OptanonConsent and OptanonAlertBoxClosed, Sourcepoint writes a _sp_user_consent_ local-storage entry per property. Swap vendors and every returning visitor is a stranger to the new banner, so they all get prompted again. Budget for that: your consent rate for the following weeks is measuring a re-prompt, not a change in visitor behaviour, and comparing it to last month's rate will mislead whoever reads the report.

The archive half: your historical records sit in the old vendor's system under the old vendor's terms. Cookiebot deletes them the moment you cancel. Export before you cancel, not after.

One correction to the received wisdom, because we found it while checking this piece. It is often said flatly that consent records can't be imported into another platform. That's true of anonymous banner consents — there's no shared identifier to import them against — but not of consent generally. OneTrust publishes bulk import templates for consent records, including a "Create Historic Data Subject Consents" template for past events (checked 30 July 2026). Those work on identity-linked consent, the kind keyed to an email address in a preference centre. If your consents are attached to accounts, ask about import. If they're cookie-banner consents, take the export and treat it as a closed archive.

Four things to do before anyone asks you for proof

1. Download your consent log now, then quarterly. Check it holds a timestamp, a per-purpose state and an identifier you could actually look up.
2. Version your banner. Keep a dated copy of the wording, the vendor list and the privacy information each time either changes. That is the element the log doesn't carry, and it's the one Google names explicitly.
3. Write down your expiry decision. Whatever your preference cookie's lifetime is, record why you chose it and when you last reviewed it.
4. Export before you migrate. Anything left in the old account goes when the account goes.

The uncomfortable part of this topic is that a good record can prove the wrong thing. If your tags fire before the banner is answered, a tidy consent log documents exactly when each visitor's choice was ignored — which is the pattern behind most of the enforcement risk described in what the £17.5m PECR ceiling changed, and the reason consent-or-pay models get scrutinised on the mechanics rather than the wording. Fix the enforcement first, then the paperwork proves something worth proving. That's the job in our Consent Mode v2 work.

Sources

1. 1.ICO — How should we obtain, record and manage consent? · Checked 2026-07-30
2. 2.ICO — Guidance on the use of storage and access technologies: How do we manage consent in practice? · Checked 2026-07-30
3. 3.ICO — Guidance on the use of storage and access technologies: About this guidance (April 2026 update) · Checked 2026-07-30
4. 4.Google — EU user consent policy · Checked 2026-07-30
5. 5.Google — Help with the EU user consent policy · Checked 2026-07-30
6. 6.Cookiebot — Logging and demonstration of user consents · Checked 2026-07-30
7. 7.Cookiebot — Data processed when using Cookiebot CMP · Checked 2026-07-30
8. 8.Cookiebot — Terms of Service (clauses 2.2.8 and 5.3) · Checked 2026-07-30
9. 9.IAB Tech Lab — TCF v2 consent string and vendor list formats · Checked 2026-07-30
10. 10.OneTrust — Bulk Importing Consent Records · Checked 2026-07-30
11. 11.OneTrust — Cookie Notice (OptanonConsent lifespan) · Checked 2026-07-30
12. 12.Sourcepoint — Cookies and local storage (Web) · Checked 2026-07-30