The Cookies Your Consent Banner Sets Before Anyone Chooses
Open a site in a fresh browser and watch the cookies before touching the banner. There will be at least one, set by the consent platform itself, recording that no choice has been made yet. A visitor who reads the banner closely will ask the obvious question: the site just set a cookie to ask me about cookies. Is that allowed?
Yes, and the reason is narrow. The cookie the banner sets is a consent-record cookie. It stores the visitor's choice, or the fact that no choice has been made, so the banner knows whether to show again. It belongs to the strictly necessary category, the same category as a login session or a shopping cart. The ePrivacy rules require prior consent for storing information on a device, but they exempt what is strictly necessary to provide the service the visitor asked for. Remembering a consent choice is that kind of necessity.
The cookie the banner sets first
A typical consent platform sets one or two cookies on first visit. The first holds the consent state, usually as a short string of flags for each purpose and vendor. The second, on some platforms, holds the banner version and the vendor list version, so the platform knows whether the visitor's choice still matches the current list. Both are first-party cookies, set by the site's own domain or the platform's subdomain, and both contain nothing a third party could use to identify the visitor across sites.
The size is small and the lifetime is long, usually 6 to 12 months. That lifetime is the point: the visitor should not be asked again on every visit. The GDPR does not fix a lifetime for consent cookies, but regulators expect the choice to persist for a reasonable period, and 12 months is the common renewal interval. A consent cookie that expires after a week is a banner that nags, and a banner that nags gets dismissed without reading.
Why it is allowed
The exemption turns on purpose, not on the name of the cookie. A cookie that remembers a choice is strictly necessary. A cookie that also tracks the visitor, builds a profile, or sends data to an analytics endpoint is not, even if it lives in the same consent platform. The test is what the cookie does, and the test is applied cookie by cookie, not platform by platform.
This is where audits catch problems. A platform that sets its consent cookie and, in the same request, a separate identifier that feeds its own analytics is setting two cookies with two purposes. The first is exempt. The second needs consent, and it is being set before the visitor has given any. Open the network requests on a fresh visit and count the cookies. If there are more than the consent record needs, something is riding along.
What to check on your own site
Clear the browser, open the site, and list every cookie set before any choice. For each one, ask three questions. Who set it, the site or a third party. What does it store, a consent state or an identifier. And where does it go, does it leave the site's domain. A consent cookie that stays on the site and stores only the choice is fine. Anything else needs consent before it is set, and setting it first is the defect.
Check the cookie's attributes too. It should be set with a SameSite value and a secure flag on HTTPS, and it should not be accessible to scripts that do not need it. These are small settings, and they are the difference between a consent record and a leak.
Keep reading: how to audit consent cookie lifetimes and expiry, and how prior blocking of tags before consent works cover the nearby cases in this series.
Frequently asked questions
Can a consent banner set cookies before the visitor chooses?
Yes, for one job: recording the choice itself. A consent-record cookie that stores the visitor's preference, or the fact that no choice has been made, is strictly necessary and exempt from the prior-consent rule. It must store only the choice, nothing else.
How long should a consent cookie last?
Six to 12 months is the common range. The choice has to persist long enough that the visitor is not asked again on every visit, and 12 months is the usual renewal interval. A consent cookie that expires after a week makes the banner nag, and a nagging banner gets dismissed without reading.
What if my consent platform sets extra cookies on first visit?
Then those cookies need consent before they are set. The exemption covers only the consent record. A platform that also sets an identifier for its own analytics is setting a tracking cookie before the visitor has chosen, and that is a defect. Count the cookies on a fresh visit and check what each one stores.
Is the consent cookie first-party or third-party?
First-party in a normal setup, set by the site's own domain or the platform's subdomain. It contains the consent state, not an identifier a third party could use across sites. If the cookie is set by an unrelated third-party domain, that is a different design and worth questioning.