Biometric Data Compliance: GDPR, BIPA, and CCPA for Engineering Teams

If your product captures a face, a fingerprint, a voiceprint, or anything else that can be used to identify a specific person, you're not subject to one privacy law — you're subject to a patchwork of them, and they don't all say the same thing. The European Union's GDPR, Illinois's Biometric Information Privacy Act (BIPA), and California's CCPA/CPRA each define "biometric data" slightly differently, impose different obligations, and carry different consequences for getting it wrong.

The good news is that these regimes, while not identical, overlap enough that a single, well-designed engineering posture satisfies most of what each one requires. This post compares the three, then lays out that posture concretely.

Three regimes, three different starting points

GDPR (European Union) treats biometric data as "special category" data under Article 9 — but only when it's "processed through a specific technical means allowing the unique identification" of a person. A photo sitting in storage isn't automatically special category data; a photo that's run through face recognition and linked to an identity is. This is a processing-based trigger: the same image can be regulated differently depending on what you do with it.

BIPA (Illinois) takes a broader, capture-based approach. It covers "biometric identifiers" — scans of face geometry, fingerprints, voiceprints, retina/iris scans — from the moment they're captured, regardless of what you later do with them. Critically, BIPA requires written consent before collection, not after, and it's the only one of the three with a private right of action: individuals can sue directly, and statutory damages of $1,000–$5,000 per violation have produced very large class-action settlements.

CCPA/CPRA (California) classifies biometric information as "sensitive personal information" within its broader consumer privacy framework. Unlike BIPA, it doesn't require opt-in consent by default — it requires notice and gives consumers the right to opt out of sale/sharing and to limit use of sensitive data to what's necessary for the service. Enforcement runs through the California Privacy Protection Agency and the Attorney General, not private lawsuits (with narrow exceptions for data breaches).

The practical upshot: BIPA is the strictest on consent timing, GDPR is the strictest on processing limits and documentation, and CCPA is the strictest on giving consumers ongoing control. A system designed to satisfy BIPA's opt-in requirement and GDPR's data minimization and documentation requirements will, in most cases, comfortably clear CCPA's bar too.

Building for the strictest regime

Rather than maintaining three separate compliance postures (one per law, with conditional logic based on user location), most engineering teams are better served by a single posture that's strict enough to satisfy all three. The checklist:

1. Opt-in consent before capture, not after. Don't capture a face image and ask for consent on the next screen — get explicit, affirmative consent before the camera or upload component even activates. This satisfies BIPA's "before collection" requirement and GDPR's requirement for a valid Article 9 legal basis, and exceeds CCPA's notice-based requirement (which is a lower bar).

// Consent must be recorded BEFORE the capture UI is shown
async function startBiometricCapture(userId: string) {
  const consent = await consentStore.get(userId, "biometric_capture");
  if (!consent || !consent.granted) {
    return { status: "consent_required" };
  }
  return { status: "ready", consentTimestamp: consent.grantedAt };
}

2. A published, enforced retention policy. BIPA requires a written retention and destruction schedule. GDPR requires retention to be limited to what's necessary for the stated purpose. CCPA requires the same in substance. The fix is the same for all three: define a retention period per data category, and enforce it in code, not just in a policy document.

// A scheduled job, not just a policy document
async function purgeExpiredBiometricData() {
  const cutoff = new Date(Date.now() - RETENTION_DAYS * 24 * 60 * 60 * 1000);
  const expired = await db.biometricRecords.findMany({
    where: { capturedAt: { lt: cutoff } },
  });
  for (const record of expired) {
    await deleteBiometricRecord(record.id);
    await auditLog.record({ recordId: record.id, action: "auto_purged", reason: "retention_expired" });
  }
}

3. Data minimization — don't store what you don't need. If your use case is a one-time identity check (verify this selfie matches this ID, once, at signup), there's frequently no need to retain the raw images at all after the check completes. As covered in our post on face anonymization and GDPR, the safest biometric data is the data you never persist in the first place. Quantilence's APIs don't store images beyond the request for exactly this reason — your retention obligations only apply to what you choose to keep afterward.

4. Honor deletion requests across every system that has a copy. GDPR's right to erasure, CCPA's right to delete, and BIPA's destruction requirements all converge on the same operational requirement: when a user asks for their biometric data to be deleted, it needs to actually be gone — including from backups, logs, and any downstream system (analytics, ML training sets, fraud-detection galleries) that received a copy. This is often the hardest part to implement well, because it requires knowing everywhere biometric data flows, not just where it's primarily stored.

5. Audit logs for every capture, use, and deletion. All three regimes lean on accountability — being able to demonstrate what was done, when, and under what consent. A structured audit log (who, what, when, legal basis) turns "we believe we're compliant" into "here's the record."

await auditLog.record({
  userId,
  action: "biometric_capture",
  dataType: "face_image",
  consentId: consent.id,
  legalBasis: "explicit_consent",
  purpose: "identity_verification",
  timestamp: new Date(),
});

