Is it possible for a token to still be considered “personal information?”



“Tokenization” refers to the process by which you replace one value (e.g., a credit card number) with another value that would have “reduced usefulness” for an unauthorized party (e.g., a random value used to replace the credit card number).1  In some instances, tokens are created through the use of algorithms, such as hashing techniques. 

Whether personal information that has been tokenized is still considered “personal information” depends upon the particular law or regulation at issue.

In the context of the CCPA, information is not “personal information” if it has been “deidentified.”2  Deidentification means that the data “cannot reasonable identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer.”3  A strong argument could be made that data that is fully tokenized, and no longer is connected to a particular consumer, cannot reasonably be associated with an individual.  That argument is strengthened under the CCPA if a business takes the following four steps to help ensure that the tokenized data will not be re-identified:4

  1. Implement technical safeguards that prohibit reidentification.  Technical safeguards may include the process, or techniques, by which tokens are assigned.  For example, a business might take steps to randomly generate tokens, or ensure that tokens are not assigned sequentially in a manner that might allow a third party to guess to whom the token relates.
  2. Implement business processes that specifically prohibit reidentification.  This might include an internal policy or procedure that separates tokens from any “key” that might allow an individual to match a token to a consumer. 
  3. Implement business processes to prevent inadvertent release of deidentified information.  This might include a policy against disclosing information about individuals even if the names of the individuals have been replaced with tokens.
  4. Make no attempt to reidentify the information. As a functional matter, this entails taking steps to prohibit reidentification by the business’s employees.

In comparison, in the context of the European GDPR, the Article 29 Working Party5 has stated that even when a token is created by choosing a random number (i.e., it is not derived using an algorithm), the resulting token typically does not make it impossible to re-identify the data and, as a result, the token is best described as “pseudonymized” data which would still be “personal data” subject to the GDPR.6

For more information and resources about the CCPA visit 

This article is part of a multi-part series published by BCLP to help companies understand and implement the General Data Protection Regulation, the California Consumer Privacy Act and other privacy statutes.  You can find more information on the CCPA in BCLP’s California Consumer Privacy Act Practical Guide, and more information about the GDPR in the American Bar Association’s The EU GDPR: Answers to the Most Frequently Asked Questions.

1. Article 29 Working Party, WP 216: Opinion 05/2014 on Anonymisation Techniques at 21 (adopted 10 April 2014).

2. CCPA, Section 1798.145(a)(5).

3. CCPA, Section 1798.140(h).

4. CCPA, Section 1798.140(v).

5. The Article 29 Working Party was the predecessor to the European Data Protection Board.

6. Article 29 Working Party, WP 216: Opinion 05/2014 on Anonymisation Techniques at 21 (adopted 10 April 2014).

[View source.]

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© BCLP | Attorney Advertising

Written by:


BCLP on:

Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
- hide
- hide