Maybe.

“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).¹  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.”²  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.”³  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:⁴

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 Party⁵ 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.⁶

For more information and resources about the CCPA visit http://www.CCPA-info.com. 

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.]