How to Write a Biometric Data Disclosure for Fingerprint or Face ID Login

The moment an app lets a user unlock it with a fingerprint or a face scan, it starts processing a category of data that ordinary account information never touches: something a person cannot reset or reissue. A password that leaks gets changed. A fingerprint template that leaks is permanent, which is why a handful of states regulate biometric identifiers as their own category, separate from the general privacy disclosures in a standard Privacy Policy. A biometric data disclosure is the document that answers the specific questions those laws ask: what is being scanned, why, for how long, and who else sees it.

Why a Face ID Login Needs Its Own Disclosure

A general Privacy Policy usually covers biometric data with a single line buried in a longer list of data categories, “we may collect biometric information you provide.” That line does not satisfy a biometric-specific statute, because those laws require detail a generic privacy policy is not built to carry: the specific identifier collected, the exact purpose, a retention schedule with a defined destruction trigger, and in several states, proof that the individual gave informed written consent before collection started, not after. Fingerprint or Face ID login is the single most common feature that triggers this requirement, since it captures a biometric identifier purely to authenticate a login rather than for a medical, security, or research purpose that might already come with its own consent flow.

The State Law Patchwork

There is no federal biometric privacy law, so what a disclosure needs to say depends on where the business operates and where its users are. Illinois has the strictest and most litigated statute; Texas and Washington regulate the same category with a lighter enforcement mechanism; most other states fold biometric identifiers into their general “sensitive data” category under a broader consumer privacy law rather than legislating biometrics on their own.

Illinois’s Biometric Information Privacy Act (740 ILCS 14/) is the one most companies build their disclosure around even outside Illinois, because it is the strictest baseline and the one with the deepest body of litigation, mostly against employers using fingerprint time clocks rather than consumer apps. A 2024 amendment narrowed the private right of action so that collecting the same identifier from the same person by the same method repeatedly counts as one violation rather than one violation per scan, which had previously produced settlements far larger than the underlying harm. Texas’s Capture or Use of Biometric Identifier Act (CUBI) covers similar ground but only the state Attorney General can sue, so there is no equivalent of BIPA’s class-action exposure. Washington’s My Health My Data Act was written mainly for health data but defines “consumer health data” broadly enough to sweep in biometric identifiers used to identify a person, which is why a disclosure aimed at a national user base typically references all three rather than assuming Illinois residents are the only ones who matter.

What the Disclosure Needs to State, Clause by Clause

A biometric disclosure follows a fixed shape regardless of which state law it is written against. Each clause exists to answer one question a regulator or plaintiff’s attorney will ask if a dispute ever gets that far.

Which biometric identifiers are actually collected. Name the specific data type, not the general category: a fingerprint template extracted at login, facial geometry mapped from a selfie, a voice print used for voice-authenticated support calls. “Biometric information” as a bare phrase is not specific enough to satisfy a statute that expects a stated identifier, and it also undersells what the app is actually doing, most Face ID and fingerprint login features never store the raw image or scan at all, only a mathematical template derived from it, which is worth stating explicitly since it is usually true and it materially changes the privacy exposure if the template is ever exposed.

The purpose, stated narrowly. “Identity verification and authentication” is a defensible purpose for a login feature. “Improving our services” or “personalization” is not, because a biometric statute expects the stated purpose to match what the feature actually does, and a purpose broad enough to justify anything is the first thing a regulator flags as inconsistent with the minimal-necessity standard most of these laws build in.

Written consent before collection, not after. This is the clause most first drafts get backwards. The consent has to happen before the fingerprint or face scan is captured, and it has to disclose the specific identifier, the purpose, and the retention period as part of the same consent flow, not as a separate document linked somewhere else in the app. A login screen that captures a Face ID scan and only shows the disclosure afterward, in a settings menu the user may never open, does not meet an informed-consent standard under any of the state laws above.

A retention schedule with a real destruction trigger. “We retain data as needed” is not a retention schedule. A retention clause needs two things: a maximum period (a fixed span like three years, or tied to the length of active use) and a trigger that ends it sooner, most commonly account deletion or a defined period of inactivity, whichever happens first. The clause should also say what destruction actually means, permanently deleting the template using a method that makes it unrecoverable, since a “soft delete” that leaves the data recoverable does not satisfy a statute that requires destruction.

Third-party disclosure, stated as a yes or no. Most login-only implementations never send the biometric template anywhere, the comparison happens on-device or against a single authentication provider, and the disclosure should say so plainly. If a third party is involved (a hosted biometric authentication vendor, for instance), name the category of vendor and confirm that a written agreement prohibits it from using the data for anything beyond the stated purpose. BIPA specifically bars profiting from biometric data in any form, so this clause should also state outright that the data is never sold, leased, or traded.

Security measures and a contact point. A short statement of the safeguards in place, encryption at rest, access controls limited to what the authentication feature needs, and a named contact for questions or a deletion request, closes out the document. This is also where a business operating in Illinois should reference its written biometric data retention policy specifically, since BIPA requires that policy to exist as a standalone document available to the public, not just embedded language inside a disclosure.

Where This Document Lives

A biometric disclosure can be a standalone document linked from the login screen, or a dedicated section inside a broader Privacy Policy, and the state statutes above do not mandate one structure over the other. What they do require is that the biometric-specific detail, the identifier, the purpose, the retention schedule, be present and specific, wherever it sits. A single sentence buried in a long Privacy Policy usually is not that; see Privacy Policy vs Terms and Conditions for how the two documents divide responsibility if a business is trying to decide whether biometric detail belongs in the main policy or in its own disclosure.

The same clauses also apply outside a consumer login flow. Employers who install fingerprint time clocks for staff attendance, still the largest single source of BIPA litigation, need the same written-consent and retention-schedule language, just aimed at employees rather than app users, and that consent process typically gets built into onboarding alongside the rest of an employee handbook rather than handled as a one-off form.

Our Biometric Data Disclosure generator builds the full document from a short set of questions, which identifiers are collected, the stated purpose, the retention period and deletion trigger, and whether the data is shared with third parties, and assembles the written-consent and state-law references (BIPA, CUBI, MHMD) that apply based on the answers, so the retention and consent language line up with what the statute actually expects instead of a generic template that skips the specifics regulators look for first.