Illinois BIPA and Facial Recognition: What Section 15 Requires

BIPA is not a privacy-by-design statute and it does not ask you to balance interests. It is a short list of things you must do before you collect, and a private right of action for failing to do them.

What is a biometric identifier

The Illinois Biometric Information Privacy Act is codified at 740 ILCS 14 and has been in force since 2008. Section 10 defines a biometric identifier as a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry. It then excludes a long list of things, including writing samples, photographs, physical descriptions, and biological samples used for valid scientific testing. Biometric information is information based on a biometric identifier used to identify an individual, however captured or stored.

The photograph exclusion is the sentence defendants reach for and it almost never works. Illinois federal courts have repeatedly held that while a photograph is not itself a biometric identifier, a scan of face geometry derived from a photograph is one, and the resulting template is biometric information — the reasoning in cases such as Monroy v. Shutterfly and Rivera v. Google. The practical rule for a product team is that the moment you compute an embedding from a face in order to match it, you are inside the statute, whatever the input medium was.

Read the Act itself at the Illinois General Assembly, and note that it is genuinely short — the operative obligations are one section.

Section 15(b): the written release

Section 15(b) prohibits collecting, capturing, purchasing, receiving through trade or otherwise obtaining a person’s biometric identifier or biometric information unless you first do three things, in this order and before collection:

• Inform the subject in writing that a biometric identifier or biometric information is being collected or stored.
• Inform the subject in writing of the specific purpose and the length of term for which it is being collected, stored and used.
• Obtain a written release executed by the subject or their legally authorised representative.

All three elements are load-bearing and each has produced litigation on its own. “Specific purpose” is not satisfied by “security and product improvement”. “Length of term” is not satisfied by “as long as necessary”. And a written release is a separate act from acceptance of a privacy policy: burying the language in terms of service that a user scrolls past is the single most common design defect in a BIPA claim. Since the 2024 amendment in Public Act 103-0769, an electronic signature expressly satisfies the written-release requirement, which removes an argument about mechanism but not the argument about specificity.

Note what section 15(b) does not require: no risk assessment, no balancing test, no regulator notification, no data protection officer. If you have built for GDPR Article 9, you have done more work than BIPA asks for and possibly none of the work BIPA asks for.

Section 15(a): the public retention schedule

Section 15(a) requires a private entity in possession of biometric identifiers or biometric information to develop a written policy, made available to the public, establishing a retention schedule and guidelines for permanently destroying the data when the initial purpose for collecting it has been satisfied, or within three years of the individual’s last interaction with the entity, whichever occurs first.

Three details decide compliance here. The policy must be public, which means published, not merely written and retained internally. The trigger is the earlier of two events, so a three-year clock does not rescue you if the purpose was satisfied in week one. And destruction must be permanent, which for a vector store means deleting the embedding and any derived index entry, not marking a row as inactive.

The 15(a) claim is frequently pleaded alongside 15(b) because it is easy to prove from the outside: a plaintiff’s counsel can check whether a public retention policy exists by loading your website. It is also the cheapest of all BIPA obligations to satisfy, which is why its absence reads badly.

Sections 15(c) to 15(e): sale, disclosure, care

The remaining subsections are shorter and absolute. Section 15(c) prohibits selling, leasing, trading or otherwise profiting from a person’s biometric identifier or biometric information — a flat bar, with no consent route out of it. Section 15(d) prohibits disclosure, redisclosure or dissemination without the subject’s consent, subject to narrow exceptions including where disclosure completes a financial transaction requested by the subject, or is required by law or a valid warrant.

Section 15(d) is the one that catches AI architectures specifically. Sending a face crop to a third-party model provider for embedding or matching is a disclosure to that provider. A data processing agreement does not cure it, because BIPA has no controller/processor architecture at all — it does not recognise the distinction that GDPR builds its whole allocation of responsibility on. If a vendor sits in the path, the consent you obtained needs to have covered that.

Section 15(e) requires the entity to store, transmit and protect the data using the reasonable standard of care within its industry, and in a manner at least as protective as it uses for other confidential and sensitive information. It is the only subsection framed as a standard rather than a rule, and it is the one under which a breach becomes a BIPA claim rather than only a breach-notification matter.

How this differs from GDPR Article 9

Both regimes treat biometric data as special, and the resemblance ends there. GDPR Article 9(1) prohibits processing biometric data for the purpose of uniquely identifying a natural person and then reopens it through ten conditions in Article 9(2), of which explicit consent is only one; the rest of the GDPR apparatus — lawful basis under Article 6, a DPIA, data subject rights, records of processing — applies on top.

BIPA has none of that machinery. It has one gate, and the gate is a specific written release given before collection. There is no legitimate-interest route, no vital-interests route and no substantial public interest route. Conversely there is no requirement to conduct an assessment, appoint anyone, or respond to access requests. A team that ports a GDPR consent flow to Illinois will typically fail on the “length of term” disclosure and on the separateness of the release; a team that ports a BIPA flow to Europe will fail on basically everything else.

The other difference is the remedy, and it is the one that determines how seriously the statute is taken. GDPR is enforced by supervisory authorities; BIPA is enforced by private plaintiffs with statutory damages per violation, which is the subject of the damages page.