Consent for Age Verification and Identity Tools: Data Collected Before a Choice

Age checks on restricted products often load a third party tool that sets cookies and fingerprints the device before the shopper has consented to anything. Sequencing identity checks and consent on a restricted catalogue.

A store selling age restricted goods has two obligations that collide on the same page. It must verify age, sometimes before showing the product at all, and it must not load non essential tracking before consent. The age verification tool, though, is usually a third party script, and like most third party scripts it wants to set cookies, read device information, and call home the moment it loads. Load it early to satisfy the age gate and you may have shared device data with a vendor before the visitor agreed to anything beyond the strictly necessary.

The ICO has published detailed work on age assurance and children's privacy, and its general position is that data protection applies to the verification process itself, not just to what happens after it. Verifying that someone is over 18 does not require building a marketing profile of them, and a well configured setup keeps those two things separate. That separation is a configuration and procurement task more than a legal one.

What is strictly necessary here

A functional cookie that remembers a visitor has passed an age check, so they are not asked on every page, has a good claim to be strictly necessary for a service the user requested. Analytics about verification attempts, device fingerprinting for fraud scoring, and any advertising identifiers set by the same vendor are a different matter. Ask the vendor for a list of exactly what their script sets and sends on load, before any verification happens, and get it in writing. Vendors are often able to run in a reduced mode when asked directly.

Sequence the page so the minimal check loads first, with marketing and analytics held until consent, as they would be anywhere else on the site. If the verification vendor bundles the two, raise it in contract renewal. A store should not have to choose between its age obligations and its consent obligations because one supplier combined their product with an advertising pipeline.

Asking for the least data that proves age

Age assurance is a spectrum, from self declaration, which is weak, through attribute checks that confirm over 18 without revealing a date of birth, to full identity document checks. Data minimisation points toward the lightest method that meets your actual legal duty for the product in question. Collecting a full date of birth and document images to sell a product that only needs an over 18 attribute is excess data, with excess breach risk attached.

Whatever the method, be plain about it before the shopper starts: what will be checked, by whom, what is kept, and for how long. A verification step that appears without explanation, demanding documents, is where shoppers abandon and where complaints come from. Retention is the question stores forget. Verification evidence kept indefinitely, just in case, is a liability that grows with every order.

Records and the restricted catalogue edge cases

Keep records of age checks sufficient to show the check happened, without hoarding the underlying documents where the vendor can hold that responsibility instead. Decide what happens for failed and abandoned checks, for repeat attempts, and for customers who verified once and return logged in. Each of those states has a data footprint, and each should be deliberate.

Watch the edges of the catalogue too. Mixed baskets, gift purchases, subscription renewals for restricted items, and a blog or buying guide about restricted products that sits outside the age gate but loads the same marketing stack. Consistency matters: a store that gates the product page carefully and then discusses the product on an ungated page carrying full tracking has not really thought about where its obligations begin.

Related reading: Auditing Consent Banner Dark Patterns Honestly, Auditing Consent on Multilingual Stores Without Guessing, Auditing Consent on Password Reset, Account Creation, and Other Quiet Flows.

Frequently asked questions

Does an age check cookie need consent?

A cookie that is strictly necessary to provide the service the user asked for, such as remembering that an age check was passed so the site functions, is generally exempt from consent. Cookies set by the same tool for analytics, fraud profiling beyond necessity, or advertising are not covered by that exemption.

Should age verification happen before or after cookie consent?

They are separate questions and should be presented as such. Load only what is necessary for the check itself, hold non essential tracking until consent, and explain the verification before asking for personal data. Combining them into one accept everything gate muddies both decisions.

What is the least data an age check can use?

An attribute answer, over 18 yes or no, rather than a full date of birth or identity documents, where that level of assurance meets the requirement for the product. Data minimisation means matching the method to the duty, not defaulting to the heaviest check available.

Who holds verification data, us or the vendor?

Prefer arrangements where the vendor performs the check and returns a result, and the store keeps a record that a check passed, when, and by what method, without storing document images itself. Confirm retention periods and deletion in the contract, not just in a sales conversation.