Privacy and preparation
Is pseudonymized data still personal information under the CCPA?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Yes. Pseudonymized data generally remains personal information under the CCPA, because a token or hash still relates to a consumer the business can identify with information it holds. Data leaves the law's scope only when it meets the separate deidentified standard, which adds safeguards, a public commitment not to reidentify and contract terms for recipients.
Key takeaways
- Under the CCPA, pseudonymization works as a safeguard, not as a way out of the definition of personal information.
- Hashed emails, customer tokens and consistent IDs usually remain personal information because they can be linked back.
- Only data that meets the deidentified standard generally falls outside the CCPA's scope.
- Pseudonymization still lowers risk and is often a first step toward a deidentified licensing package.
- Whether a specific dataset is personal information is assessed deal by deal with counsel.
The short answer: pseudonymized data usually stays in scope#
Pseudonymized data usually stays personal information under the California Consumer Privacy Act. The CCPA defines personal information broadly, covering information that identifies, relates to or could reasonably be linked with a consumer or household, and it names unique and persistent identifiers among its examples. A customer token that the business can map back to a name fits that description.
Pseudonymization changes how directly a record points to a person, not whether it does. That is why practitioners generally manage pseudonymized records as personal information and reserve out-of-scope treatment for data that meets the deidentified standard.
| Technique | What it does | Usual CCPA status |
|---|---|---|
| Hashing emails or phone numbers | Replaces each value with a consistent hash | Personal information; hashes can be matched |
| Tokenizing customer IDs with a retained key | Replaces IDs; the business can reverse it | Personal information |
| Replacing names with role labels in text | Removes direct names from conversations | Depends on what else remains in the record |
| Aggregating to counts by region or month | Removes individual-level rows | Often outside scope if no group can identify a person |
| Meeting the deidentified standard | Combines technical, organizational and contractual controls | Generally outside the definition of personal information |
What the CCPA means by pseudonymize#
The CCPA's definitions section, Cal. Civ. Code § 1798.140, describes pseudonymizing as processing personal information so it can no longer be attributed to a specific consumer without additional information, which is kept separately and protected by technical and organizational measures. Anyone who has worked with GDPR will recognize the idea.
The key phrase is without additional information. That additional information still exists, usually in the business's own systems, and the business can use it. A lookup table that maps tokens to customer records, or a key used for deterministic encryption, keeps the link alive.
The methods themselves are mainstream. Google's Sensitive Data Protection API, for example, supports deterministic encryption and format-preserving encryption, which replace values with consistent tokens that the key holder can reverse. They are useful tools, but while the key exists their output is pseudonymized, not deidentified.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why a token or hash usually still identifies someone#
A token or hash usually still identifies someone because it is stable and linkable. The same customer gets the same token in every ticket, order and call, so a recipient can assemble a history over time, and anyone holding the original values can recompute a hash and match it.
For licensing packages built from operational records, the free-text problem matters most. A support conversation where the customer ID is tokenized but the customer signs off with a full name and phone number is not pseudonymized in any useful sense.
- Consistent tokens let records be grouped into one person's history.
- Hashes of emails and phone numbers can be matched against other lists.
- Free text around the token often names the person, their employer or their address.
- Quasi-identifiers such as location, dates and job details can narrow a token to one person.
- The business itself keeps the key or the mapping table.
What it takes for data to count as deidentified#
Data generally counts as deidentified under the CCPA only when it cannot reasonably be used to infer information about, or be linked to, a particular consumer, and the business backs that up with commitments. Under § 1798.140(m), as amended by the CPRA, the business must take reasonable measures to ensure the data cannot be associated with a consumer or household, publicly commit to keep and use it only in deidentified form and not try to reidentify it, and contractually obligate any recipients to comply with those same provisions.
The third element matters most in a licensing deal. A license that omits a no-reidentification clause and a flow-down to the buyer's own contractors may leave the package short of the standard, however well the records were scrubbed.
Counsel should confirm the exact elements and wording against the current statute and regulations. Much of the published commentary on this question was written soon after the CCPA was amended, so check for newer regulations and enforcement activity before relying on it.
| Element | What it means in practice |
|---|---|
| Not reasonably linkable | Direct identifiers removed, quasi-identifiers coarsened, free text redacted, tokens the recipient cannot map |
| Reasonable safeguards | Access controls, separated or destroyed mapping tables, documented preparation steps |
| Public commitment | A statement, often in the privacy notice, that the business maintains the data in deidentified form |
| Recipient contract terms | License terms that prohibit reidentification and require onward recipients to accept the same limits |
Why pseudonymization still matters in a licensing deal#
Pseudonymization still matters because it reduces exposure, supports security obligations and is often the first step toward a deidentified package. It also preserves useful structure: a consistent token lets a buyer follow one customer's ticket thread or one site's job history without learning who the customer is.
The tradeoff is direct. Consistent tokens raise usefulness and raise linkability. Packages that must meet the deidentified standard usually generate new tokens for the export, keep no mapping the recipient can reach and limit how widely a token stays stable.
| Question | Treated as pseudonymized personal information | Treated as deidentified |
|---|---|---|
| Consumer rights requests | May still apply, with practical limits counsel can explain | Generally do not apply |
| Sale or sharing analysis | Licensing may be analyzed as a sale | Generally outside that analysis |
| Contract terms needed | Terms that fit the recipient's role, plus a notice review | Deidentified-data terms, including no reidentification |
| Preparation effort | Lower | Higher, with documented review |
Illustrative: a manufacturer prepares warranty claim records#
Illustrative: a fictional maker of commercial kitchen equipment holds years of warranty claims and service records in its ERP and help desk, including claims filed by individual restaurant owners in California. Its first plan tokenized claimant names and emails with a reversible key and kept everything else unchanged.
Counsel advised that the tokenized set would still be personal information. The company changed course: it generated new export-only tokens, removed claimant names and phone numbers from free-text notes, coarsened site addresses to region, adopted a public deidentification commitment and drafted license terms that bar reidentification. The failure codes, parts, service steps and outcomes stayed intact, which is where the records' value sits.
How SourceX handles pseudonymized records#
SourceX addresses this question in the Rights and Preparation steps of the SourceX five-step transaction. Counsel decides which standard a package must meet, and preparation is designed to that standard rather than to a default technique.
The privacy record in the SourceX Evidence Packet states which techniques were applied, such as tokenization or redaction, and whether any mapping was retained and where. The Data and Trust Alliance's Data Provenance Standards list pseudonymization, tokenization and anonymization as separate privacy-enhancing tools, a useful reminder to name the technique precisely instead of calling every package anonymized.
Frequently asked questions
Does destroying the key make pseudonymized data deidentified?
Destroying the key helps, but it is rarely enough on its own. Free text, quasi-identifiers and stable tokens can still link records to people, and the deidentified standard also expects public commitments and recipient contract terms. Treat key destruction as one step in a wider review, and have counsel confirm the result against the current rules.
How do other state privacy laws treat pseudonymous data?
Several other state laws define pseudonymous data and relax some consumer rights when the business keeps the additional information separate and controlled. They generally still treat it as personal data, so the category changes obligations at the margins. A company with customers in several states should expect pseudonymized records to stay in scope in most of them.
Does licensing pseudonymized data count as a sale under the CCPA?
It may. Making personal information available to another business for value can fall within the CCPA's definition of a sale, and pseudonymized data usually remains personal information. Whether a specific license is a sale depends on the data, the recipient's role and the contract terms, so counsel should review it before the deal is structured.
Do consumer requests still apply to pseudonymized records?
Generally yes, because the records remain personal information. In practice a business may not be able to match a request to a tokenized record without the key, and the rules address some of those situations. Map how a deletion or opt-out request would reach any pseudonymized copy before that copy leaves your control.
Is aggregated data treated the same as pseudonymized data?
No. Aggregated data summarizes groups rather than describing individuals, and it is often outside the definition of personal information when no group is small enough to point to a person. Pseudonymized data keeps individual-level rows. Most licensing packages of operational records are individual-level, so aggregation rarely solves the problem for them.
Sources
- Google's Sensitive Data Protection API supports de-identification transforms including format-preserving encryption (CryptoReplaceFfxFpeConfig) and deterministic encryption (CryptoDeterministicConfig). Source
- Under Cal. Civ. Code § 1798.140(m), as amended by the CPRA, information is deidentified only if it cannot reasonably be linked to a particular consumer and the business takes reasonable measures against association, publicly commits not to reidentify it, and contractually obligates recipients to comply. Source
- The Data Provenance Standards' Privacy Enhancing Tools code list includes anonymization, pseudonymization and tokenization as separate entries, among others. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.