When Chrome Holding Company (formerly 23andMe) agreed to pay California $6 million over a breach affecting nearly 7 million people, the settlement revealed something more troubling than the incident itself: a pattern of fundamental privacy program failures that your team might be repeating right now.
The breach didn't happen because of sophisticated attackers exploiting zero-day vulnerabilities. It happened because foundational controls failed. Here's what goes wrong when you're managing sensitive biometric data, and how to fix it before regulators come calling.
Why These Mistakes Keep Happening
Genetic data sits in a regulatory gray zone. It's not protected health information under HIPAA unless collected by a covered entity. It's not financial data under GLBA. Yet it's more permanent and more revealing than either. Your Social Security number can be changed. Your genome cannot.
This ambiguity creates dangerous complacency. Teams treat genetic data like standard PII, applying the same risk ratings and controls they'd use for email addresses. They don't design systems assuming that a single breach could expose family relationships, health predispositions, and ethnic ancestry for millions of people across generations.
The California settlement, combined with an $18 million settlement with 42 other state attorneys general in July, demonstrates that regulators won't accept "we're not technically a healthcare company" as a defense. If you're collecting biometric identifiers, you're being measured against the highest privacy standards, regardless of your industry classification.
Mistake 1: Treating Genetic Data Like Standard PII
Your data classification taxonomy probably has three or four sensitivity levels. Genetic data doesn't fit neatly into any of them.
Why it happens: Most classification frameworks were written before consumer genomics existed. Teams default to existing categories rather than creating new ones, classifying genetic information alongside birthdate or phone number.
The consequence: Controls get calibrated wrong. You apply retention periods designed for transactional data to information that reveals hereditary conditions. You set access permissions based on job function without considering that genetic data can identify relatives who never consented to testing.
The fix: Create a distinct classification tier for biometric identifiers, including genetic data, fingerprints, and facial recognition templates. Map it to the strictest controls in your framework: encryption at rest and in transit, separate authentication requirements, audit logging for every access, and automatic alerts on bulk exports. Under General Data Protection Regulation Article 9, genetic data is a special category requiring explicit consent and heightened protection. Treat it that way in your control matrix, even if you're not EU-based.
Mistake 2: Ignoring the Bankruptcy-Privacy Intersection
When 23andMe filed for bankruptcy in March 2025 and transferred customers' genetic samples to TTAM Research Institute, it exposed a gap most privacy programs don't address: what happens to your data obligations when the company fails?
Why it happens: Privacy impact assessments focus on operational risks (unauthorized access, insider threats, vendor breaches). They rarely model what happens if the organization enters bankruptcy proceedings, where data becomes an asset subject to creditor claims.
The consequence: Consumer rights evaporate. Deletion requests get frozen. Data you promised would never be sold becomes part of the bankruptcy estate, potentially transferred to entities consumers never agreed to trust.
The fix: Document your position on data transfers in bankruptcy within your privacy policy, not buried in terms of service. California's settlement ensures affected consumers can still delete their data and order genetic samples destroyed despite the bankruptcy filing. Build this commitment into your data governance charter: genetic data and biometric identifiers are not transferable assets. If your organization enters bankruptcy, samples will be destroyed and digital records deleted unless consumers explicitly opt into a transfer. Get executive sign-off on this policy while the company is solvent, when it's a theoretical risk rather than a creditor negotiation.
Mistake 3: Failing to Separate Physical and Digital Genetic Data
23andMe sold both saliva samples (physical) and genetic data (digital) to TTAM. Your incident response plan probably covers database breaches. Does it cover what happens to biological samples?
Why it happens: Security teams focus on logical controls. Physical sample management falls to lab operations or research teams who don't think of themselves as handling "data" in the cybersecurity sense.
The consequence: You have comprehensive access logs for who queried the genetic database but no chain-of-custody documentation for the samples those records came from. You can detect unauthorized database exports but not unauthorized sample processing.
The fix: Extend your data lifecycle management to physical specimens. If you're collecting saliva, blood, or tissue samples, document:
- Sample retention periods (align with digital data retention)
- Destruction procedures (witnessed, documented, irreversible)
- Access controls for storage facilities (badge logs, video surveillance)
- Processing authorization workflows (who can order re-testing or additional analysis)
- Consumer rights procedures (how someone requests sample destruction, verification steps, timeline)
Map these physical controls to ISO/IEC 27001 Annex A 7.4 (Physical security monitoring) and A 8.10 (Information deletion). Your auditors should be able to trace a sample from collection through destruction with the same rigor they'd expect for database records.
Mistake 4: Underestimating Cross-Jurisdictional Exposure
The settlement with California was $6 million. The settlement with 42 other states was $18 million. Your breach notification plan probably calculates exposure for your primary operating jurisdiction. Genetic data doesn't respect state lines.
Why it happens: Teams assess breach notification obligations based on where the company is headquartered or where servers are located. They don't model that a single genetic database likely contains residents from all 50 states and multiple countries.
The consequence: You discover mid-incident that you need to comply with 43 different state breach notification laws, each with different timelines, different definitions of personal information, and different requirements for what the notice must contain. Your 30-day remediation plan becomes a 12-month regulatory negotiation.
The fix: Pre-map your genetic database to likely geographic distribution. If you've tested 5 million people, statistically model how many are California residents (triggering California Consumer Privacy Act obligations), how many are EU residents (triggering General Data Protection Regulation's 72-Hour Notification Requirement), how many are in states with biometric privacy laws. Build notification templates for each jurisdiction before you need them. Identify outside counsel in major jurisdictions now, while you have time to negotiate rates and execute engagement letters. Document your analysis in your SOC 2 Type II readiness materials under CC7.4 (incident response procedures).
Mistake 5: Neglecting Consent Durability Through Corporate Changes
When 23andMe transferred data to TTAM Research Institute, consumers who consented to genetic testing by a for-profit company found their samples held by a nonprofit research organization. That's a material change in data controller and processing purpose.
Why it happens: Consent management platforms track opt-ins and opt-outs for current operations. They don't version consent against corporate structure changes, mergers, or purpose modifications.
The consequence: You're processing data under consent that's no longer valid. Under General Data Protection Regulation Article 7, consent must be freely given, specific, informed, and unambiguous. "I consent to 23andMe analyzing my DNA for ancestry reports" doesn't equal "I consent to TTAM Research Institute using my DNA for medical research."
The fix: Implement consent versioning in your Consent Management Platform. Every time you contemplate a corporate transaction (merger, acquisition, bankruptcy, spin-off), trigger a consent review:
- What processing purposes did consumers originally consent to?
- What purposes will the new entity pursue?
- Is the legal basis for processing changing (consent to legitimate interest, consent to legal obligation)?
- Do consumers need to re-consent, or can you rely on compatible purpose expansion?
Document this analysis before the transaction closes. For high-sensitivity data like genetic information, default to re-consent. It's slower and more expensive than assuming consent transfers, but it's defensible when regulators ask why you didn't seek fresh authorization.
Prevention Checklist
Before you collect the first sample:
- Create a distinct data classification tier for genetic/biometric data with controls mapped to General Data Protection Regulation Article 9 special category requirements
- Document your bankruptcy position: genetic data is not a transferable asset without explicit consumer consent
- Extend data lifecycle procedures to physical samples (retention, destruction, chain of custody)
- Model geographic distribution of likely customers and pre-build breach notification templates for major jurisdictions
- Implement consent versioning that triggers review on corporate structure changes
Quarterly:
- Audit access logs for genetic database and physical sample storage facilities
- Review consent records for any processing purpose changes or corporate events
- Test sample destruction procedures (witness, document, verify irreversibility)
- Update your incident response plan with current contact information for multi-state AG coalition
When corporate changes loom:
- Trigger consent review before transaction closes
- Assess whether new entity/purpose requires fresh consumer authorization
- Document legal basis analysis for continued processing
- Prepare consumer notification of ownership/purpose changes
The $24 million in settlements (California plus 42 states) represents about $3.43 per affected person. That's the regulatory cost. The reputational cost of becoming the cautionary tale in genetic privacy is incalculable. Your controls should reflect that you're not just protecting data; you're protecting family trees, medical futures, and ethnic identities that can't be reset when credentials are compromised.
