Consent Logs: How Long Do I Need to Keep Cookie Consent Records?

«Can you prove that this visitor agreed to the marketing cookie?» When that question arrives — from a supervisory authority, a lawyer or a data subject exercising their access rights — a single document decides your position: the consent log. If you document cookie consents properly, you answer the question in minutes. If you merely run a banner but record nothing, you stand there empty-handed.

The most common follow-up question is: how long do these records need to be kept? The honest answer up front: there is no statutory period. What applies instead, which guardrails determine the retention period, and what a consent log must contain to hold up when it matters — here is the overview.

What is a consent log — and why do you need one?

A consent log is the continuous record of all consents and withdrawals that visitors give through your cookie banner — your evidence for the moment you need to prove consent.

The obligation is spelled out in black and white in the European General Data Protection Regulation (GDPR): under Article 7 paragraph 1, the controller must «be able to demonstrate that the data subject has consented to processing of his or her personal data». Anyone who bases tracking on consent without documenting it violates this duty of proof — regardless of how correctly the banner is designed. Add to that the accountability principle in Article 5 paragraph 2 GDPR: you must not only ensure compliance with the principles, but be able to demonstrate it.

The Swiss Federal Act on Data Protection (FADP), by contrast, contains no explicit consent-log obligation. Concluding that documentation is optional in Switzerland would still be a fallacy: whoever bases data processing on consent bears the burden of proof in a dispute that it was given — that follows from general rules of evidence. Without a record, all you have is an assertion. What else the law requires is summarised in our FADP guide. And as soon as your website addresses visitors from the EU, the GDPR duty of proof applies directly anyway.

What belongs in a consent log?

A robust consent log answers four questions: who consented, when, to what — and on what basis? In concrete terms, five details belong in every entry:

• Timestamp — date and time of the decision, to the second.
• Consent version — which banner text, which purposes and which services applied at the moment of consent? If the banner changes, it must remain traceable what older consents referred to.
• Category selection — what exactly was accepted or declined: everything, statistics only, marketing only? A blanket «agreed» is not enough when the banner offers granular choices.
• Pseudonymised identifier — a random visitor ID or a hashed IP address, so the entry can be attributed to a person. The plain-text IP address has no place in a consent log: it would itself be personal data whose stockpiling creates more risk than benefit — data minimisation applies to evidence too.
• Withdrawals and changes — every later adjustment of the selection as a new entry, so the history remains complete.

A screenshot of the banner replaces none of this: it shows what visitors saw, but not what an individual visitor decided. If you want to document cookie consent, you need the record per decision — the screenshot is merely a sensible attachment.

How long do cookie consents need to be kept?

The short, honest answer: neither the FADP nor the GDPR sets a fixed retention period for consent logs. Anyone selling you «a legally mandated five years» or any other number as an obligation is selling an invention. Instead of a deadline, there are two guardrails from which the duration follows.

Guardrail 1: For as long as the processing relies on the consent. The proof must be available for as long as you rely on the consent — that is, as long as the cookies are being set and the associated data processing is running. Deleting a log while the tracking continues would be contradictory: that is exactly when you need the evidence.

Guardrail 2: For as long as claims can be brought. Even after the processing ends, a data subject can sue or an authority can investigate. The general limitation periods offer orientation: in Switzerland, non-contractual claims become time-barred, depending on the constellation, three years after knowledge and ten years absolutely; in Germany, the standard three-year limitation period is often cited as a reference point. These are orientation values from liability law — not data protection deadlines.

In practice, this usually comes down to keeping records for a few years; common models hold detailed data in direct access for two to three years and archive afterwards. The framing matters: these are practice values derived from limitation periods and proportionality — not legal requirements.

And the opposite direction applies just as much: keeping consent logs forever is not a safety reserve but a problem of its own. The log itself contains personal data, and the principles of proportionality and storage limitation apply to evidence just the same. Anyone hoarding ten-year-old detail logs with no remaining reason for keeping them violates precisely the principles the log is supposed to prove compliance with. The balance: keep detailed data for as long as the retention can be justified, then delete or archive in condensed form — and record the chosen period and its reasoning internally. A documented, reasoned decision convinces an authority more than any blanket number.

Withdrawal and re-consent: what the log must also reflect

A consent log that only knows approvals is half the documentation — just as important is the proof that withdrawals work and were respected.

Article 7 paragraph 3 GDPR requires that withdrawing consent be as easy as giving it. For the log, that means: if a visitor reopens the cookie settings and deactivates a category, a new entry with a timestamp is created. Only the chain «consent on 5 March, withdrawal on 12 June» proves that your system implements withdrawals technically — and from what point on you were no longer allowed to set which cookies.

The second case is re-consent: if you embed new services or extend the purposes — say, an additional marketing tool — the old consent does not cover the new processing. The banner must ask again. For the log, that means two things: the new consent is recorded with the new consent version, and the old entries are kept — they continue to prove that the earlier processing was lawful. Purely cosmetic changes such as colours or a linguistic polish with no substantive effect, by contrast, do not trigger re-consent.

Consent logs in practice: export, archiving, switching providers

Three situations decide whether your consent log really holds up in everyday life: the audit, long-term retention, and switching providers.

Export for audits. Whether it is a data protection authority, an auditor or opposing counsel: if someone demands the proof, you need the logs in a readable format — as a CSV file or report, filtered by period and domain. A log that exists only in the provider's database and cannot be exported is worthless when it counts. Test the export before you need it.

Archiving instead of a data graveyard. On well-visited websites, detail logs quickly grow to hundreds of thousands of entries. For older periods, a condensed form is sufficient: periodic exports plus aggregated statistics, while the detailed data is deleted from the active database. That keeps the system lean and implements storage limitation without giving up the proof.

Switching providers. The most critical moment in the life cycle of a consent log: if you cancel your consent tool, the logs usually disappear along with the account — and with them the proof for the entire period so far. So export all consent logs before you terminate the old contract, and archive the exports internally. What else to watch out for when migrating is covered in our switching guide.

How Aiara keeps the consent log

At Aiara, the consent log is not an add-on module but part of every banner installation — with the points from this article as the default, not an option.

Every visitor decision is recorded server-side: timestamp, selected categories, type of action and the page visited. Aiara never stores the IP address in plain text, but exclusively as a SHA-256 hash with a secret key — the pseudonymised identifier from the chapter above. Withdrawals and changed selections create new entries; the history remains complete.

Retention is handled by automatic archiving: detail entries are transferred into monthly CSV archives after 24 months and additionally preserved as aggregated statistics; after that, they disappear from the active database. The proof is retained without a data graveyard building up. For audits and a possible switch, the same applies: the logs belong to you and can be exported at any time. Which data resides where is documented transparently in the Trust Center.

That turns the retention question into what it should be: a trade-off you make once, with reasons — and which then runs automatically instead of remaining an open flank.