The BIPA Clause Anyone Can Check Without Ever Contacting You

Why This Clause Behaves Differently From the Rest

The consent provisions are relational. To evaluate them you have to know what a specific person was told, when, and whether they signed something. That takes a plaintiff with a story and a document request.

The policy provision is not relational. It describes a state of the world: does a written policy exist, and can the public read it. That question is answerable from outside your organisation, at scale, by anyone who has noticed you deployed a face recognition time clock or a voice authentication step. Which is exactly how the screening is done — a scan of public pages, then a look at what the product visibly does.

So the practical asymmetry is stark. It is the cheapest obligation in the statute to satisfy, and it is the one most likely to be evaluated first, by someone deciding whether you look like an organisation that has thought about this at all.

What Has to Be in the Document

The statutory text is short, which tempts teams to write something equally short. The two nouns it uses — a schedule and guidelines — both imply particulars:

• The categories held. Face templates, voice templates, fingerprint or palm minutiae, iris or retina scans, and any derived embedding. Name them rather than saying "biometric data", because the categories drive the schedule.
• The purpose for each. Timekeeping, access control, identity verification, fraud prevention. The purpose is the destruction trigger, so a policy that omits it cannot describe when destruction occurs.
• The retention period and its trigger. Not just a duration — the event that starts the clock, and the outer three-year backstop measured from last interaction.
• The destruction method. Permanent deletion of templates and any copies, including the derived vector store, with a statement about backups and how long they persist before rotation removes the record.
• Who is responsible. A role that owns the schedule and reviews it, so the document is a live control rather than a page written once.
• Vendors and disclosure. That third parties may process on your behalf, and that they are bound to the same schedule. This is where the policy meets reality, and where most of them are quietly untrue.

Two things to avoid. Do not copy a general data retention policy and add a biometric paragraph — the schedule and the destruction guidelines are the substance, and a paragraph is not a schedule. And do not publish a period you cannot meet. A stated schedule that your infrastructure contradicts is a documented commitment you are visibly failing, which is a worse position than an honest, longer period.

The Destruction Half Is Where AI Pipelines Break

Writing the policy is an afternoon. Making the destruction half true is the actual project, because a modern biometric feature is not one store. A face verification step may produce an uploaded image, a cropped face, a numeric embedding in a vector index, a match log with a similarity score, a model cache at the vendor, and a queue message that carried the payload between two of those.

Teams reliably delete the first and forget the rest. The embedding is the item the statute cares about most and it is usually the one that survives, because it sits in an index that was designed for fast recall and never had a deletion path. If your destruction routine cannot remove a specific person's vector from that index, your published schedule is describing something that does not happen.

Three checks make this concrete. Pick one enrolled individual, run the deletion path, and confirm the template is gone from the primary store, from the search index, and from the vendor. Then check what the backup lifecycle does — if the daily snapshot retains ninety days, say so in the policy rather than implying instantaneous erasure. Finally, check the logs: a match log holding the score and the template identifier can itself be the retained record.

The Purpose Trigger Fires Long Before Three Years

The three-year figure is the one everybody remembers, and it is the less demanding of the two triggers. Destruction is due when the initial purpose has been satisfied or three years after last interaction, whichever comes first. For most deployments the purpose is satisfied far sooner:

1. An employee separates. The timekeeping purpose ends with employment. Templates for former staff sitting in a live enrolment database are the single most common finding.
2. A one-time verification completes. If the face scan existed to confirm identity at onboarding, retaining the template afterwards requires a new purpose, not the original one.
3. A device or site is decommissioned. Enrolments tied to a scrapped scanner or a closed location have no remaining purpose, and the data usually migrates rather than being cleared.
4. A vendor is replaced. The old provider's copy needs a documented deletion and a confirmation, which is easy to obtain during a transition and nearly impossible after the contract ends.

Build the schedule around those events rather than around a calendar, and the three-year backstop becomes what it is meant to be — a limit that rarely binds, not the plan.

Where to Put It So It Counts

Publish it as its own page on the public site, linked from the footer next to the privacy policy, reachable without authentication and without a cookie wall. Keep the URL stable, date the version, and keep prior versions retrievable — an undated policy cannot demonstrate that it existed before the collection it governs.

If you employ people in Illinois, publishing externally does not remove the need to put the same document in front of them internally; it satisfies a different half of the same obligation. And if you are a vendor selling a biometric capability to other businesses, your customers will increasingly ask for the URL during procurement, because their own exposure runs through yours.

Common Questions