Where the three regimes actually diverge

The unified posture above covers the common ground, but a few differences are worth knowing about explicitly because they affect specific decisions:

Geographic scope isn't always obvious. GDPR applies based on whether you're processing data of people in the EU, regardless of where your company is based. BIPA applies to biometric data of Illinois residents. CCPA applies to California residents (and businesses meeting certain size/revenue thresholds). A US-only company with no EU users can still be subject to BIPA if any users are Illinois residents — which, for a consumer-facing product, is hard to rule out without geographic controls.

BIPA's private right of action changes the risk calculus. Under GDPR and CCPA, a compliance gap typically becomes a regulatory investigation — slow, and often resolved through guidance or settlements with the company as a whole. Under BIPA, a compliance gap (most commonly, missing or inadequate written consent) can become a class action, because any affected individual can sue, and statutory damages apply per violation — which in practice can mean per scan, per user. This is the single biggest reason BIPA compliance specifically deserves its own checklist item, not just "we're GDPR compliant so we're fine."

Other US states are filling in the patchwork. Illinois and California aren't the only US states with biometric-specific provisions — Texas's Capture or Use of Biometric Identifier Act (CUBI) and Washington's biometric privacy law impose similar consent and retention requirements, generally with state attorney general enforcement rather than private rights of action. The trend across US state privacy laws (Virginia, Colorado, and others) has been toward classifying biometric data as "sensitive" and requiring opt-in consent for its processing — which is consistent with, and covered by, the posture described above.

Common pitfalls

Treating "we're GDPR compliant" as sufficient for US users. GDPR compliance covers a lot of the same ground as BIPA and CCPA, but BIPA's pre-collection written consent requirement and private right of action are specific enough that a GDPR-oriented consent flow (often a cookie-banner-style "I agree" after the fact) doesn't necessarily satisfy it.

Storing biometric data "temporarily" without a real deletion mechanism. "Temporary" storage that has no automated deletion path tends to become permanent storage — either because the deletion job was never built, or because some downstream consumer (a log aggregator, a backup, an analytics export) holds a copy nobody accounted for.

Conflating identity verification with biometric data collection for BIPA purposes. Some teams assume that because their use of facial data is a one-time identity check (not building a "biometric database" in the colloquial sense), BIPA doesn't apply. BIPA's definition of "biometric identifier" is based on what's captured, not on whether you build a persistent database — a single face scan, captured without prior written consent, can itself be a violation regardless of retention.

Assuming your vendor's compliance covers your use. A vendor that processes images without storing them (as Quantilence does) reduces your retention and deletion burden significantly, but it doesn't eliminate your obligation to obtain consent before sending a user's biometric data to that vendor in the first place — that responsibility sits with whoever controls the data collection from the user, which is you.

Frequently asked questions

Does this apply if we never store the images, only derived embeddings or scores? Generally yes. GDPR's Article 9 and BIPA's "biometric identifier" definitions are written broadly enough to cover derived data that can be used to identify someone, not just raw images — an embedding vector that enables re-identification is treated similarly to the image it was derived from. CCPA's "biometric information" definition is similarly broad. Don't assume that discarding the raw image after generating an embedding removes you from scope if the embedding itself is retained and identifying.

Do we need separate consent flows for EU vs. US users? You can use a single, opt-in, pre-capture consent flow that satisfies BIPA's strictest requirement globally — this tends to be simpler to build and maintain than geographically conditional consent logic, and it doesn't create a worse experience for users in jurisdictions with lighter requirements (an opt-in consent screen is a small addition regardless of where the user is).

What counts as a "legal basis" under GDPR if we don't want to rely on consent? Consent is the most common basis for biometric processing, but GDPR Article 9 also permits processing necessary for specific purposes like substantial public interest or legal claims, in narrow circumstances. For most commercial identity-verification and fraud-prevention use cases, explicit consent remains the practical basis — the other Article 9 exceptions are narrow and fact-specific enough that relying on them without legal review is risky.

How does this interact with anonymization? Anonymization is the other lever, covered in depth in our GDPR-focused post: if biometric data is irreversibly anonymized (faces blurred beyond re-identification, originals discarded), it generally falls outside the scope of all three regimes, because there's no longer "biometric data" capable of identifying a person. For use cases where identifiable faces aren't actually needed downstream — training data, public imagery, analytics — anonymization can be simpler than building a full consent/retention/deletion compliance posture.

Conclusion

GDPR, BIPA, and CCPA don't agree on everything, but they agree on enough: get consent before you capture biometric data, don't keep it longer than you need to, give people a way to have it deleted, and keep a record of what you did. Build that posture once, enforce it in code rather than policy documents, and you'll find that "are we compliant with the law in this specific jurisdiction" becomes a much easier question to answer — for whichever jurisdiction asks next.

Quantilence processes images for the duration of the request only, doesn't retain biometric data by default, and provides audit-ready request logs — reducing your compliance surface to the consent and retention decisions you make on top. Explore our products →