CCPA/CPRA deidentified data: the obligations a buyer inherits when licensing California data

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

What 1798.140(m) actually requires, condition by condition

The current definition has a substantive test and three conditions, and all three attach to "the business that possesses the information," which after delivery includes you [1]. The substantive test is that the information "cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer." The conditions then layer conduct on top of that technical state.

• Reasonable measures. The possessing business must take reasonable measures to ensure the information cannot be associated with a consumer or household [1]. Household is broader than individual: a support ticket stripped of names but keeping a full service address still points at one home.
• Public commitment. It must publicly commit to maintain and use the information in deidentified form and not to attempt reidentification, with a narrow exception for testing whether its own deidentification process works [1][3].
• Contractual flow-down. It must contractually obligate any recipients to comply with all provisions of the subdivision [1]. That includes your vendors, labeling contractors, cloud evaluation partners and any affiliate that receives a copy.

Deidentified consumer information sits outside the CCPA's definition of personal information [1]. The practical consequence is that the exclusion is conditional and continuing: if any holder in the chain stops meeting the conditions, counsel should assume the records can revert to personal information in that holder's hands.

Why older CCPA summaries mislead buyers

The 2018 text and the CPRA text are different tests, so a vendor memo or privacy notice written before 2023 may describe the wrong one [4]. The original CCPA required technical safeguards, business processes prohibiting reidentification, processes to prevent inadvertent release, and no reidentification attempt, and it sat under a different subdivision letter [2][4]. The recipient-contract condition and the public commitment are CPRA-era features [3].

Two consequences follow for diligence. First, check which definition a supplier's "deidentified" representation cites; a reference to 1798.140(h) is a dating signal. Second, the CPRA's temporary exemptions for employee and business-to-business data were set to lapse on January 1, 2023 [2], so HR records, Slack exports and sales-call notes about California employees and contacts now need the same analysis as consumer data. Bills continue to touch the personal information exemptions (for example SB 435 in the 2025–2026 session), so confirm the current text as of October 2026 rather than relying on a cached copy [6].

Which obligations land on the buyer, and which stay with the supplier

The supplier carries the deidentification work up to delivery; the buyer inherits the conduct conditions for as long as it holds the data [1][3]. Splitting them cleanly avoids the common failure where both sides assume the other made the public commitment.

The buyer column is where AI programs most often fail. Annotation vendors, red-team contractors and hosted evaluation services are "recipients" in plain terms, and a standard data processing addendum does not by itself oblige them to comply with 1798.140(m), which requires recipients to be bound to all of its provisions [1].

Writing the flow-down clause into the license

A license that satisfies the flow-down condition names the deidentification obligations expressly [1][5]; making them survive delivery, onward transfer and termination is good practice rather than a statutory term. Generic confidentiality language is not a substitute because it says nothing about reidentification or public commitments.

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

Section 7 - Deidentified Data (illustrative clause checklist)
7.1  Licensee shall maintain and use the Licensed Records only in deidentified
     form as defined in Cal. Civ. Code 1798.140(m) and comparable state law.
7.2  Licensee shall not attempt to reidentify any Licensed Record, including by
     linkage to Licensee-held data, third-party enrichment, or model-assisted
     inference, except testing of deidentification expressly approved in writing.
7.3  Licensee shall publicly commit to 7.1 and 7.2 and provide the URL on request.
7.4  Licensee shall bind each onward recipient (contractors, labelers, hosting
     and evaluation providers) to terms no less protective than 7.1-7.5.
7.5  Licensee shall notify Licensor within [N] days of discovering that any record
     appears reidentifiable, quarantine it, and cooperate on remediation.
7.6  Obligations survive termination for any retained records, derived features
     and stored embeddings.

Clause 7.5 is not in the statute; it is a buyer-side control that gives both parties a way to restore the "reasonable measures" condition when a residual identifier surfaces in a transcript or free-text field. Clause 7.6 matters because derived artifacts such as embeddings and cached tokenized shards are copies of the records for most practical purposes.

