CCPA deidentified data requirements: safeguards, public commitment and contract terms

What does the CCPA require for data to count as deidentified?#

The CCPA, as amended by the CPRA, requires deidentified data to pass a linkability test and meet three conditions. Under Cal. Civ. Code section 1798.140(m), the information must not reasonably be usable to infer information about, or otherwise be linked to, a particular consumer, and the business holding it must take reasonable measures to ensure it cannot be associated with a consumer or household, publicly commit to keep and use it only in deidentified form and not to reidentify it, and contractually obligate any recipients to comply with the same provisions.

The conditions matter because deidentified information is generally excluded from the CCPA's definition of personal information. Data that meets the standard sits largely outside the law's notice, access, deletion and opt-out duties; data that misses it stays inside them, however carefully the names were removed.

Practitioners often summarize the standard as three parts, and the checklist below follows that structure. The CPRA version replaced older wording that spoke of technical safeguards and business processes, so read the current statutory text and any regulations with counsel before relying on an older checklist.

Reasonable measures: what safeguards look like in practice#

Reasonable measures are the steps that stop deidentified data from being tied back to a person or household. The statute does not list techniques, so the measures are judged against the data and its risks. For operating records such as support tickets, email threads or job notes, the technical side usually means removing direct identifiers, treating quasi-identifiers in free text and testing what remains.

Testing turns a claim into evidence. Mainstream cloud tooling now measures re-identification risk directly; Google's Sensitive Data Protection API, among others, includes k-anonymity, l-diversity, k-map estimation and delta-presence estimation as risk-analysis metrics. Those metrics suit structured fields better than free text, so add a documented human review of sampled records.

The organizational side is easier to forget. Restrict who can see any token-to-identity lookup table, keep it apart from the deidentified copy, log access to both, and ask whether you need the table at all. A business that keeps an easy path back to identities will struggle to show its data cannot reasonably be linked to a consumer.

Public commitment: where and how to make it#

The public commitment is a statement, open to anyone, that the business holds and uses the information only as deidentified data and makes no attempt to reidentify it beyond what the law allows. Most companies place it in their privacy policy, in a section on deidentified and aggregate information.

Timing matters. Publish the commitment before the deidentified data is used, shared or licensed, and keep a dated copy of the version that was live at each release. A commitment added after a buyer's diligence question is better than none, but it leaves a gap in the record for earlier uses.

Illustrative commitment wording, for discussion with counsel only: 'Where we deidentify information, we maintain and use it in deidentified form and do not attempt to reidentify it, except to test whether our deidentification processes work as intended.'

Contract terms: what a data license should say#

Contract terms are the third condition: every recipient of deidentified data must be contractually obligated to comply with the same requirements. In a data license that means the buyer and, through flow-down, the buyer's contractors, cloud providers and any affiliate that touches the data.

Illustrative clause wording, again only a starting point for counsel: 'Licensee shall not reidentify or attempt to reidentify any individual or household from the Licensed Data, shall not combine the Licensed Data with other data for that purpose, and shall impose these obligations in writing on any party it permits to access the Licensed Data.'

• 1A prohibition on reidentifying, or attempting to reidentify, any consumer or household.
• 2A prohibition on linking the data with other information for that purpose.
• 3Flow-down of the same obligations, in writing, to every permitted recipient.
• 4An obligation for the recipient to meet the same conditions itself, including its own reasonable measures and, where counsel advises, its own public commitment.
• 5A duty to tell the supplier promptly about any accidental reidentification, then stop using and delete the affected records.
• 6Permitted-use limits, audit or certification rights, and deletion or return of all copies when the license ends.

Deidentified, pseudonymized or aggregate: which is which?#

Deidentified, pseudonymized and aggregate data are separate categories, and only deidentified and aggregate information generally fall outside the CCPA's definition of personal information. Mixing them up leads to misplaced confidence about what a license can include.

Operating records rarely aggregate well, since their value lies in individual cases: one ticket, one job, one exception and how it was resolved. Licensing work therefore aims at the deidentified category, which is why the three conditions deserve a file of their own.

Illustrative: a software company prepares deidentified support threads#

Illustrative: a fictional B2B software company based in California plans to license several years of Zendesk support conversations with personal details removed. Its general counsel opens a file for each condition before any data moves.

For reasonable measures, the file holds the redaction method, a human review of sampled threads and a note that the token lookup table is destroyed after preparation. For the commitment, the privacy policy gains a section on deidentified information, and a dated copy is saved before release. For contracts, the draft license adds a no-reidentification clause with flow-down, and the buyer's cloud provider is named as a permitted recipient bound by the same terms.

One gap surfaced in review: customers often signed tickets with their full names and job titles, and early samples kept them. The redaction rules were updated, the sample was rerun, and the file was closed only after the new review came back clean.

How SourceX documents the three conditions#

SourceX documents the three conditions inside the SourceX Evidence Packet: the method and review results sit in the privacy record, the location and date of the public commitment sit with licensing rights, and recipient obligations sit with permitted use. Counsel can check every condition in one place.

The work happens in the Preparation and Approval steps of the SourceX five-step transaction, and the supplier approves the prepared dataset before release. Whether a dataset meets the CCPA standard remains a legal judgment for the supplier's counsel.