# Consent Renewal: How Often to Re-Ask, and What Resets the Clock

Source: https://cookierampart.com/blog/2026-11-06-consent-renewal-intervals.html

[Home](../index.md) / [Blog](index.md) / Consent Renewal: How Often to Re-Ask, and What Resets the Clock


Published 2026-11-06

A visitor consented in January. It is November, the banner has not reappeared, and the site is still processing their data under a choice made ten months ago. Is that consent still valid. The honest answer is that it depends on what changed since January, and most sites have no idea what changed, because nobody wrote it down. Consent renewal is not a calendar problem. It is a change problem, and the clock resets on changes, not on dates.

The GDPR does not set a single expiry period for consent. What it does set is a standard: consent must be specific and informed, which means it covers the purposes, vendors, and data uses the visitor was told about when they agreed. Change any of those and the old consent no longer covers the new processing. The renewal question is really a record-keeping question: what did the visitor agree to, and is that still what you are doing.

## The three resets

Purposes change. A site that adds a new advertising purpose, or starts sharing data with a new category of partner, needs fresh consent for the new processing. TCF 2.2 tightened the withdrawal rules alongside this: withdrawing consent must be as easy as giving it, and a consent record that cannot show what the visitor agreed to cannot show whether a new purpose is covered. If your consent log records the choice but not the banner version and the purposes list, you cannot answer the renewal question at all.

Vendors change. A new vendor on the TCF list, a new subprocessor at the CMP, or a new analytics tool all change who processes the data. The vendor change that matters most is the one the visitor never sees: a CMP that silently adds vendors to the list while the stored consent string stays the same. Check the vendor count on the first layer of the banner against the count from the last time you looked. If it grew, the consent underneath it is stale.

The law changes. TCF v2.2 removed legitimate interest for advertising purposes, v2.3 became mandatory for new strings in February 2026, and v2.4 followed in October. Each version change is a reason to re-check what your CMP writes, and a major version change is a reason to re-ask, because the string the visitor agreed to is no longer the string the system produces.

## What interval to actually use

Most practitioners re-ask every 6 to 12 months, and the regulators who have opined on the question cluster in the same band. The CNIL, the French authority, has treated 6 months as the reference period for consent validity in its guidance on cookies, and several other authorities use 12 months as the outer bound. Neither number is in the GDPR itself, which is why the interval is a risk decision, not a compliance fact. A site with sensitive data or a high complaint volume should sit at the short end. A site with stable purposes and vendors can sit at the long end.

The interval has to be a setting, not a habit. Set the consent cookie expiry to match the renewal period, so the banner reappears on schedule without anyone remembering to do it. And set a separate, shorter interval for the consent record review: every quarter, check that the stored choices still match the current purposes and vendor list. A banner that reappears on schedule but re-asks the same stale purposes is theater.

## The record that makes renewal defensible

Keep four things with every consent record: the choice per purpose and vendor, the version of the banner and privacy notice shown, the timestamp, and a pseudonymous identifier. That is the minimum that lets you answer a complaint, and it is the minimum that lets you decide whether a renewal is needed. A log that records the choice but not the banner version cannot show what the visitor agreed to, and a renewal decision made without that information is a guess.

And record the renewal itself. When the banner reappears and the visitor chooses again, the new record supersedes the old one, and the old one should be kept, not deleted, because the history is the evidence that consent was maintained rather than assumed. A consent history with gaps is a consent history with questions, and the questions arrive at the worst time.

Keep reading: [Your Banner Keeps Coming Back Because the Consent Cookie Died](2026-11-05-consent-cookie-expiry-scope.md), [Server Side Tagging Hides Cookies From Your Own Scan](2026-11-05-server-side-tagging-consent-gap.md), and [The Reject Button Audit: Placement, Wording, and Colour Traps That Fail Review](2026-11-04-reject-button-placement-audit.md) cover the nearby cases in this series.

## Frequently asked questions

### How long does cookie consent last?

The GDPR sets no single expiry period. Most practitioners re-ask every 6 to 12 months, with the CNIL treating 6 months as a reference period. The interval is a risk decision based on how often your purposes and vendors change.

### What resets the consent clock?

Three things: a new purpose, a new vendor or subprocessor, or a major framework change like a TCF version move. Any of them means the old consent no longer covers the current processing, and fresh consent is needed.

### Does changing vendors require re-asking for consent?

It can. If a new vendor processes data the visitor did not agree to share with, the old consent does not cover it. Check the vendor count on the banner against the last review, and re-ask if it grew.

### What should a consent record contain for renewal decisions?

The choice per purpose and vendor, the banner and privacy notice version shown, the timestamp, and a pseudonymous identifier. Without the banner version, you cannot tell what the visitor actually agreed to.