BIPA Compliant Software Development: The Ceiling Fell, the Floor Didn't

Something significant happened to Illinois biometric privacy law in April 2026, and a lot of engineering teams drew exactly the wrong conclusion from it.

Here's what happened. In 2023, the Illinois Supreme Court held in Cothron v. White Castle System that a separate claim accrues under BIPA each time a biometric identifier is scanned or transmitted in violation of the Act. The arithmetic that follows is brutal: an employee clocking in with a fingerprint twice a day for five years generates thousands of claims. In one case that later reached the Seventh Circuit, a single plaintiff alleged his fingerprint had been collected roughly 1,500 times — putting his individual exposure at $7.5 million, with the putative class action placing billions in controversy.

The Illinois legislature responded with Public Act 103-769, signed August 2, 2024, clarifying that collecting or disclosing the same biometric identifier from the same person using the same method of collection constitutes a single violation — not one per scan.

Then, on April 1, 2026, in Clay v. Union Pacific Railroad, the Seventh Circuit held that this amendment applies retroactively to cases pending when it was enacted, reasoning that the amendment limited available damages rather than altering the substantive requirements or the number of violations.

The conclusion many teams drew: BIPA got easier.

The conclusion the ruling actually supports: the financial ceiling came down substantially, and the engineering floor didn't move at all.

Every substantive obligation remains. The written policy with a retention schedule. Informed written consent before collection. Disclosure limits. Reasonable security standards. The private right of action — the thing that made BIPA the most litigated privacy statute in the country — is entirely intact. Per-person damages of $1,000 or $5,000 still apply, and a class of a few thousand people is still a very serious number.

What changed is that a compliance failure is now expensive rather than existential. That is not the same as safe.

This guide covers what BIPA actually requires of a system, the architecture that satisfies it, the scope boundaries that determine how much of your platform is exposed, and — because Illinois added a second regime this year — what the state's new AI employment discrimination law means for anyone building software that scores or ranks people.

It is written for architects and technical leaders, and it is engineering guidance rather than legal advice. Validate your specific obligations with qualified counsel.

