Deidentified data under US state privacy laws: comparing the standards a dataset must meet

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Where the state definitions agree

The shared core is a linkability threshold plus three holder obligations, and that structure appears in California, Virginia, Texas, Colorado and Nebraska alike [1]. Texas defines deidentified data as data that "cannot reasonably be linked to an identified or identifiable individual, or a device linked to that individual" [1]. Virginia uses materially the same formula and then requires the controller in possession to take reasonable measures against association with a natural person, publicly commit to keep the data deidentified and not attempt reidentification, and contractually obligate recipients to comply [1]. Texas section 541.106(a) repeats those three duties almost word for word [1].

For an AI buyer, the practical consequence is that deidentification is a status the holder maintains, not a property stamped on a file. When a supplier releases a deidentified extract and you take it into a training pipeline, you become a "recipient" whom the supplier must bind by contract, and in most of these states you also become a controller "in possession" with your own three duties. Expect your license to carry reidentification prohibitions downstream, and expect them to reach your vendors, annotators and cloud processors.

Where the standards diverge, and why it matters for training data

The deltas are small in wording but large in operational effect, and practitioners comparing the statutes find them in four places [1]:

• Unit of identifiability. The CCPA test covers information that cannot reasonably be used to infer information about, or be linked to, a particular consumer, and its reasonable-measures prong extends to association with a consumer or household [2]. Virginia and Texas speak of an individual or a device linked to that individual [1]. A household-level identifier, such as a service address hash or a shared account ID in utility or telecom records, can pass the Virginia or Texas test and still fail California.
• Reidentification testing. The CCPA public commitment has been described as allowing the business to attempt reidentification only to test whether its own deidentification process works [2]. Write that exception into your license explicitly if your red team will run linkage attacks; do not assume another state's text gives you the same room.
• Monitoring duty. Virginia requires a controller that discloses pseudonymous or deidentified data to exercise reasonable oversight of the contractual commitments and to take appropriate steps on breach [1]. Colorado's act is generally read to impose a similar oversight duty [1]. Suppliers subject to those duties will want audit, attestation or notice rights against you.
• Recipient contract wording. Nebraska section 87-1117 expressly requires controllers to contractually obligate recipients of deidentified data [3]. Some statutes require recipients to comply with "this chapter," others with the deidentification provisions only, which changes what your flow-down clause must promise.

If you need the single-state view, the owner explainers for the Virginia Consumer Data Protection Act, the Colorado Privacy Act and the Texas Data Privacy and Security Act cover each law on its own terms. The California-specific buyer obligations are covered in CCPA/CPRA deidentified data obligations for buyers.

Comparison table: deidentified and pseudonymous data elements by state

The table below summarizes the elements counsel usually map before signing; verify each cell against the current statute text, because subsection lettering and amendments shift [1].

Two observations follow. First, pseudonymous data is not deidentified data in Virginia or Texas: it remains personal data, and the carve-out only switches off listed consumer rights and controller duties when the controller can show the key is held separately [1]. Second, California defines pseudonymization but offers no equivalent carve-out, so a tokenized dataset that is comfortable in Austin is simply personal information in Sacramento. For the EU counterpart of this distinction, see anonymised versus pseudonymised training data under GDPR.

The highest-common-denominator standard for one license

One license can cover a multi-state dataset if it adopts the strictest version of each element rather than citing each statute separately. In practice that means a household-inclusive linkability test (California) [2], a reidentification ban with a narrowly drawn testing exception [2], recipient flow-down that reaches every subprocessor (Nebraska, Virginia, Texas) [1][3], and cooperation with the supplier's oversight duty (Virginia) [1]. It also means treating pseudonymous tokens as personal data unless the token map stays with the supplier and never crosses the delivery boundary.

The state statutes do not prescribe a method, so many buyers borrow a measurable benchmark. HIPAA offers two: Safe Harbor's enumerated identifier removal and Expert Determination's documented, statistically supported very-small-risk finding [4]. Neither is required for non-health consumer records, but an Expert Determination style report gives counsel something concrete to rely on when a regulator asks what "reasonable measures" meant. The trade-offs are covered in HIPAA Safe Harbor versus Expert Determination.

Contract flow-down checklist

Illustrative example: invented to show structure; it does not describe an available dataset.

• Definition clause uses the household-inclusive CCPA formulation, not the individual-only one.
• Licensee commits publicly (for example in its privacy notice or model documentation) to keep the data deidentified and not attempt reidentification.
• Reidentification-testing exception is limited to evaluating the deidentification method, logged, and results shared with the supplier.
• Every processor, annotation vendor and cloud host is bound to the same terms in writing before access.
• Linkage with other datasets that could reidentify (CRM exports, enrichment vendors, public records) is prohibited without written approval.
• No token map, salt or crosswalk table is delivered; if one must exist, it stays with the supplier.
• Supplier receives audit or attestation rights sufficient for its oversight duty.
• Breach of the reidentification ban triggers notice, cessation and remediation obligations.
• Model outputs that reproduce identifiers are treated as a reidentification incident.

Failure modes in real business records

Statutory deidentification usually fails on the data, not the contract. Free text in support tickets, sales notes and engineering issues carries names, signatures, account numbers and rare-event descriptions that structured masking misses; see indirect identifiers in business text. Joins are the second failure: two individually deidentified extracts can be linked on timestamps, order totals or ZIP-plus-date combinations, which is why multi-system packaging needs a linkage review, as described in packaging linked records from multiple systems.

The third failure is the model itself. A model trained on deidentified records can still memorize and emit rare strings, which a regulator could view as the licensee reidentifying data it committed not to reidentify; training-data extraction and memorization risk covers testing for it. The fourth is device identifiers: Virginia and Texas both count a device linked to an individual [1], so hashed advertising IDs, IMEIs and stable cookie IDs keep a record identifiable.

Illustrative delivery manifest entry

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "extract_id": "support-tickets-2025Q4-deid",
  "states_of_origin": ["CA", "VA", "TX", "CO", "NE"],
  "standard_applied": "highest_common_denominator_v2",
  "linkability_unit": ["individual", "household", "device"],
  "removed_fields": ["customer_name", "email", "phone", "account_number", "service_address", "device_id"],
  "transformed_fields": {"ticket_opened_at": "truncated_to_month", "zip": "3_digit_prefix"},
  "free_text_method": "NER redaction plus rule-based account-number masking",
  "token_map_location": "supplier_only",
  "sample_review": {"records_checked": 500, "residual_identifiers_found": 2, "action": "rule added, extract regenerated"},
  "recipient_terms_ref": "License schedule C, deidentification covenants"
}

The useful fields for counsel are states_of_origin, linkability_unit and token_map_location, because those three determine whether the California household test and the Virginia and Texas pseudonymous carve-outs are even in play.

How SourceX handles deidentification in sourced datasets

SourceX sources operational datasets from US companies on request and manages the licensing process. Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Health records require HIPAA de-identification by Safe Harbor or Expert Determination, and diligence materials on source, rights, preparation and allowed use are prepared per dataset. Buyers can start by describing the records and states involved on the SourceX buyer page.

For a quick read on which state laws a supplier's records may implicate, the privacy rules checker gives a starting map, and the Oregon Consumer Privacy Act explainer covers another state in the same family. The broader regulatory picture is in the AI training data compliance hub and the privacy cluster guide.

Licensing multi-state deidentified data for AI training

SourceX looks for US businesses that hold the data you describe, assesses data and licensing permissions, and nothing is contracted until a supplier agrees. Every release is approved by the supplying company and delivered through private, access-controlled workflows after an executed agreement. Describe the records, states and intended uses on the SourceX buyer page.