Definitions and comparisons
What counts as deidentified data under the CCPA?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Under the CCPA, deidentified data is information that cannot reasonably be linked to a particular consumer, held by a business that meets three conditions: reasonable technical measures, a public commitment not to reidentify, and contracts binding every recipient to the same rules. If any one condition is missing, treat the records as personal information.
Key takeaways
- Deidentified status under the CCPA depends on the data and on the business's own conduct, not on scrubbing alone.
- All three conditions apply together: reasonable measures, a public commitment and contractual obligations on every recipient.
- Free text in support tickets, CRM notes and call transcripts is where most identifying details survive automated removal.
- Employee and business contact records need the same analysis, because the CCPA's temporary exemptions for them expired.
- A data license without a no re-identification clause can undo deidentified status for the records it covers.
What does the CCPA say deidentified data is?#
The CCPA defines deidentified data as information that cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer. The definition sits in California Civil Code section 1798.140(m), as amended by the CPRA, and it adds three conditions that the business holding the data must meet.
That structure matters for a company preparing records for an AI license. The test is not only about what the file looks like after cleanup. It also asks what the business has promised the public and what it has required of anyone who receives the file. A carefully scrubbed export can still fall short if the license that carries it says nothing about reidentification.
Information that meets the definition is generally treated as outside the CCPA's definition of personal information, which is why the term carries so much weight in data licensing. Information that misses any element stays personal information, with the notice, rights and contract duties that follow.
The three-part test as a working checklist#
The three-part test is easiest to manage as a checklist with an owner and an evidence record for each element. Counsel decides whether the elements are met; operations and IT produce the proof.
Treat the rows as cumulative. A strong technical process does not cure a missing public commitment, and a well-drafted license does not cure records that still carry customer names in free text.
| Element | What it generally requires | Evidence to keep | Common gap |
|---|---|---|---|
| Reasonable measures | Steps that ensure the data cannot be associated with a consumer or household | Removal method, field list, sampled review results, residual risk notes | Names removed from fields but left in ticket bodies and email signatures |
| Public commitment | A public statement that the business keeps and uses the data only in deidentified form and will not try to reidentify it | Published privacy notice language and the date it went live | The commitment exists in an internal policy but in no public notice |
| Contractual obligation | Every recipient is contractually bound to comply with the same requirements | Signed license with a no re-identification clause and flowdown terms | The clause binds the licensee but not its contractors or affiliates |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why removing names is not the same as deidentifying#
Removing names is a start, but deidentification under the CCPA turns on whether the remaining data can reasonably be linked back to a person or household. Operational records carry identifying details in places a column-level scrub never touches.
NIST's report on de-identifying personal information notes that researchers have shown some de-identified data can be re-identified. In business records the risk usually comes from combinations: a job address plus a date and an equipment model, or a support ticket that quotes a customer's own description of their account. Each source below needs a documented handling rule, not just a pass through a detection tool.
- Ticket and chat bodies in Zendesk or Intercom, where customers type names, phone numbers and order numbers.
- Email signatures, forwarded threads and quoted replies inside CRM activity logs in Salesforce or HubSpot.
- Call transcripts where agents read back addresses or confirm identity.
- Attachments such as invoices, photos and screenshots with embedded text.
- Rare combinations of job type, location and date that point to one household.
- Internal account keys that map back to a customer table the company still holds.
What the public commitment and the contracts look like#
The public commitment is a statement, usually in the privacy notice, that the business maintains and uses deidentified information only in that form and will not attempt to reidentify it. An internal data-handling policy on its own does not meet this element, because the commitment has to be public.
Check the notice that covers the people in the records, not just the website visitor notice. A software company's notice may cover product users but say nothing about support contacts or prospects. Record when the language was published and keep prior versions, because diligence teams on both sides of a license will ask. The commitment also has to match practice: if an analytics team routinely joins the deidentified archive back to the customer table, the label is weak.
The contractual element means every recipient must be obligated to comply. For an AI data license, that is the licensee, and in practice it should also reach the licensee's contractors, hosts and any affiliate that touches the files. Read the definitions section closely; if 'Licensee' is defined narrowly, affiliates that receive the data may sit outside the obligation.
Deidentified, pseudonymized and aggregate data compared#
Deidentified, pseudonymized and aggregate data are different categories, and mixing them up is a common mistake in licensing discussions. The practical difference is whether anyone, including the company itself, can link the records back to a person.
AI developers usually want record-level data, because a single resolved ticket or job record is what shows a model how the work gets done. That tends to rule out aggregate data and makes deidentification, not pseudonymization, the target for licensed packages.
| Category | What it means in practice | Typical status under privacy laws |
|---|---|---|
| Deidentified | Identifiers removed or generalized, public commitment made, recipients bound by contract | Generally outside personal information if every condition is met |
| Pseudonymized | Names replaced with codes, but a key that maps codes to people still exists | Generally still personal information, because the key allows relinking |
| Aggregate | Counts, averages and trends about groups, with no record-level rows | Generally outside personal information if individuals cannot be singled out |
| Raw export | Records as they sit in the source system | Personal information wherever people are identifiable |
Illustrative: a software company prepares its support archive#
Illustrative: a fictional vertical software company wants to license several years of resolved Zendesk tickets linked to Jira issues. Its first export removes requester names and emails, and the team assumes the archive is now deidentified.
Counsel's review finds three gaps. Ticket bodies still contain customer phone numbers and site addresses, the privacy notice never mentions deidentified data, and the draft license binds the licensee but not its annotation contractor. The company adds free-text redaction with sampled human review, publishes a deidentification commitment in its notice, and adds a no re-identification clause with flowdown terms. Only then does it treat the package as deidentified for licensing.
How SourceX handles deidentification in a transaction#
SourceX treats deidentification as part of the Preparation step in the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Personal and confidential details are removed before anything is shared with a buyer, and the supplier approves the prepared package.
The privacy record in the SourceX Evidence Packet documents the removal method and review results, and the license carries the contractual terms. Whether a given package meets the CCPA definition is assessed deal by deal with the supplier's counsel.
Frequently asked questions
Does deidentified data need consent before it is licensed?
Information that meets the CCPA definition is generally outside personal information, so consumer rights tied to personal information generally do not attach to it. Consent can still matter for other reasons, such as call recording laws, customer contracts, confidentiality terms or other states' privacy laws. Those questions are assessed separately with counsel.
Do employee and business contact records need the same treatment?
Generally yes. The CCPA's temporary exemptions for employee and business-to-business personal information expired on January 1, 2023, after the legislature did not extend them. California regulators also opened preliminary rulemaking in April 2026 on how the CCPA applies to employee, applicant and contractor information, so check current rules before relying on older guidance.
Do other states use the same deidentification test?
Many state privacy laws use a similar structure of technical measures, a public commitment and contractual controls, but the wording and scope differ. A package licensed nationally should be checked against each state law that may apply to the people in the records, not only California's.
Is hashing an email address enough to deidentify it?
Usually not on its own. A hashed email can often be matched by anyone who hashes the same address, and the business that created the hash can relink it. Hashing is closer to pseudonymization, which generally leaves the data as personal information.
Can anyone test whether the prepared data can be reidentified?
Some licenses allow tightly controlled testing by the supplier or an independent reviewer to confirm the removal process works. A licensee running its own attempts would usually breach a no re-identification clause unless the contract expressly permits it, so any testing right should be written in with clear limits.
Sources
- Under Cal. Civ. Code 1798.140(m), as amended by the CPRA, information is deidentified only if it cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer, and the business takes reasonable measures, publicly commits not to reidentify it, and contractually obligates recipients to comply. Source
- The California legislature did not extend the CCPA employee and business-to-business personal information exemptions, so they expired on January 1, 2023. Source
- The California Privacy Protection Agency initiated preliminary rulemaking on April 20, 2026 on how the CCPA applies to personal information of employees, job applicants and independent contractors. Source
- NIST Interagency Report 8053, De-Identification of Personal Information, notes that researchers have shown some de-identified data can be re-identified. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.