Re-consent cadence: how often should you re-ask visitors for cookie consent?
Re-ask for consent when something material changes: new vendor categories, new purposes, or a regulatory update that alters the rules. On top of that, set a time-based refresh, typically every 6 to 12 months, so stale decisions do not linger forever. Re-asking on a fixed schedule alone, without tying it to real changes, just trains visitors to click accept blindly.
Consent has a shelf life
A consent decision made eighteen months ago was made about a different site. Vendors were added, purposes shifted, the privacy law got an amendment, and the visitor has no memory of what they clicked. Treating that old decision as permanently valid is convenient and increasingly hard to defend.
Regulators have started saying the quiet part out loud: consent should be refreshed periodically, and it must be refreshed when the processing it covers changes materially. The question is not whether to re-ask. It is how often, and what triggers it.
Change-triggered re-consent comes first
The non-negotiable trigger is material change. Add a new advertising vendor, start a new purpose like personalization that was not disclosed before, or face a regulatory update that changes the consent requirements: each of these invalidates the old decision for the affected processing. The banner must re-appear for the changed scope.
Implement this as a consent version. Every material change to vendors or purposes bumps the version, and visitors holding an older version get re-prompted. Versioning turns a vague obligation into a concrete mechanism, and it gives auditors a clean story: version 4 added two vendors, everyone on version 3 or below was re-asked.
Time-based refresh as the backstop
Even with no changes, decisions decay. The common backstop is 6 to 12 months, with 12 months the most frequently cited. Shorter than 6 months and banner fatigue sets in: visitors stop reading and start clicking whatever dismisses the banner fastest, which degrades the quality of the consent you collect.
Longer than 12 months and you are holding decisions that predate vendor changes you forgot to version, staff turnover in whoever managed the list, and visitors who have not thought about your cookie practices since last year. Twelve months is the compromise most frameworks have converged on. Document why you chose your number.
Do not re-ask the people who said no
The re-consent cadence applies to grants, not refusals. A visitor who rejected non-essential cookies should not be re-prompted every month in hopes they change their mind. That is the dark pattern regulators actually fine: consent nagging that wears down refusal.
Rejections get the same version-bump treatment for material changes, because a new purpose needs a decision, but they do not get the time-based refresh. When you do re-prompt after a material change, the previous refusal must be the starting point, not a blank slate that defaults to accept.
Make the cadence visible
Put the re-consent policy in your cookie policy: how often decisions refresh, what triggers an early re-ask, and how visitors can change their minds at any time. Transparency about the cadence does two things. It satisfies the accountability principle, and it makes the re-appearing banner feel like a policy instead of a bug.
Consent is not a one-time event. It is an ongoing relationship with a refresh cycle. Set the version triggers, set the time backstop, respect refusals, and write it all down. The banner that re-appears for a reason is compliance. The banner that re-appears for no reason is just annoyance.