When to Ask Again: Setting a Consent Refresh Cadence
Teams ask how long consent lasts as if a regulator published a number. A few authorities have suggested timeframes, six months appears in some guidance, but there is no universal expiry date printed in the major laws. What exists is a principle: consent should reflect a current choice, and a choice made years ago about vendors who have since changed is hard to call current.
The practical answer is to build the cadence out of your own facts. Your stack sets identifiers with specific lifetimes and changes vendors on a specific schedule. The refresh rule should be derived from those, written down, and enforced by the consent tool rather than remembered by a person.
The three clocks
Clock one is identifier lifetime. If your longest analytics or personalization cookie lives thirteen months, a consent that is never renewed inside that window stops describing reality. Renew at or before the longest lifetime you actually set, and consider shortening lifetimes instead of lengthening the argument.
Clock two is a ceiling you choose, six to twelve months is the defensible band for consent based processing in most programs. Clock three is events, not time: a new purpose, a new category of vendor, or a notice version change that alters processing. Event based refresh is non-negotiable, because old consent cannot cover a purpose that did not exist when it was given.
How to re-ask without training people to click anything
A renewal banner that interrupts like the first one teaches visitors that banners are obstacles, and reflexive acceptance is bad evidence of choice. Some programs surface renewal inside the preference center with a notice on the next visit, keeping both choices equally easy while lowering the pressure. The legal test stays the same: the refreshed choice must be as free as the first.
Never let renewal silently reset a refusal. A user who rejected and is re-asked must be rejecting or accepting from the same record, and if they ignore the prompt, the previous refusal stands. Tools that treat non-response at renewal as a fresh slate are manufacturing consent.
Prove the cadence runs
Keep a renewal log: who was re-asked, when, which clock triggered it, and what they chose. Programs fail reviews less on the cadence they chose than on the absence of any evidence the cadence operated. A quarterly sample check, ten users, reconstruct their consent timeline, catches drift between policy and tool configuration while it is still cheap to fix.
Related reading
These earlier guides cover connected questions in more depth: Auditing Tag Manager Consent Defaults: Where the Leaks Actually Are, When to Ask Again: Setting a Consent Refresh Cadence, and Consent Logs in a Data Breach: What Your Banner Records Expose.
Frequently asked questions
Is six months a legal requirement for consent renewal?
Not as a universal rule. Some national guidance uses six months as a reference point, and several regulators expect renewal within six to twelve months. Treat it as a strong convention to justify departing from, not a statute to cite.
What happens to data collected under expired consent?
Stop the processing that depended on it and re-ask. Data already collected is usually kept or deleted under your retention schedule and the law's storage limits, but continuing to use it for the consented purpose after expiry is where programs get into trouble.
Should logged-in users renew on the same cadence?
Yes, and it is easier for them: account level consent can be timestamped, versioned, and surfaced in settings. Authenticated consent is usually better evidence than an anonymous banner event, so use the account record as the source of truth.
Does a notice update always force re-consent?
Only material changes do: new purposes, new sharing, longer retention. Clarifications and typo level edits need a changelog entry, not a new ask. Document the materiality call for each version.