The Consent Cookie That Expires in 30 Days: What Short Expiry Does to Your Records
A site sets its consent cookie to expire after 30 days. The visitor consents, the cookie records it, and a month later the cookie is gone. The visitor returns, the banner appears again, and they consent again. The site has two consents for one person, and no record connecting them. The audit asks for the consent history of a single visitor, and the site can produce the last 30 days.
Consent has two clocks, and they are not the same clock. The cookie is a browser mechanism: it tells the site what the visitor chose, so the banner does not reappear on every visit. The record is a legal mechanism: it proves the visitor consented, and it has to survive for as long as the processing it authorizes continues, plus the limitation period for enforcement. The SecurePrivacy audit guide puts that retention at typically three to five years after processing ends. A 30-day cookie cannot carry a three-year proof.
What short expiry actually breaks
The first thing it breaks is the visitor experience. A returning visitor gets asked again every month, and each re-ask is a chance to reject. The accept rate of a banner that reappears monthly is lower than the accept rate of a banner that appears once, because the visitor who already said yes is being asked to say yes again for no visible reason. Teams blame banner fatigue. The banner is not fatigued. The cookie expired.
The second thing it breaks is the audit trail. A consent log that only holds 30 days of history cannot answer the question an audit actually asks, which is what did this visitor agree to, and when, over the life of the relationship. The WPLegalPages consent audit guide makes the point directly: the log has to be retrievable, tamper-proof, and time-stamped, and it has to cover the period the processing covers. A log that rotates monthly is not a log. It is a window.
The third thing it breaks is the withdrawal record. A visitor who withdraws consent needs that withdrawal to be recorded and honored, and the record of the withdrawal has to outlive the cookie that carried it. If the cookie expires and the server-side record was never written, the withdrawal disappears with it, and the site has no proof it ever happened. The visitor remembers withdrawing. The site does not. That is the worst possible position in a dispute.
The two-record fix
Keep two records, and keep them separate in your head. The browser cookie is the short-lived one: it tells the site what to do on this visit, and it can expire in weeks or months. The server-side log is the long-lived one: it records every consent event, with a user or device identifier, a precise timestamp, the purposes consented to, the banner version shown, and any withdrawal, and it is retained for three to five years. The cookie is convenience. The log is proof.
Then set the cookie expiry deliberately. Twelve months is the common choice, and it matches the consent renewal interval many platforms use. Shorter than that, and returning visitors get re-asked for no reason. Longer, and the site is holding a consent the visitor may have forgotten they gave, which is its own problem. The number matters less than the fact that someone chose it on purpose and wrote down why.
Finally, test the expiry. Set a test browser, consent, and check what happens when the cookie is deleted manually. The site should re-ask, and the server-side log should still show the original consent and the new one, linked by the same identifier. If deleting the cookie erases the history, the site has one record, not two, and the proof disappears with the browser.
Keep reading: how long consent records are kept, per-domain vs per-session pricing, and consent state across domains cover the nearby cases in this series.
Frequently asked questions
How long should a consent cookie last?
Twelve months is the common choice, matching the renewal interval many platforms use. Shorter, and returning visitors get re-asked for no reason. The number matters less than the fact that someone chose it deliberately and wrote down why.
How long must consent records be kept?
For as long as the processing they authorize continues, plus the limitation period for enforcement, typically three to five years after processing ends. A 30-day cookie cannot carry that proof, which is why the server-side log has to exist separately.
What happens when a visitor deletes the consent cookie?
The site should re-ask, and the server-side log should still show the original consent and the new one, linked by the same identifier. If deleting the cookie erases the history, the site has one record, not two.
Does a short cookie expiry hurt the accept rate?
Yes. A returning visitor asked again every month is a visitor given a fresh chance to reject, for no visible reason. The accept rate of a banner that reappears monthly is lower than one that appears once.