A question we get often enough to be worth its own answer: once a visitor accepts or rejects cookies, how long does that choice stay valid? The honest answer is that there's no single universal legal deadline written into GDPR itself — but there is a widely cited, commonly implemented guideline of roughly 12 months, and it's worth understanding where that number comes from rather than just taking it on faith.
Where the 12-month figure actually comes from
GDPR and the ePrivacy Directive don't specify an exact expiry period for cookie consent. What they do require is that consent remain genuinely informed and specific — which implies it can't be treated as valid indefinitely, since circumstances (what a site tracks, who it shares data with, what the vendor landscape looks like) change over time.
CNIL (France's DPA) has published some of the most specific guidance on this point among EU regulators, explicitly recommending a maximum validity period of 6 months in earlier guidance, which most of the industry's CMP vendors and consent frameworks subsequently converged around roughly 12 months as the more commonly adopted practical standard — treating it as a reasonable outer bound rather than a strict legal mandate. Other DPAs have given similar, non-identical guidance, generally landing somewhere in the 6–13 month range depending on jurisdiction. The UK's ICO points to a similar approximate window. There's no single number that's legally binding across every EU member state — which is exactly why most CMPs default to roughly 12 months as a reasonable, broadly defensible middle ground rather than optimizing for one specific DPA's published figure.
Why reconsent matters beyond just the clock running out
The time-based trigger is the most commonly implemented one, but it's not the only reason to re-prompt:
- A new vendor or tracker is added to the site since the original consent was given — the original consent wasn't informed about this vendor, so it doesn't cover it
- The purpose of an existing tracker changes (e.g., an analytics tool starts also being used for ad targeting)
- The cookie policy itself changes materially
Any of these should trigger a fresh consent prompt independent of how recently the visitor last answered, in addition to the time-based expiry.
How this actually gets implemented technically
Most CMPs handle this by storing a timestamp alongside the consent cookie itself and checking it against a configured expiry window (commonly defaulting to 12 months, usually configurable) on each visit — if the stored consent is older than the window, the banner re-displays as if the visitor had never answered. This is usually a setting worth explicitly confirming is turned on and set to a reasonable value, rather than assuming the CMP's default is appropriate for your specific risk tolerance.
What to check on your own site
- Confirm your CMP has an expiry window configured at all — some ship with reconsent disabled by default, meaning a visitor's choice from three years ago is still being treated as current
- Check what happens when the cookie is manually cleared versus naturally expiring — both should trigger a fresh prompt, and testing the manual-clear case is the fastest way to confirm the mechanism works at all without waiting months
- Confirm vendor list changes trigger reconsent, not just the clock — if you've added a new tracking tool recently, check whether existing visitors with old consent are still being shown it without a fresh prompt
The broader point
Consent isn't a one-time checkbox you configure once and forget — it's closer to a subscription that needs periodic renewal, both on a schedule and whenever the underlying facts (what you track, who you share with) change. Treating it as a "set it up once" task is one of the more common gaps we see on sites that otherwise have a well-configured banner.
Run a free scan of your site to check your current consent setup, including whether reconsent is actually configured.