Pseudonymized records are not deidentified records

A dataset that swaps names for stable tokens is pseudonymized: the CCPA defines pseudonymizing as processing that stops attribution only while the additional information is kept separately, and its personal information definition covers unique and persistent identifiers, so counsel should treat such records as personal information rather than deidentified [1]. Stable customer IDs, hashed emails and consistent ticket requester tokens let a holder build longitudinal profiles, which is exactly the linkage 1798.140(m) excludes.

For training data this creates a design choice. Longitudinal structure (the same customer across many tickets) helps models learn escalation and resolution patterns, yet it raises linkability. Ask the supplier whether tokens are salted per release, whether the mapping table is destroyed or retained, and whether the token space is shared with any other dataset you license. Indirect identifiers in free text are covered in indirect identifiers in business text, and the redaction tooling side in PII redaction for LLM training data.

Model training, memorization and the reasonable-measures test

Training on deidentified records does not end the buyer's duties, because the conditions apply for as long as the business possesses the information [1] and a model that memorizes residual identifiers can become a route to association. Counsel should treat reasonable measures as covering the full pipeline: corpus, checkpoints, retrieval indexes and eval logs.

Practical controls include deduplication before training, canary strings to detect verbatim regurgitation, output filters for phone, account and address patterns, and keeping retrieval-augmented generation indexes behind the same access policy as the source records. See training-data extraction and memorization risk and retrieval-time privacy controls for RAG for test designs.

Your public commitment also creates FTC exposure. FTC staff have warned that quietly adopting more permissive data practices, such as using data for AI training contrary to earlier privacy commitments, may be unfair or deceptive [8]. Draft the commitment to match what your training and evaluation pipelines actually do.

Where the CCPA test stops and other regimes take over

The CCPA standard is one of several, and records often fall under a stricter or different one [3]. Protected health information follows HIPAA's 45 CFR 164.514 de-identification standard, either Safe Harbor or Expert Determination, not the CCPA test [7]. Other states copy the California structure: Nebraska, for example, requires controllers to contractually obligate recipients of deidentified data to comply [5].

A multi-state license is simpler if it adopts the strictest common elements: reasonable measures, a public commitment and recipient flow-down. The full comparison is in deidentified data under US state privacy laws, and the legal-status vocabulary in de-identified, anonymized and pseudonymized definitions. For health data specifically, read HIPAA Safe Harbor vs Expert Determination.

A buyer diligence checklist for California-origin records

Before signing, collect evidence that each condition was met at the supplier and can be met in your environment [1][3]. The de-identification evidence package checklist covers documents in depth; the items below are specific to the CCPA test.

• Which statutory definition the supplier relies on, cited by current subdivision (m), not a pre-CPRA letter [1][4].
• Whether the records include California employees or business contacts, now that the temporary exemptions have lapsed [2].
• The deidentification method, fields transformed, and how household-level identifiers (address, device, account) were handled.
• Whether tokens are stable across releases and whether a key exists.
• The supplier's public commitment URL and the date captured.
• The flow-down clause text and a list of your onward recipients bound by it.
• Your own public commitment, reviewed against actual training and evaluation practice [8].
• Whether any record falls under HIPAA or another sector regime instead [7].

SourceX rights-reviews every dataset for ownership and consents and prepares diligence materials per dataset covering source, rights, preparation and allowed use, which gives counsel a starting file for this checklist; see how that works for buyers sourcing licensed business records. 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. For the seller-side licensing question, read CCPA and licensing business data; for terms, see the data anonymization glossary entry.

Licensing deidentified California business records for AI

SourceX sources operational datasets from US companies on request and manages licensing through Find, Assess, Agree, Transact and Manage, with every dataset delivered under a license defining records, uses, term and delivery. SourceX looks for US businesses that hold the described data, every release is approved by the supplying company, and a request does not guarantee a match. Describe the records you need at SourceX for buyers.

Related reading: the privacy and de-identification buyer's guide, AI training data procurement, and employee communications in training data.