What BIPA Actually Requires {#requirements}

Strip away the litigation coverage and the statute imposes a compact set of obligations. Translated into engineering terms:

A written policy, publicly available, with a retention schedule and destruction guidelines. Not an internal wiki page — a published document stating how long you keep biometric data and when you destroy it. And critically: the schedule has to be one your system actually executes.

Informed written consent before collection. The subject must be told, in writing, that biometric data is being collected or stored, the specific purpose, and the retention period — and must provide a written release. The 2024 amendment usefully clarified that electronic signatures satisfy the written release requirement, which resolved a genuine ambiguity for digital products.

No selling, leasing, or trading biometric data. Absolute.

No disclosure without consent, subject to narrow exceptions.

Reasonable standard of care in storage and transmission — at least as protective as how you handle other confidential and sensitive information.

Destruction when the purpose is satisfied or within three years of the individual's last interaction, whichever comes first.

That last clause is the one most likely to be quietly violated by a system that otherwise looks compliant, and it gets its own section below.

Scope: What Counts as Biometric Data {#scope}

Scope determines exposure, and scope questions are where engineering teams most often guess wrong.

Biometric identifiers under BIPA include retina or iris scans, fingerprints, voiceprints, and scans of hand or face geometry.

Biometric information is any information, however captured, converted, stored, or shared, based on a biometric identifier used to identify an individual.

That second definition is the expansive one, and it's why the following are commonly in scope even though no raw biometric is stored:

• Face embeddings and feature vectors. A mathematical representation derived from face geometry, used to identify someone, is biometric information. "We don't store the photo, only the embedding" is not the defense teams sometimes assume it is.

• Voiceprint templates in speaker identification or voice authentication.

• Fingerprint hashes used for matching.

• Hand geometry measurements from time clocks and access control.

Commonly outside scope, though this depends heavily on implementation:

• Photographs and writing samples, which the statute expressly excludes from the identifier definition — though a face template derived from a photograph is a different question

• Face detection that never identifies anyone (counting faces in a frame, detecting whether a person is present) as distinguished from face recognition

• Demographic estimation not tied to identifying a specific individual

The engineering principle that follows: the boundary is identification, not capture. A system that processes facial imagery to blur it, count it, or detect presence sits in a materially different position from one that generates a template to match a person against a database.

And the corresponding design decision: if identification isn't required for your use case, architect so that you never generate an identifying template. That single decision removes the entire obligation set rather than requiring you to satisfy it. It's the biometric equivalent of scope reduction, and it's the cheapest compliance you will ever implement.

Consent Architecture {#consent}

BIPA's consent requirement is prior, written, informed, and purpose-specific. Four properties, each with architectural consequences.

Prior means the gate sits before collection, not before use. A pipeline that captures biometric data and checks consent downstream has already collected. The check belongs at the capture boundary — in the client, at the API edge, before the frame or the scan is processed.

Written means an artifact you can produce years later. The 2024 amendment confirmed electronic signatures qualify, which makes this tractable for digital products — but "tractable" means designing for it. What you need to be able to reproduce, potentially in litigation, is: who consented, to what exact disclosure text, at what version, when, through what mechanism.

Informed means the disclosure text is part of the record. If your privacy notice changed in March, a consent captured in January was given against different text. Version your disclosures and store the version identifier with each consent record. This is a small schema decision that becomes very important if you ever have to demonstrate what someone actually agreed to.

Purpose-specific means consent isn't a global boolean. Consent to fingerprint-based timekeeping is not consent to use the same identifier for building access, or for training a model.

The pattern that satisfies all four:

Treat consent as an append-only event log, not a flag on a user record. Every grant and every withdrawal is an immutable event carrying the subject, the biometric type, the purpose, the disclosure version, the timestamp, and the capture mechanism. Current consent state is derived from the log rather than stored separately.

The reason this matters more than it might seem: a boolean tells you the current state and nothing about history. An event log lets you answer the question that actually gets asked — what was this person's consent status on this date, against what disclosure? — which a flag simply cannot.

The Retention Schedule Problem {#retention}

Here is the requirement most likely to be violated by a system whose team believes it is compliant.

BIPA requires destruction when the purpose for collection is satisfied, or within three years of the individual's last interaction with the entity — whichever occurs first.

Most teams write a policy stating this. Far fewer build a system that executes it.

Why it fails in practice:

"Last interaction" is harder to compute than it sounds. Which events count? A login? A support ticket? An automated email open? You need a defensible definition, implemented consistently, and documented.

Deletion has to reach everywhere. The primary store, replicas, backups, the analytics warehouse, log archives, any cache, any third-party processor, and any model artifact derived from the data. A retention job that deletes a row while the value persists in six other places hasn't satisfied anything.

Derived data is the hard case. If a face embedding was used in a training set, what does destruction mean? There is no clean technical answer, which is precisely why the defensible posture is to exclude biometric data from training pipelines by default and permit exceptions only with specific, documented consent and a plan for what happens on destruction. Discovering this question after a model exists is far worse than answering it in sprint two.

Nobody owns it after launch. Retention is an operational process, not a launch task. A scheduled job that silently fails for eight months is a compliance gap accumulating quietly.

What a defensible implementation looks like:

• A retention engine that runs on a schedule, computes eligibility from a documented "last interaction" definition, and executes destruction across every store

• Destruction receipts — a record that deletion occurred, when, and across which systems. Retained after the data itself is gone, because proving destruction is the point

• Alerting when the job fails, treated with the same seriousness as a production outage

• Periodic verification that the job's coverage still matches the actual data estate, since new systems get added and retention configuration rarely follows automatically

Disclosure Controls and the Vendor Chain {#disclosure}

BIPA prohibits disclosing biometric data without consent, and prohibits selling, leasing, or trading it outright.

The engineering consequence teams underestimate: your third-party stack is a disclosure surface.

If biometric data or derived identifiers flow to a cloud vision API, an analytics platform, an error monitoring service that captures request payloads, or a log aggregation tool, those are disclosures. Each needs to be either consented to, contractually controlled, or — far preferably — architecturally prevented.

The audit worth running before you ship:

1. Enumerate every service that could receive biometric data or a derived identifier, including indirectly through logs, error payloads, or telemetry

2. For each: is it necessary, is it covered by consent, is it contractually bound to your retention obligations?

3. For anything unnecessary, remove the flow rather than papering it with consent language

A specific and very common failure: error monitoring that attaches request context to exceptions. A face-matching endpoint that throws will helpfully ship its request body to a third party — which now holds biometric data nobody intended to disclose, with its own retention policy you don't control. Redaction at the logging boundary, tested, is a small piece of engineering that prevents a large problem.

Designing for the Evidence You'll Need {#evidence}

Because BIPA carries a private right of action, the practical question isn't only "are we compliant" but "can we demonstrate compliance to a plaintiff's counsel and a court."

Those are different engineering problems.

What you need to be able to produce:

• Consent records with the disclosure version, timestamp, mechanism, and purpose — for a specific individual, on a specific date

• The policy as it existed at any given time, which means versioning your published policy, not just your current one

• Destruction receipts demonstrating the retention schedule executed

• Access logs showing who accessed biometric data and when

• Disclosure records showing where data flowed and under what authority

And the design implication: these are all queryable-by-individual requirements. A system that can tell you aggregate statistics but can't reconstruct one person's complete history is much less useful than it needs to be.

Build the "produce everything about this person" query on day one. You will use it for compliance response, and you will be very glad it exists if you ever need it under time pressure.

Where Teams Consistently Get It Wrong {#failure-patterns}

1. Assuming the 2026 ruling reduced obligations. It reduced damages exposure. Every substantive requirement, and the private right of action, remain.

2. "We only store the embedding, not the image." A template derived from face geometry and used to identify someone is biometric information.

3. Consent as a boolean. Cannot answer what someone agreed to, when, or against what disclosure text.

4. A retention policy nobody implemented. Writing the schedule is the easy half. Executing it across every store, with receipts, is the actual requirement.

5. Biometric data reaching third parties through logs and error payloads. Unintended disclosure, with a retention policy you don't control.

6. Biometric data in training pipelines by default. Creates a destruction problem with no clean answer.

7. Building identification where detection would do. The most expensive unforced error, because the entire obligation set was avoidable.

8. Treating retention as a launch task. It's an operational process that needs an owner and failure alerting.

Illinois' Second Regime: AI in Employment {#hb3773}

Illinois added a materially different obligation this year, and it reaches a much wider set of software than BIPA does.

Effective January 1, 2026, House Bill 3773 amended the Illinois Human Rights Act to make it a civil rights violation for an employer to use artificial intelligence that has the effect of subjecting employees to discrimination on the basis of a protected class — across recruitment, hiring, promotion, renewal of employment, selection for training or apprenticeship, discharge, discipline, tenure, and the terms, privileges, or conditions of employment.

It also prohibits using ZIP code as a proxy for protected classes, and requires notifying employees and applicants when AI is used in those decisions. The Illinois Department of Human Rights has been developing implementing rules addressing notice requirements and related specifics.

Three features make this consequential for engineering teams.

Liability attaches to effect, not intent. "We didn't design it to discriminate" is not a defense. What matters is whether the system produces a discriminatory effect — which means the ability to demonstrate you tested for it becomes the practical requirement.

The definition of AI is broad. The statute reaches machine-based systems that infer how to generate outputs including predictions, content, recommendations, or decisions — expressly including generative AI. A resume-ranking score, a scheduling optimizer, a performance-flagging model, a chatbot screening candidates: all plausibly in scope.

Employers remain responsible for third-party tools. This is the clause that matters most if you build software rather than buy it. If your product scores, ranks, screens, or flags people in an employment context, your customers are now carrying strict liability for what your model does. That will show up in their procurement requirements whether or not the statute names you directly.

What that means you need to build:

• Bias testing as a repeatable pipeline, not a one-time audit. Disparate impact analysis across protected classes, run before every model release, with retained results.

• Proxy detection. ZIP code is named explicitly, but the underlying principle reaches any feature that correlates strongly with a protected class. Audit your feature set for proxies, and be able to show you did.

• Notice mechanisms your customers can actually deploy — surfaced at the right moment in the candidate or employee flow, configurable to their language.

• Explainability sufficient to defend a decision. If a candidate was ranked low, someone will eventually need to explain why in terms a person understands. Models that produce a score without attributable reasoning make this hard, which is a real architectural argument for interpretable approaches or explanation layers in this domain.

• Meaningful human review workflows — where the reviewer sees the reasoning, has genuine authority to override, and leaves a record. An interface optimized for throughput produces rubber-stamping, which is not review.

• Documentation and audit artifacts your customers can hand to their counsel.

If you sell HR tech, ATS software, workforce management, or performance tooling into Illinois and haven't built these, your next enterprise security review is going to be uncomfortable.

Building for Both at Once {#both}

Illinois is now the only state carrying both an aggressive biometric statute with a private right of action and an AI employment discrimination law imposing strict liability for effect.

That combination bites hardest at a specific intersection: workforce systems that use biometrics.

A biometric time clock is a BIPA system. If its data feeds attendance analytics that inform discipline or scheduling decisions, it may also be an HB 3773 system. A facial recognition access control platform whose logs inform performance evaluation sits in both regimes simultaneously.

The architectural response is a boundary, not a merge. Biometric identification data should not flow freely into decision-support systems. Where a legitimate connection exists, it should be an explicit, documented, minimal interface — not an incidental consequence of everything living in the same warehouse.

Usefully, the two regimes share underlying engineering primitives:

Build those primitives once and both regimes become substantially cheaper to satisfy — which is the general case for compliance architecture and the specific case in Illinois.

A Case Study in Density: Illinois {#illinois}

BIPA reaches any private entity collecting biometric identifiers from Illinois residents, regardless of where that entity is headquartered — which is why it has generated litigation against companies with no Illinois presence at all.

But Illinois is where teams live with it daily, and the state's economic mix explains why the exposure is unusually broad there.

Illinois runs two Department of Energy national laboratories — Fermilab in Batavia and Argonne in Lemont — producing research computing demands most states never generate. It hosts heavy equipment manufacturing at genuine industrial scale, with plant floors running biometric time clocks and access control as a matter of course. It has some of the most productive farmland in the country, with agricultural operations increasingly instrumented. And the University of Illinois Urbana-Champaign, where NCSA built the Mosaic browser in 1993, anchors an engineering pipeline that runs statewide rather than concentrating in one metro.

The practical consequence: in Illinois, biometric exposure isn't confined to consumer apps. It runs through manufacturing workforce systems, facility access control, research facility credentialing, and increasingly agricultural operations management. Those are exactly the systems where a retention schedule is most likely to have been written and never implemented — because they were procured as operations tooling rather than as privacy-sensitive platforms.

For organizations building under both regimes, our software development company in Illinois practice works with manufacturing, research-adjacent, and agtech clients on exactly these constraints, with consent architecture and retention enforcement designed in from sprint one. Our Illinois cost guide covers what that compliance layer typically adds to a build.

How to Evaluate an Engineering Partner {#evaluating}

Seven questions that distinguish teams who have shipped under these regimes from teams who have read about them.

1. "Does this use case actually require identification, or would detection suffice?"
A partner who asks this first is trying to remove your obligation set rather than satisfy it. It's the single strongest signal available.

2. "How would you structure consent so we can prove what someone agreed to, and when?"
Strong answers describe an append-only event log with disclosure versioning. Weak answers describe a checkbox.

3. "Walk me through how the retention schedule executes across our whole data estate."
Every store, backups included, with destruction receipts and failure alerting. Vagueness here means the policy will exist on paper only.

4. "Which of our third parties could receive biometric data, including through logs and error payloads?"
Fluency here signals real experience. Teams new to this haven't thought about their error monitoring.

5. "How do you keep biometric data out of training pipelines, and what happens on destruction?"
Exclusion by default with documented exceptions is the defensible answer.

6. "If we score or rank people in an employment context, how would you build bias testing and explainability?"
Repeatable disparate impact analysis before every release, proxy detection, retained results, meaningful human review with override authority.

7. "What would make you tell us not to build this feature?"
A partner who has advised against an identification feature because detection would serve is demonstrating exactly the judgment you're buying.

Red flags: compliance discussed as a phase near launch; "we're BIPA compliant" stated as a company property rather than a system characteristic; no question about whether identification is genuinely required; a retention policy with no implementation plan; no bias testing proposed for a system that scores people in employment contexts.

Key Takeaways {#takeaways}

• The 2026 ruling cut damages exposure, not obligations. Written policy, retention schedule, prior informed written consent, disclosure limits, security standards, and the private right of action all remain.

• Scope turns on identification, not capture. If detection serves your use case, architect so you never generate an identifying template — the cheapest compliance available.

• Derived identifiers count. Face embeddings, voiceprint templates, and fingerprint hashes used to identify someone are biometric information.

• Consent must be an event log, not a boolean. With disclosure versioning, so you can prove what someone agreed to and when.

• The retention schedule is the requirement most often written and least often implemented. Build a retention engine with destruction receipts and failure alerting.

• Your third-party stack is a disclosure surface — including error monitoring that captures request payloads.

• Illinois added a second regime in January 2026. HB 3773 imposes strict liability for discriminatory effect in AI-assisted employment decisions, and employers remain responsible for third-party tools — which reaches anyone building HR, ATS, or workforce software.

Frequently Asked Questions {#faqs}

What is BIPA and who does it apply to?

The Illinois Biometric Information Privacy Act regulates how private entities collect, store, use, and disclose biometric identifiers and biometric information. It applies to private entities collecting biometric data from Illinois residents regardless of where the entity is headquartered, which is why it has produced litigation against companies with no Illinois presence. It carries a private right of action with liquidated damages of $1,000 or $5,000 per violation depending on the conduct.

Did the 2026 Seventh Circuit ruling make BIPA compliance easier?

It reduced financial exposure, not obligations. Public Act 103-769 established in August 2024 that repeatedly collecting the same identifier from the same person by the same method is a single violation rather than one per scan, reversing the effect of Cothron v. White Castle. In April 2026, the Seventh Circuit held in Clay v. Union Pacific Railroad that this applies retroactively to pending cases. The substantive requirements and the private right of action are unchanged.

What are the core engineering requirements of BIPA?

A publicly available written policy with a retention schedule and destruction guidelines; prior informed written consent specifying purpose and retention period, with electronic signatures now expressly sufficient; no selling, leasing, or trading of biometric data; no disclosure without consent; a reasonable standard of care in storage and transmission; and destruction when the purpose is satisfied or within three years of the individual's last interaction, whichever comes first.

Are face embeddings covered by BIPA?

Generally yes, where they are derived from face geometry and used to identify an individual. BIPA's definition of biometric information covers information based on a biometric identifier used to identify a person, however captured or converted. "We don't store the photo, only the embedding" is not the defense teams sometimes assume it is.

Does face detection count as biometric data under BIPA?

The boundary turns on identification rather than capture. Detecting that a face is present, counting faces, or blurring them without generating an identifying template sits in a materially different position from face recognition that matches a person against a database. Where identification isn't required by the use case, architecting so you never generate a template removes the obligation set entirely.

How should consent be stored for BIPA compliance?

As an append-only event log rather than a boolean on a user record. Each grant or withdrawal should carry the subject, biometric type, purpose, disclosure text version, timestamp, and capture mechanism, with current state derived from the log. This is what lets you answer the question that actually gets asked — what did this person agree to, on this date, against what disclosure text.

What does BIPA's retention requirement actually demand technically?

Destruction when the collection purpose is satisfied or within three years of the individual's last interaction, whichever comes first. Technically that requires a defensible and documented definition of "last interaction," a retention engine that executes on schedule across every store including backups and analytics warehouses, destruction receipts proving deletion occurred, failure alerting treated as seriously as a production outage, and periodic verification that coverage still matches the data estate.

Can biometric data be used to train AI models?

It creates a destruction problem with no clean technical answer, since removing an individual's contribution from a trained model is not straightforward. The defensible architectural posture is to exclude biometric data from training pipelines by default and permit exceptions only with specific documented consent and a plan for what destruction means. This question is far cheaper to answer in sprint two than after a model exists.

What is Illinois HB 3773 and does it apply to software vendors?

Effective January 1, 2026, HB 3773 amended the Illinois Human Rights Act to make it a civil rights violation for employers to use AI with a discriminatory effect on protected classes in employment decisions, to use ZIP code as a proxy for protected classes, or to fail to notify employees and applicants that AI is being used. Liability attaches to effect regardless of intent, and employers remain responsible for third-party AI tools — so vendors building ATS, HR, or workforce software will face these requirements through customer procurement.

What should HR tech vendors build to support HB 3773 compliance?

Repeatable bias testing as a pipeline rather than a one-time audit, with disparate impact analysis run before every model release and results retained. Proxy detection across the feature set, since ZIP code is named but the principle reaches any strongly correlated feature. Deployable notice mechanisms customers can surface at the right moment. Explainability sufficient to defend an individual decision. Meaningful human review workflows with visible reasoning and genuine override authority. And documentation customers can hand to their counsel.

How do BIPA and HB 3773 interact?

They intersect at workforce systems using biometrics. A biometric time clock is a BIPA system; if its data feeds analytics informing discipline or scheduling, it may also fall under HB 3773. The architectural response is a deliberate boundary rather than a merge — biometric identification data shouldn't flow incidentally into decision-support systems. Both regimes share underlying primitives: purpose-bound processing, immutable event logging, versioned artifacts, and query-by-individual capability.

How much does BIPA compliance add to a software build?

Typically 15–25% above an equivalent unregulated build, covering consent capture and event logging, disclosure versioning, the retention engine and destruction receipts, disclosure controls across the third-party stack, access logging, and query-by-individual capability. Designed in from sprint one it's a line item; retrofitted after a claim it's re-architecture under time pressure.

The Bottom Line

The temptation after April 2026 is to relax. A statute that could plausibly have produced annihilative damages now produces merely serious ones, and the difference is real.

But the requirements a system has to satisfy were never really about the damages multiplier. They were always about six things: a policy that exists, consent captured before collection with a record you can produce, disclosure kept inside its boundaries, data secured properly, retention actually executed, and the whole thing demonstrable to someone skeptical.

Systems built that way were fine before Cothron, survived it, and are fine now. Systems that weren't built that way have simply had their worst case revised downward.

Meanwhile Illinois has added a second regime with a wider reach — one that catches any software scoring or ranking people in an employment context, and holds liability to effect rather than intent.

The engineering answer to both is the same, and it's unglamorous: decide what you actually need to collect, gate it properly, log the decisions, execute the retention, and build the query that reconstructs one person's complete history. Those primitives are cheap in sprint two and expensive in year three.

Book a free consultation → calendly.com/akhil-akoode/ak

A senior engineer reviews every inbound project — not an account manager. We'll look at whether your use case genuinely requires identification, where your consent and retention architecture sits today, and what your third-party disclosure surface actually contains.

Explore: AI development services | SaaS product development | manufacturing | software development company in Illinois | Illinois software costs | case studies

This guide reflects the Illinois Biometric Information Privacy Act as amended by Public Act 103-769, the Seventh Circuit's April 2026 decision in Clay v. Union Pacific Railroad, and House Bill 3773 amending the Illinois Human Rights Act, current as of August 2026. Illinois Department of Human Rights rulemaking under HB 3773 is ongoing. This is engineering guidance, not legal advice — validate your specific obligations with qualified counsel.