Consent Expiry and Re-Prompting: A Checklist for When to Ask Visitors Again
Consent Is Not Forever
Once a visitor makes a choice, you should remember it so they are not nagged on every page. But a stored choice does not last indefinitely. Circumstances change, tools are added, and a decision made long ago may no longer reflect what the visitor would choose today. This checklist helps you set sensible expiry and re-prompt rules.
What the Rules Say (and Don't)
The GDPR does not set a fixed expiry date for consent. Guidance from regulators fills the gap in practice. France's CNIL, for example, recommends keeping the visitor's choice for around six months before asking again, and says that the lifetime of the tracking cookies themselves should not exceed 13 months. Other authorities have not set exact numbers. Check the authority relevant to your audience and document the period you choose.
Checklist 1: Set the Default Lifetime
- Pick a consent lifetime and write it down. Six to twelve months is a common range; choose the shorter end where your regulator suggests it.
- Store the date the choice was made, not just the choice.
- Apply the same lifetime logic to the cookie or storage entry that holds the consent record.
- Make sure the stored choice expires on the server side or in your logic, not only in the browser.
Checklist 2: Define Re-Prompt Triggers
Ask the visitor again, regardless of age of the stored choice, when:
- You add a new purpose. A new use of data was never covered by the earlier choice.
- You add a new vendor or partner that processes data in a way not previously disclosed.
- Your privacy or cookie policy changes materially.
- The banner version changes in a way that alters the choices on offer.
- The stored choice is missing, corrupted or unreadable.
Tie this to a consent version number you increment when anything above happens. A stored choice with an older version triggers the banner.
Checklist 3: Protect the Visitor Experience
- Do not re-prompt on a timer inside a single session.
- Do not re-ask a visitor who rejected just to wear them down; honour a rejection for the full period unless a genuine trigger occurs.
- Keep a persistent link in the footer so visitors can change their mind at any time, with no waiting for expiry.
- Make withdrawing consent as easy as giving it.
Checklist 4: Handle the Edge Cases
- Cleared cookies. The banner will reappear. That is expected; do not try to work around it with fingerprinting.
- Multiple domains or subdomains. Decide whether a choice is shared across them and make the behaviour consistent.
- Apps. Store the choice and its date in app storage, and re-ask after SDK updates that add data uses.
- Region changes. If a visitor moves to a different jurisdiction, check whether your rules should apply differently.
Checklist 5: Keep Evidence
- Record timestamp, banner version and choice for each consent.
- Keep a change log of when you changed the lifetime or version number and why.
- Review the settings every quarter alongside your cookie inventory.
Where FlexyConsent Fits
FlexyConsent is certified by IAB Europe and IAB Canada, supports IAB TCF 2.4 and Google Consent Mode v2, and covers regions including the EU, EEA, UK, US states, Canada and Quebec. Whatever platform you use, check how it stores the choice and what triggers a new prompt, and match that against the rules you wrote above.
Key Takeaways
- Consent should expire; there is no single legal number, so choose a period, write it down and check your regulator's guidance.
- Re-prompt when purposes, vendors, policies or banner choices change, using a consent version number.
- Do not pester visitors who rejected without a real trigger.
- Keep an always-available way to change or withdraw consent.
- Record timestamp, version and choice, and review the rules every quarter.