Are companies required to get opt-in consent under the CCPA before using personal data?
No.
The CCPA does not require that a company obtain the consent (or the “opt-in”) of a person before collecting or using their personal information. The concept of consent only arises within the CCPA if a company intends to sell information. In that context, consent applies in three situations:
- Exemption from the definition of “sale.” The CCPA’s broad definition of “sale” could encompass a number of ordinary information transfers that consumers would hardly consider to be a “sale” as the term is generally understood. The CCPA exempts from the definition of “sale” any transfer that takes place because the “consumer uses or directs the business” to “intentionally disclose personal information” to a third party.1 In other words, if a consumer consents, or opts-in, to an information transfer it is not considered a “sale” under the CCPA.2
- Sale of information about minors. The CCPA prohibits a business from knowingly selling the personal information of a consumer that is “less than 16 years of age” unless the consumer (in the case of individuals between 13 and 16) or the guardian (in the case of individuals under the age of 13) has “affirmatively authorized the sale” of personal information.3 In other words, opt-in consent is needed to sell the information of a minor. Interestingly, if a business obtained the affirmative consent to transfer personal information, as discussed in the previous paragraph technically the information transfer might not be a “sale” at all.
- Re-soliciting the ability to sell. The CCPA states that if a person opts-out of the sale of information (E.g., click a “Do Not Sell My Personal Information” link) a business is not permitted to solicit their consent (or opt-in) to a future sale for “at least 12 months.”4
Are companies required under the CCPA to get employees’ consent before collecting their personal information?
No.
The CCPA does not require that a company obtain the consent (or the “opt-in”) of a person before collecting or using their personal information. The concept of consent only arises within the CCPA if a company intends to sell information. In that context, consent applies in two situations when dealing with employees:
- Exemption from the definition of “sale.” The CCPA’s broad definition of “sale” could encompass a number of ordinary information transfers that consumers would hardly consider to be a “sale” as the term is generally understood. The CCPA exempts from the definition of “sale” any transfer that takes place because the “consumer uses or directs the business” to “intentionally disclose personal information” to a third party.1 In other words, if an employee consents, or opts-in, to an information transfer it is not considered a “sale” under the CCPA.2
- Sale of information about minors. The CCPA prohibits a business from knowingly selling the personal information of a consumer that is “less than 16 years of age” unless the consumer has “affirmatively authorized the sale” of personal information.3 In other words, opt-in consent is needed to sell the information of a minor-employee. Interestingly, if a business obtained the affirmative consent to transfer personal information, as discussed in the previous paragraph the information transfer might not be a “sale” at all.
- Re-soliciting the ability to sell. The CCPA states that if a person opts-out of the sale of information (E.g., click a “Do Not Sell My Personal Information” link) a business is not permitted to solicit their consent (or opt-in) to a future sale for “at least 12 months.”4 As a result, if a company sells the information of its employees, and provides employees a do not sell option, it is not permitted to ask those employees that opt-out for permission to sell for 12 months.
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. Cal. Civil Code § 1798.140(t)(2)(A).
2. Cal. Civil Code § 1798.140(t)(2)(A).
3. Cal. Civil Code § 1798.120(c).
4. Cal. Civil Code § 1798.135(a)(5).
Are consumers in Europe more likely than consumers in the United States to “opt-in” to cookies?”
Yes.
Most cookie banners can be classified into one of three general categories: (1) notice only banners, (2) notice + opt-out banners, and (3) notice + opt-in banners. If a company chooses to adopt a cookie banner that provides notice and solicits the opt-in consent (e.g., “I agree”) of website users, the company would have a strong argument that it does not need to disclose that it has sold information, does not need to forward deletion requests to the providers of its third party cookies, and does not need to include an “opt out of sale” link on its website.1
Companies often struggle with anticipating the percentage of users that are likely to accept the deployment of cookies when prompted. There is relatively little empirical data publicly available concerning website visitors’ interactions with cookie banners. The little data that exists, however, indicates that acceptance rates differ depending upon the location of the website visitor. Specifically, users in some European countries (e.g., Sweden and the Netherlands) appear to “accept” cookies when presented with a cookie notice that solicits opt-in at rates that may be more than double the acceptance rate in the United States.2
Are the “unified business provision” and the “affiliate exception” within the CCPA the same thing?
Yes.
The CCPA includes within the definition of a “business” an entity “that controls or is controlled by [another] business” and that “shares common branding with the business.” 1 This provision has been referred to by some companies as the “unified business provision” as it functionally states that entities under common control and common branding should be treated under the CCPA as a single “business” instead of as multiple business entities. Other companies have referred to this as the “affiliate exception” owing to its functional impact on compliance. Specifically, if the Act did not treat businesses that were under common ownership, control, and branding as a single business, then affiliates might find themselves in the situation in which transfers of data between and among members of a corporate group might constitute the “sale” of information as they might be viewed as transfers from one business to a separate business for consideration (if, for example, the affiliated entities were performing services for one another or cross-marketing products). Viewing corporate affiliates as a single business unit for the purposes of the CCPA functionally creates an exception to the definition of “sale” for those situations in which Affiliate A transfers personal information to a commonly branded Affiliate B.
Can a company market to individuals whose information was collected as part of a sweepstakes?
Federal law sometimes requires that companies obtain consent prior to sending marketing communications. Whether a company needs consent to send a marketing communication to an individual that provided her information as part of a sweepstakes entry depends on the following factors:
(1) The mode of communication (e.g., email, telephone, or SMS) that the company intends to use to contact the individual. As a general proposition, consent is not needed within the United States to send email communications; consent may be needed to send telephone (voice or SMS) marketing communications to individuals.
(2) The technology utilized for the contact. If a company intends to send a telephone (voice or SMS) marketing communication, the level of consent and the level of documentation to substantiate the consent are generally greater if the company uses an automated telephone dialing system (“ATDS”) to send the message, will be transmitting a pre-recorded message, or is contacting a wireless telephone number.
The CCPA does not enhance, or lessen, the consent requirements imposed by federal law for transmitting marketing communications. It may require, however, that if a business collects personal information as part of a sweepstakes that the following steps be taken:1
Can retargeted advertising campaigns be done under service provider agreements?
Yes.
The definition of “sale” under the CCPA contains an exception for situations in which information is shared with a service provider. In order for an adtech company to meet the definition of a “service provider,” at least two conditions must be met.
First, the transfer of information to the service provider must be “necessary” for the website’s business purpose.1
Second, the agreement with a service provider must “prohibit” the service provider “from retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract with the business.”2
One common use of third party behavioral advertising cookies is to allow businesses to contact consumers that have left the business’s website in order to serve those consumers with targeted advertising. Similarly, businesses may serve targeted advertising not through the use of behavioral advertising cookies, but by providing adtech partners lists (e.g., names, email addresses, or telephone numbers) of customers or potential customers. These practices are commonly referred to as retargeting campaigns, as they often attempt to “retarget” consumers that expressed interest in a product or service, but failed to complete a transaction.
Questions have been raised about whether third parties that provide retargeting services can be classified as “service providers” under the Act. Specifically, some commenters have asserted that such a use might not be “necessary” for a business purpose under the CCPA, or that by performing a retargeting campaign an adtech partner may be using data for its own purposes. In response to these concerns, the California Attorney General clarified that “[t]he CCPA allows a service provider to furnish advertising services to the business that collected personal information from the consumer, and such ads may be shown to the same consumer on behalf of the same business on any website.”3 The Attorney General further cautioned, however, that to be considered a service provider the adtech partner must not use the personal information that it collects from one business to “provide advertising services to other businesses.4 Furthermore, under the regulations implementing the CCPA the adtech partner must be prohibited from “building or modifying household or consumer profiles” from the data that it receives.5
CCPA Privacy and Security FAQs: Does the CCPA define “personal information” differently for privacy and security purposes?
Yes.
The sections of the CCPA that relate to data privacy (i.e., the collection, use, and sharing of information) use a definition of “personal information” that includes approximately 26 categories or types of data.1That said, an amendment to the CCPA deferred the full impact of the Act upon employee data until January 1, 2021.2 In contrast, the sections of the CCPA that relate to data security (i.e., the protection of information) adopt a far narrower definition of “personal information” that includes only 6 categories of types of data. The following chart indicates which categories of personal information apply to the data privacy and the data security sections of the CCPA:
Examples of Personal Information | Applies to Privacy Requirements of CCPA | Applies to Security Requirements of CCPA |
1. Audio, electronic, visual, thermal, olfactory, or similar information | ✓3 | |
2. Bank account number | ✓4 | ✓5 |
3. Biometric information | ✓6 | |
4. Commercial information (e.g., products or services purchased, or other purchasing or consuming histories or tendencies) | ✓7 | |
5. Credit card number | ✓8 | ✓9 |
6. Debit card number | ✓10 | ✓11 |
7. Driver’s License Number / State ID | ✓12 | ✓13 |
8. Education | ✓14 | |
9. Electronic network activity (e.g., browsing history) | ✓15 | |
10. Email address | ✓16 | Partial ✓17 |
11. Employment | ✓18 | |
12. Employment history | ✓19 | |
13. Geolocation data | ✓20 | |
14. Health insurance information | ✓21 | ✓22 |
15. Identifiers (e.g., name or alias) | ✓23 | Partial ✓24 |
16. Insurance Policy Number | ✓25 | ✓26 |
17. Medical information | ✓27 | ✓28 |
18. Online identifier (e.g. IP address) | ✓29 | |
19. Other financial information | ✓30 | |
20. Passport Number | ✓31 | |
21. Physical Characteristics | ✓32 | |
22. Postal address | ✓33 | |
23. Signature | ✓34 | |
24. Social Security Number | ✓35 | ✓36 |
25. Telephone Number | ✓37 | |
26. Transaction information | ✓38 |
CCPA Privacy and Security FAQs: If a company receives a right to be forgotten request, does it have to delete the requestor’s IP address from its weblogs?
Probably not.
The term “personal information” is defined by the CCPA as “information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.”1 While the Act provides a list of examples of personal information – which explicitly includes “Internet Protocol Address” – it qualifies the examples by stating that they only fall within the definition of personal information if they identify, relate to, describe, are “capable of being associated with,” or “could be reasonably be linked” with a particular person.2 There is a strong argument that a dynamic IP address (which is assigned to different computers at different times) may not fall within the definition of “personal information” under the CCPA as it may not be capable of being reasonably linked with a particular person. There may also be an argument that many static IP addresses may not be “reasonably” linked to a consumer if they are not combined with other information that would permit the easy identification of that consumer.
Assuming that a court or a regulator were to determine that a particular IP address did fall under the definition of “personal information,” and a consumer were to make a right to be forgotten request in connection with that IP address, the right to be forgotten is not absolute.3 The CCPA provides ten exceptions pursuant to which a business can refuse a deletion request. That said, an amendment to the CCPA deferred the full impact of the Act upon employee data until January 1, 2021.4Of those ten exceptions, the following are most likely to apply to a request that a company delete an IP address from its weblogs:
- Detect wrongdoing. If personal information is collected from a consumer because it is needed to detect security incidents, or protect the business against illegal actions (e.g., fraud, deception, etc.), it does not need to be deleted.5 To the extent that a company maintains a weblog to identify potential malicious activity impacting its website (e.g., hacking, unauthorized attempts to access information, patterns of suspicious activity, possible denial-of-service attacks, etc.), this exception could be asserted to deny a deletion request.
- Repair errors. According to the CCPA, if personal information is necessary to “[d]ebug to identify and repair errors that impair existing intended functionality,” it does not need to be deleted.6 To the extent that a company maintains a weblog that contains IP addresses as part of its effort to identify and debug errors that may be occurring on its website (e.g., faulty page loads, broken links, etc.), this exception could be asserted to deny a deletion request.
- Exercise legal right. If personal information collected from a consumer is needed for the business to “exercise another right provided for by law,” it does not need to be deleted.7 To the extent that a company maintains a weblog as part of its right to communicate with third parties and/or a right to understand the identity of those third parties that attempt to communicate with it, this exception might be asserted to deny a deletion request.
- Internal uses aligned with consumer expectations. If personal information collected from a consumer will have “solely internal uses” for the business, and if those uses are “reasonably aligned with the expectations of the consumer based on the consumer’s relationship with the business,” the information does not need to be deleted.8 Note that, while the statute does not explicitly state whether a California court should look to the “expectations of the consumer” at the time that they provided the information to the business, presumably that is the relevant time period, as any other interpretation might render the exception a nullity (i.e., a consumer is likely to argue at the time of making a deletion request that they have no continued expectation of use). To the extent that a consumer would expect the company to collect IP addresses (e.g., such collection was disclosed as part of a privacy notice, or such collection has become industry standard practice), this exception might be available to deny a deletion request.
- Internal uses aligned with the context of collection. If personal information collected from a consumer will be used “internally” and in a manner that is “compatible” with the “context in which the consumer provided the information,” than the information does not need to be deleted.9 While this exception is similar to the previous exception, unlike the previous exception, the use need not be aligned with the consumer’s expectations so long as it is compatible with the context of the original collection. Again, in the context of IP addresses, if a company uses IP address in a context in which the consumer provided the information (e.g., as disclosed in a privacy notice), this exception might be available to deny a deletion request.
- Comply with legal obligations. If personal information collected from a consumer is needed to comply with a legal obligation (e.g., a statute that requires that the business maintain documentation relating to the consumer, a preservation hold issued as part of legal process, or a statute that requires that a company maintain weblogs as part of its overall security), the business is not required to delete the information.10In the context of IP addresses, if a company is required by law to maintain certain records – such as a weblog for security or audit trail purposes – this exception may be available to deny a deletion request.
CCPA Privacy FAQs: Are corporate affiliates that use common branding safe under the CCPA?
The CCPA broadly defines the term “sale” as “disclosing” or “making available” personal information “for monetary or other valuable consideration” from one business to another.1 The CCPA implies that two (or more) entities are considered a single “business” if one of the entities “controls or is controlled by” the other, and the two entities “share[] common branding.”2 A threshold question, therefore, asked by corporate affiliates that are part of large corporate structures is whether their relationship with a sister entity satisfies the “control[]” or “controlled by” language.
Confusion surrounding what it means to be “controlled” by another entity stems, in part, because the CCPA’s definition of “control” departs from the definitions used in other privacy statutes. For example, the following compares the definition of “control” found within the CCPA and the definition of “control” found within the Gramm Leach Bliley Act’s (“GLBA”) Privacy Rule (Regulation P) that applies to financial institutions:
Criteria | CCPA
Definition of Control |
GLBA (Regulation P)
Definition of Control |
Ownership, or the power to vote, at least 25% of the outstanding shares of voting security. | Not in of itself Sufficient3 | ✓4 |
Ownership, or the power to vote, at least 50% of the outstanding shares of voting security. | ✓5 | ✓6 |
Control in any manner over the election of a majority of the directors, or of individuals exercising similar functions. | ✓7 | ✓8 |
The power to exercise a controlling influence over the management of a company. | ✓9 | ✓10 |
As indicated above, while the definitions are similar, an entity that owned a substantial, but minority, share of a second entity (e.g., 49%) would be considered to “control” the second entity under the GLBA, but would not be considered to “control” the second entity under the CCPA unless it also exercised some other control element (e.g., a controlling influence over management).
The CCPA adds additional confusion because, unlike many other privacy statutes, it does not define or use the term “affiliate” or “corporate group” to explicitly account for the reality that many modern corporate structures include intermediary ownership. For example, Regulation P defines an “affiliate” to mean “any company that controls, is controlled by, or is under common control with another company.”11 When the definition of “affiliate” is combined with the definition of “control,” it is clear that, under the following corporate structure, if Entity E were to transmit data to Entities A, B, C, D, F, G, H, I or J, they would be sharing with a corporate “affiliate:”
Because the CCPA lacks any definition of “affiliate” or “corporate group,” some companies have wondered whether the CCPA would only treat a transfer between two entities that are in a direct vertical relationship (e.g., Entity B and Entity A) as occurring within the same “business.” Such an interpretation, however, would be highly unlikely for two reasons. With regard to vertical transmissions of information up a corporate structure, as indicated above, the CCPA defines “control” as being not limited to just the entity that “owns” another entity, but an entity that “exercise[s] a controlling influence over the management” of another entity. In the above corporate structure, it is likely that Entity A exercises a “controlling influence” (whether direct or indirect) with regard to all of the other corporate entities. With regard to horizontal transmission of information (e.g., Entity B to Entity C), courts are likely to triangulate ownership such that if Entity B is “controlled by” Entity A it represents a single “business,”and if Entity A “controls” Entity C, then it too represents part of the same single business.
The net result is that while the language of the CCPA is far less artful than the language used in most other privacy statutes, it will likely be interpreted as permitting data to be shared between and among a corporate group, so long as all of the members of the group ultimately trace control or ownership back to a common source.
CCPA Privacy FAQs: Are payment processors and acquiring banks “service providers” under the CCPA?
It’s unclear.
A vendor must be bound by a written contract that prohibits it from:
- Retaining the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,”
- Using the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,” or
- Disclosing the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title.”
While an argument could be made that a payment processor contains the retention, use, and disclosure restrictions mandated by the CCPA because they receive information from merchants for the purpose of processing credit card payments for the benefit of the merchant, it is possible that a California court could determine that their purpose in processing the information goes beyond simply providing service for their merchant client. For example, in addition to using a credit card number transmitted from a merchant to process a credit card transaction, a payment processor may use that information to look for suspicious activity that could indicate a data breach, or identity theft of a cardholder. They may also have obligations to third parties (e.g., Visa and MasterCard) to retain cardholder information even after they have completed the transaction requested by the merchant. A court might view these types of activities as going beyond the “specific purpose of performing the services” specified in a contract with a merchant.
To the extent that a court were to determine that a payment processor or an acquiring bank does not fall under the statutory definition of “service provider,” a merchant would have to disclose to consumers that their credit card information was “sold” to these companies unless the information transfer fell under one of the exceptions to a “sale” under the CCPA. It is possible that a business could argue that by providing their credit card, the consumer implicitly or explicitly “direct[ed] the business to intentionally disclose personal information or use[d] the business to intentionally interact with a third party.” Put differently, a reasonable consumer would understand that in order for a business to process a credit card transaction, the consumer’s credit card would need to be provided to a variety of third parties ranging from a payment processor, payment gateway, payment authentication service, acquiring bank, and payment card network. The act of providing the credit card and requesting that it be used for payment must, by its nature, be a request that the business disclose the consumer’s information to these entities.
CCPA Privacy FAQs: Does the CCPA apply to personal data about non-Californians (e.g., Europeans)?
Although the California Consumer Privacy Act (“CCPA”) is scheduled to go into force in early 2020, there is a great deal of confusion regarding the requirements of the CCPA, including the degree to which it aligns with other privacy regulations such as the European General Data Protection Regulation (“GDPR”). To help address that confusion, BCLP has published a multi-part series that discusses the questions most frequently asked by clients concerning the CCPA. You can play a video discussion of this FAQ here or find a complete archive of FAQs at www.ccpa-info.com.
Q. Does the CCPA apply to personal data about non-Californians (e.g., Europeans)?
No.
Some data privacy laws are designed to apply to personal data collected about individuals that live beyond the country’s borders. Most notably, if a company is subject to the general jurisdiction of the European GDPR because it is processing personal data in the context of an establishment within the European Union, the GDPR purports to apply to all personal data – regardless of the residency of the person about whom the data relates. So, for example, if a company processes data in Paris, the GDPR purports to apply to that data regardless of whether the data is about Parisians or Americans.1 The net result is that if the GDPR attaches, it may apply to data subjects “whatever their nationality or place of residence.”2
The CCPA, on the other hand applies only to “consumers” a term that is expressly defined as including only “a natural person who is a California resident.”3 As a result, if a company processes data in Los Angeles, the CCPA applies only to the personal information processed about Californians; it does not apply to information processed about residents of other states or countries.
1. It is worth nothing that if a company that is not established within the European Union is subject to the more limited jurisdiction of the GDPR by offering goods or services to Europeans, or monitoring the behavior of Europeans the GDPR does not purport to apply to individuals outside of Europe (i.e., Americans).
2. GDPR, Recital 14.
3. Cal. Civil Code 1798.140(g) (emphasis added).
CCPA Privacy FAQs: Does the CCPA incorporate the definition of “personal information” from other statutes?
Yes.
The CCPA defines the phrase “personal information” as referring to any information that “identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.”1 The CCPA goes on to provide a non-exhaustive list of data categories that might fall under that broad definition. That list, however, incorporates categories of personal information from other statutes, including California Civil Code Section 1798.80(e), and some of the incorporated-by-reference categories are redundant to categories included elsewhere in the CCPA’s personal information definition. The following identifies and de-duplicates the “categories” of personal information named, or cross-referenced, in the CCPA:
Category of Personal Information | CCPA | California Civil Code 1798.80(e) (integrated into CCPA via 1798.140(o)(B). |
1. Audio, electronic, visual, thermal, olfactory, or similar information | 1798.140(o)(1)(H) | |
2. Bank account number | 1798.80(e) | |
3. Biometric information | 1798.140(o)(1)(E) | |
4. Commercial information (e.g., products or services purchased, or other purchasing or consuming histories or tendencies) | 1798.140(o)(1)(D) | |
5. Credit card number | 1798.80(e) | |
6. Debit card number | 1798.80(e) | |
7. Driver’s License Number / State ID | 1798.80(e) | |
8. Education | 1798.140(o)(1)(J) (within the scope of FERPA) | 1798.80(e) |
9. Electronic network activity (e.g., browsing history) | 1798.140(o)(1)(F) | |
10. Email address | 1798.140(o)(1)(A) | |
11. Employment | 1798.140(o)(1)(D) | 1798.80(e) |
12. Employment history | 1798.140(o)(1)(I) | 1798.80(e) |
13. Geolocation data | 1798.140(o)(1)(G) | |
14. Health insurance information | 1798.80(e) | |
15. Identifiers (e.g., name or alias) | 1798.140(o)(1)(A) | |
16. Insurance Policy Number | 1798.80(e) | |
17. Medical information | 1798.80(e) | |
18. Online identifier (e.g. IP address) | 1798.140(o)(1)(A) | |
19. Other financial information | 1798.80(e) | |
20. Passport Number | 1798.140(o)(1)(A) | 1798.80(e) |
21. Physical Characteristics | 1798.80(e) | |
22. Postal address | 1798.140(o)(1)(A) | 1798.80(e) |
23. Signature | 1798.80(e) | |
24. Social Security Number | 1798.140(o)(1)(A) | 1798.80(e) |
25. Telephone Number | 1798.80(e) | |
26. Transaction information | 1798.140(o)(1)(D) |
CCPA Privacy FAQs: Does the CCPA require that a company allow consumers to opt-out (e.g., toggle off) analytics cookies?
It depends.
The CCPA requires that a business that “sells” personal information disclose within its privacy policy a “list of the categories of personal information it has sold about consumers in the preceding 12 months.”1 The CCPA broadly defines the term “sell” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration.”2 “Personal information” is also defined broadly as including any information that “could reasonably be linked, directly or indirectly, with a particular consumer or household” such as, in certain instances, IP addresses, unique online identifiers, browsing history, search history and “information regarding a consumer’s interaction with an Internet Web site, application, or advertisement.”3
While the definition of “sale” under the CCPA contains an exception for situations in which information is shared with a service provider, whether the exception applies to analytics cookies operated by third parties may depend in part upon the contract in place (or terms and conditions) with the third party.4 Specifically, the service provider exception requires that following three conditions be present:
- The transfer of information to the service provider must be “necessary” for the website’s business purpose.5 It is uncertain whether a court would view analytics cookies (and the information that they provide) as a necessity.
- The transfer of the information to the service provider must be disclosed to consumers. Many websites arguably meet this requirement by disclosing their use of third party cookies or analytics cookies in their privacy policies.
- The agreement with a service provider must “prohibit” the service provider “from retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract with the business.”6 Whether the contract in place with the provider of an analytics cookie meets these requirements may be a case-by-case inquiry.
In order to mitigate the risk that permitting analytics cookies to deploy on a website will be interpreted as a “sale” of information, a website has at least three options:
- Verify that the contract fits the definition of a “service provider.” If the analytics cookies are necessary for the efficient operation of the website, and if a website verifies that its contract with the analytics cookie provider qualifies as a “service provider,” the cookie can be placed without offering consumers the ability to opt-out or toggle the cookie off.
- Ask for consent. The CCPA excepts from the definition of “sale” the situation where a “consumer uses or directs the business to intentionally disclose personal information.”7 As a result, if a website deploys a cookie banner, and a consumer agrees or “opts-in” to the use of analytics cookies, the website arguably has not “sold” information to the company that provides the analytics cookie. Note that if the consumer agrees to the deployment of the analytics cookie, nothing within the CCPA would require the website to present them with an automatic ability to opt-out (i.e., toggle off) the cookie.
- Disclose the sale of information and offer opt-out. If an analytics vendor does not fit the definition of a “service provider,” and opt-in consent is not obtained, a website could disclose within its privacy policy that it is “selling” information (as that term is defined within the CCPA) to an analytics cookie provider. Note, however, that if a company sells personal information, the CCPA requires that the company provide a “Do Not Sell My Personal Information” link on its homepage, and honor requests to opt-out from such sales.8 Assuming that a business provides such a link, it is not clear that a mechanism currently exists for the business to communicate to analytics cookie providers that a particular consumers’ information cannot be collected. One possible alternative might be to adopt a cookie management tool that provides consumers with the ability to “toggle off” the analytics cookie. A cookie management tool solution, however, has not been validated by the Office of the Attorney General or California courts and may raise conceptual questions concerning whether the “toggle-off” feature is sufficient given that the consumer may be re-presented with a request to accept analytics cookie the next time that the consumer clears their cache, or visits the website from a different browser.
The net result is that while the CCPA does not expressly require that websites offer to consumers the ability to “toggle-off” analytics cookies, some companies may offer such a feature as part of a risk mitigation strategy.
CCPA Privacy FAQs: Does “personal information” include information that a business obtains from government records?
In most cases, no.
The CCPA excludes from the definition of “personal information” information that is “publicly available” and defines that term to mean “information that is lawfully made available from federal, state, or local government records, if any conditions associated with such information.”1
The CCPA was put together quickly (in approximately one week). Given its hasty drafting, there are a number of instances in which the act is at best ambiguous and at worst unintelligible. The definition of “publicly available” may be one of those instances. Specifically, the definition of publicly available seems to be missing a direct object following the introductory phrase “if any conditions associated with such information.” While presumably the drafters intended the phrase to state “if any conditions associated with such information imposed by a government agency are satisfied,” the incomplete conditional clause has yet to be interpreted by courts or the California Attorney General.
The CCPA adds additional ambiguity to the treatment of information derived from publicly available government records by further stating that information “is not ‘publicly available’ if that data is used for a purpose that is not compatible with the purpose for which the data is maintained and made available in the government records for which it is publicly maintained.”2 Based upon this language, it is not clear whether a business’s use has to be “compatible” with the purpose for which the government agency originally maintained the data, or only with the purpose for which the business collected (and then maintained) the data. As an example, a municipal tax authority may make available public records reflecting tax assessments on real property (e.g., the names of the owners of real property, their land valuation, and their tax assessment), and as the only condition indicate that a business may not use the information to harass a property owner. It is uncertain whether a court would examine whether the business’s use is “compatible” with the purpose of the government agency (e.g., imposing taxes) or with the purpose of the business as permitted by the government agency (e.g., any business purpose that does not involve harassment). Assuming that a court looked to the government’s purpose, it is equally unclear what it means to be “compatible” with that purpose. It is unlikely that a court would interpret compatibility as meaning that the business must share the same purpose as to do so would typically negate any plausible business purpose (i.e., no business shares a purpose of imposing taxes).
It is more likely that a court would interpret “compatibility” based upon its plain meaning of permitting two things to exist or occur together without conflict. Under that definition, arguably any use by a business of such data would be “compatible” (even if it the business’s purpose is unrelated to the government purpose) so long as the business’s purpose does not (1) interfere with the government purpose by, for example, preventing the collection of taxes, or (2) interfere with any condition placed on the data by the government (i.e., involve harassment). As a result, a business that downloaded tax assessment data in order to perform analytics (e.g., compute average assessment values by block, or zip code) would have a purpose that is “compatible” with the government’s purpose in assessing property taxes, as would a business that downloaded the same tax assessment data to send marketing communications to home owners.
CCPA Privacy FAQs: How far can a company go to validate the identity of an individual making a data subject access request?
- If a company receives a written request from a current employee that is personally known, a phone call may be sufficient to satisfy the identity of the requestor. It would likely be unreasonable to ask them for additional proof of identity.
- If a company receives a request by email, and in that email the requestor provides an address which does not match the address a company has on record, it would be reasonable to confirm another detail which the company holds on record.
The means by which the request is delivered may also affect your decision about how far a company needs to go to confirm the requestor’s identity. For example, if a request is made from an email account with which a company has recently corresponded with the requestor, it may be reasonable (particularly if the personal information kept has no sensitivity) to assume that the request has been made by the requestor. On the other hand, if the request is made via a social networking website or on blank letter paper, it may be more prudent to check whether it is a genuine request.
1. CCPA, 1798.100(c).
2. CCPA, 1798.140(y).
3. Working Party Paper 242 Rev.01, Guidelines on the Right to Data Portability at 13-14 (5 April 2017).
4. See UK Information Commissioner’s Office, Subject Access Code of Practice: Dealing with Requests from Individuals for Personal Information at 24.
CCPA Privacy FAQs: If a business allows consumers to redeem loyalty program benefits for products or services offered by a partner, does that constitute the sale of information?
No.
The CCPA broadly defines the term “sale” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration” from one business to another.1 In the context of loyalty programs, it is not unusual for the operator of a loyalty program to enter into an agreement with a business partner (e.g., another company) to permit a consumer to redeem loyalty points accumulated through the loyalty program of business A in order to receive goods or services provided by business B. For example, a hotel may have an agreement with a car rental service through which a consumer can redeem hotel loyalty points to receive a free car rental.
Such redemption arrangements may require the disclosure of personal information from one business (e.g., business A) to a second business (e.g., business B), and may include the payment of money or other consideration for the ability to receive advertising or promotion as a rewards provider. As a result, and depending upon the structure of the business relationships, it is possible that the arrangement could fit the definition of “sale” under the CCPA.
Assuming that the transfer of information to a redemption partner did satisfy the definition of a “sale,” the CCPA contains an exception for situations in which a “consumer uses or directs the business to intentionally disclose personal information.”2 As a result, if a consumer uses a loyalty program in order to interact with another business, or directs a loyalty program to disclose personal information as part of a points redemption, the loyalty program operator arguably has not “sold” information.
CCPA Privacy FAQs: If a business shares information through its loyalty program with a third party fulfillment company, is it “selling” information?
Probably not.
The CCPA broadly defines the term “sale” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration” from one business to another.1
The definition of “sale” under the CCPA contains an exception for situations in which information is shared with a service provider. Whether the exception applies to a third party fulfillment company that has been contracted by a loyalty program operator to provide benefits (e.g. free merchandise, goods, or services) depends in part upon the contract in place with the fulfillment company.2 Specifically, the service provider exception requires that following three conditions be present:
- The transfer of information to the service provider must be “necessary” for the loyalty program’s business purpose.3 There is a strong argument that the use of a vendor to fulfill promised benefits is necessary to the operation of a loyalty program.
- The transfer of information to the service provider must be disclosed to consumers. Many loyalty programs meet this requirement by disclosing their use of service providers in their privacy policies.
- The agreement with a service provider must “prohibit” the service provider “from retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract with the business.”4 Whether the contract in place with a fulfillment provider meets these requirements may be a case-by-case inquiry.
CCPA Privacy FAQs: If a company collects personal information through a cookie, is it required to provide a consumer with a privacy policy?
Maybe.
Section 1798.100(b) of the CCPA states that a “business that collects a consumer’s personal information shall, at or before the point of collection, inform consumers as to the categories of personal information to be collected and the purposes for which the categories of personal information shall be used.” Plaintiffs and consumer advocates are likely to argue that this requirement applies to information collected through “cookies” based upon the following:
- The CCPA defines the term “collects” as including situations in which a business “buy[s], rent[s], gather[s], obtain[s], receiv[es], or access[es]” personal information by “any means.”1
- The CCPA defines “personal information” to include “unique identifiers” which includes “persistent identifier[s] that can be used to recognize a . . . device that is linked to a consumer . . . over time and across different services, including, but not limited to . . . cookies.”2
It is worth noting, however, that notifying a consumer about the type of information collected and the purpose of the collection does not necessarily mean distributing to the consumer a full privacy policy. The statute does not require, for example, that the notification must be in writing or that the notification must include other types of information that are typically present in a privacy notice (e.g., information on the company’s practices with regard to sharing, etc.). As a result, it is possible that a company that collects information across websites through the use of cookies is able to fulfill its obligation to inform consumers of the data that it collects and its use for that data orally, contextually, or via a third party (e.g., via the privacy policy of company A that might intend to transmit the information to company B).
Some companies that collect information across websites through the use of cookies (i.e., third party behavioral advertisers) may also take the position that their cookies do not fall within the definition of “unique identifier” (and, through that, the definition of “personal information”) because their cookies are not “persistent.” For example, they may argue that if their cookie is set to expire in 90 days or 60 days it should be considered transient in nature. California’s courts and the California Office of the Attorney General have not interpreted whether cookies with set expiration dates should be considered “persistent” for the purposes of the CCPA.
CCPA Privacy FAQs: If a website participates in behavioral advertising, does Nevada privacy law require that it disclose that it is “selling” consumers’ information?
While Senate Bill No. 220 incorporates the CCPA’s concept of permitting consumers to object to the sale by a company of their information, it avoids many of the drafting errors, ambiguities, and business impracticalities of the CCPA, including its treatment of online behavioral advertising.
For context, the California CCPA requires that a business that “sells” personal information disclose within its privacy policy a “list of the categories of personal information it has sold about consumers in the preceding 12 months.”1 The CCPA broadly defines the term “sell” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration.”2 “Personal information” is also defined broadly as including any information that “could reasonably be linked, directly or indirectly, with a particular consumer or household” such as, in certain instances, IP addresses, unique online identifiers, browsing history, search history and “information regarding a consumer’s interaction with an Internet Web site, application, or advertisement.”3 Plaintiffs’ attorneys are likely to argue that the act of authorizing a third party behavioral network to access information transmitted by a consumer is synonymous with “making available” the information and, thus, constitutes a “sale” pursuant to the CCPA. In order to mitigate the risk that permitting behavioral advertising networks to deploy cookies on a website will be interpreted as a “sale,” many websites are asking consumers for opt-in consent to the use of behavioral advertising cookies through cookie banners. The CCPA excepts from the definition of “sale” the situation where a “consumer uses or directs the business to intentionally disclose personal information.”4 As a result, if a website deploys a cookie banner, and a consumer agrees or “opts-in” to the use of tracking cookies, the website arguably has not “sold” information to behavioral advertisers.
Unlike the CCPA, Nevada defines the term “sale” as including only “the exchange of covered information for monetary consideration by the operator [of a website] to a person for the person to license or sell the covered information to additional persons.”5 Nevada’s narrower definition precludes the term from applying to the use of third party behavioral advertising networks as (1) behavioral advertising networks typically do not provide advertisers or publishers with “monetary consideration” for the deployment of their cookies, and (2) while the behavioral advertising networks may use the information that they obtain from their cookies for the benefit of themselves and their other clients, they typically do not “license or sell” that information.
CCPA Privacy FAQs: Is a Service Provider Responsible if its Client Violates the CCPA?
No.
In order to be considered a “service provider” for the purposes of the CCPA, a vendor must be bound by a written contract that prohibits it from:
- retaining the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,”
- using the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,” or
- disclosing the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title.”
If a service provider negotiates an agreement with a client that contains the three provisions above, the CCPA states that the service provider will “not be liable” in the event that it’s client fails to fulfil the client’s obligations as a “business” under the Act. So, for example, a service provider should not be liable if its client fails to post a privacy notice, inaccurately describes its sharing practices, or fails to disclose that it has transferred personal information to the service provider.
CCPA Security FAQs: Can employees bring a class action under the CCPA following a data breach?
More than likely.
“Consumers” can bring suit under the CCPA if they can prove the following five elements:
- A business incurred a data breach;
- The data breach involved a sensitive category of information identified in California Civil Code Section 1798.81.5;
- The business had a legal duty to protect the personal information from breach;
- The business failed to implement reasonable security procedures and practices; and
- The business’s failure resulted in (i.e., caused) a data breach.
While the common definition of “consumer” suggests that it refers to an individual that has “consumed” a product or a service in relation to a company, the definition ascribed by the CCPA is far broader. The term is defined to include any “natural person who is a California resident.”1 Read literally, the phrase includes not only an individual that consumes a product (e.g., a customer of a store), but also that store’s California-based employees, and California-based business contacts or prospective customers.
It is worth noting that various legislative amendments have been proposed which would modify the definition of “consumer” to exclude employees. As of the date of publication, the only remaining proposed amendment concerning the applicability of the CCPA to employees would functionally delay the application of the CCPA’s privacy provisions to employee data an additional 12 months (i.e., until January 1, 2021), but not exempt employees altogether.2 Specifically, employees might still be able to bring suit following a data breach.
1. CCPA, Section 1798.140(g).
2. See Assembly Bill 25.
CCPA Security FAQs: Can non-California residents bring a class action under the CCPA following a data breach?
No.
“Consumers” can bring suit under the CCPA if they can prove the following five elements:
- A business incurred a data breach;
- The data breach involved a sensitive category of information identified in Cal. Civil Code Section 1798.81.5;
- The business had a legal duty to protect the personal information from breach;
- The business failed to implement reasonable security procedures and practices; and
- The business’s failure resulted in (i.e., caused) a data breach.
While the common definition of “consumer” suggests that it refers to an individual that has “consumed” a product or a service in relation to a company, the definition ascribed by the CCPA is that a “consumer” is any “natural person who is a California resident.”1 As a result individuals that are not residents of California are not permitted to bring suit under the statute.
1. CCPA, Section 1798.140(g) (emphasis added).
Do companies have to “flow down” access requests to service providers?
Probably.
When a business receives a request from a consumer to access the personal information that the business has “collected,” it must decide whether to grant the request or to deny it based upon one of the exceptions to access contained in the CCPA.1 If the business decides to grant the request and provide the personal information in its possession, the CCPA does not specifically state that the business must also direct its service providers to produce the personal information that may be in their possession. This contrasts with deletion requests where the CCPA expressly states that a business which intends to honor such a request must “direct any service providers to delete the consumer’s personal information from their records.”2
Although the CCPA does not expressly state that a business must direct its service providers to search for and produce information collected from a consumer, privacy advocates are likely to take the position that flowing down an access request is implicitly required for the following reasons:
- Service providers are an extension of a business. The CCPA states that a service provider “processes information on behalf of a business.”3 To the extent that a service provider functions as an agent of a business, an argument could be made that a failure by the business to instruct the service provider to search for and produce information could constitute a violation by the business itself.
- The CCPA refers to access to the information “collected.” The CCPA states that a consumer should be able to request access to the “specific pieces of personal information the business has collected.”4 To the extent that a business collects personal information and then transmits it to a service provider for storage or further processing, the personal information was still “collected” by the business and, therefore, may need to be identified and produced regardless of whether it currently resides with the business or with its service provider.
- Access requests under the European GDPR are typically flowed down. Like the CCPA, the European GDPR does not expressly state that a controller must flow down an access request to a processor. In practice, however, it is well accepted in Europe that if a controller grants an access request it should flow down an instruction to its processors to provide the impacted personal information. In turn, the GDPR requires processors to “assist[] the controller . . . [in] the fulfilment of the controller’s obligation to respond to requests for exercising data subject’s rights . . . .”5
The act of instructing service providers to provide personal information in response to a consumer’s request is often referred to as “flowing down” an access request, or an “access request flow down.”
Do cookie banners receive different acceptance rates on desktops and on smartphones?
Yes.
Most cookie banners can be classified into one of three general categories: (1) notice only banners, (2) notice + opt-out banners, and (3) notice + opt-in banners. If a company chooses to adopt a cookie banner that provides notice and solicits the opt-in consent (e.g., “I agree”) of website users, the company would have a strong argument that it does not need to disclose that it has sold information, does not need to forward deletion requests to the providers of its third party cookies, and does not need to include an “opt out of sale” link on its website.1
Companies often struggle with anticipating the percentage of users that are likely to accept the deployment of cookies when prompted. There is relatively little empirical data publicly available concerning website visitors’ interactions with cookie banners. The little data that does exist, however, indicates that user acceptance rates are significantly greater when a user visits a website on their smartphone. For example, in one study researchers placed the same cookie banner on the bottom-left of a website and on the bottom left bottom-left of a smartphone.2 They found that desktop visitors accepted the banner 18.4% of the time, whereas smartphone visitors accepted the same banner 26.4% of the time. When other variables were controlled the difference increased. So, for example, when the banner was adjusted to present only two options – accept or decline – the acceptance rate increased to 45.6% for smartphones while it remained around 20% for desktop users.3 The increase was likely caused by presenting options that were, from a user-experience perspective, easy to select on a smartphone.
Do job applicants need to be given a privacy notice?
Yes.
The CCPA applies to personal information held about “consumers” – a term which is defined as referring to any resident of California.1 As a result, if a business is governed by the CCPA, the rights conferred by the statute – including the right to receive a privacy notice — apply to any job applicants about whom the business collects personal information that are California residents.
Does the CCPA apply to cookies that are used for data analytics?
It is not clear.
The California Attorney General was asked to clarify whether the CCPA applies to a website that utilizes “cookies to track traffic” assuming that such cookies were not utilized to sell data or to market products.1 The Attorney General refused to provide guidance stating only that the determination as to whether cookies that track website traffic (e.g., analytics cookies) are governed by the Act “raises specific legal questions that may require a fact-specific determination.”2 The Attorney General further advised a business that utilizes such cookies to “consult with an attorney who is aware of all pertinent facts and relevant compliance concerns.”3
Although the California Attorney General did not specify what “facts” and “concerns” he believes are relevant to the analysis, whether an analytics cookie is governed by the CCPA arguably turns on the Act’s definition of “personal information.”
The phrase “personal information” is defined within the CCPA to mean any information that “identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.”4 The CCPA includes a non-exhaustive list of data types that might fall within that definition. That list includes “unique personal identifiers,”5 a term which itself is defined as including “cookies” that are used to “recognize a . . . device that is linked to a consumer or family, over time and across different services.”6 When the qualifiers found within the definition of “personal information” are combined the CCPA suggests that an analytics cookies should not be considered personal information regulated by the statute unless, at a minimum, the following three conditions are met:
- The analytics cookie is persistent (i.e., tracks “over time”),
- The analytics cookie is used to track across multiple websites (i.e., “across different services”), and
- The analytics cookie can “reasonably be linked” to a particular consumer or household (as opposed to a particular device that may, or may not, be shared among a number of individuals).
Does the CCPA apply to information about businesses?
The CCPA only applies to personal information about “consumers,” a term which is defined as “a natural person who is a California resident.”1 As corporations or other legal entities are not people, the CCPA does not apply to information that relates to them. That said, to the extent that information that relates to a business also relates to a real person, and either identifies them or makes the person identifiable, it would be within the scope of the CCPA. As an example, an online rating of a company called Best Dentist would not be governed by the CCPA. An online rating of an office named John Smith DDS (after the dentist that practices there) would (or will) be governed by the CCPA.
It is worth noting, however, that to the extent that information relates to an “employee, owner, director, officer, or contractor” of a company, the obligations of the CCPA phase in over time. Specifically, some provisions went into effect on January 1, 2020, such as possible liability following a data security breach that includes sensitive category information. Other provisions become effective on January 1, 2021, such as the ability of the employee, owner, director, officer, or contractor to request access to their personal information.2
Does the CCPA apply to the personal information of employees?
Yes.
The CCPA applies to personal information held about “consumers” – a term which is defined as referring to any resident of California.1 As a result, if a business is governed by the CCPA, the rights conferred by the statute apply to the business’s employees.
While the CCPA applies to data collected about employees, the California legislature passed an amendment in 2019 (Senate Bill 25) that effectively phased-in the rights afforded to employees over the course of 2020. Pursuant to the amendment, those provisions of the CCPA found within Sections 100(b) and 150 applied immediately to employees.2 These included the obligation that a business inform an employee “at or before the point of collection” of the personal information to be collected and the purposes for which the information will be used.3 They also included the ability of an employee to bring suit if an employer failed to adequately protect sensitive category information.5 Employee’s personal information was exempted from other provisions of the CCPA until January 1, 2021 (e.g., access rights, deletion rights, sale rights, etc.).5
Does the placement of a cookie banner impact user acceptance rate?
Yes.
Most cookie banners can be classified into one of three general categories: (1) notice only banners, (2) notice + opt-out banners, and (3) notice + opt-in banners. If a company chooses to adopt a cookie banner that provides notice and solicits the opt-in consent (e.g., “I agree”) of website users, the company would have a strong argument that it does not need to disclose that it has sold information, does not need to forward deletion requests to the providers of its third party cookies, and does not need to include an “opt out of sale” link on its website.1
Companies often struggle with how to display a cookie banner given the complexities of conveying information to individuals that may lack technical expertise, and “banner fatigue” – i.e., the fact that website visitors are presented with so many pop-ups and banners that they often do not spend the time to read banners that appear before closing them.
There is relatively little empirical data publicly available concerning website visitors interactions with cookie banners. The little data that does exist, however, indicates that user acceptance rates are significantly impacted by where a cookie banner is placed on a screen. For example, in one study researchers randomly placed the same cookie banner at the top, the top-left, the top-right, the bottom, the bottom-left, and the bottom-right of a website and then observed how 14,135 website visitors interacted with the banner.2 They found that when the banner was placed in a “bar” at the top of the page approximately 1.8% of visitors accepted cookies. When the same banner was placed on the bottom-left of the screen the acceptance rate jumped to 18.4%. While the researchers did not probe the cause of the difference, they suspected that the bottom-left placement was more likely to cover the main content of a website (in comparison, notices shown at the top often hide only design elements), and that website visitors were accustomed to the left-to-right directionality of Latin script. Both factors may cause viewers to interact with a cookie banner at the bottom left.
Does “personal information” include aggregate or de-identified information?
No.
By its terms, the definition of personal information excludes aggregated or de-identified information. Specifically, pursuant to an amendment enacted by the California legislature in late 2019, the definition of personal information was modified to state that “’[p]ersonal information’ does not include consumer information that is deidentified or aggregate consumer information.”1
If a company acquires another company, can it transfer the target’s data to its new affiliates for their marketing purpose?
Federal and state privacy laws do not expressly prohibit most acquirers (e.g., acquirers of a retail brand) from internally transferring the target’s data for use by affiliated companies. That said, in 2000, the Federal Trade Commission took the position that a company which had included a broad statement within its privacy notice that it would not share personal information with third parties could not transfer personal information as part of the sale and/or acquisition of the company unless the acquirer met certain threshold qualifications (e.g., hailed from the same industry).1 Forty-six states, the District of Columbia, and two federal territories took an even more restrictive position that the information could never be transferred to an acquirer.2 As a result of the positions taken by the FTC and state regulators, as a best practice, most organizations now include a clause within their privacy notices that affirmatively states that personal information may be shared as part of a merger or acquisition. For example, many companies include a provision along the following lines:
“If another company acquires, or plans to acquire, our company, business, or our assets, we will also share information with that company, including at the negotiation stage.”
If the target has a disclosure similar to the above, the acquirer arguably can take and disseminate to corporate affiliates the personal information collected by the target consistent with federal and (most) state laws.
This result is largely consistent with the approach taken by the California Consumer Privacy Act. The CCPA broadly defines the term “sale” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration” from one business to another.3 The CCPA includes an exception to the sale of information, however, in situations in which information is transferred as part of an acquisition in which the acquirer “assumes control of all or part of” the target.4 In those situations, the Act permits internal transfers to occur without classifying those transfers as “sales” so long as the information is “shared” consistently with the target’s privacy notice.5 On a going forward basis (i.e., post acquisition) the CCPA’s rules concerning affiliate sharing likely apply. Under those rules, an entity that is owned by another entity is considered a separate business unless the two companies “share[] common branding.”6 For the purposes of the statute “common branding” is defined as a “shared name, servicemark, or trademark.”7
The net result is that if a privacy notice states that information can be shared between and among acquirers and affiliates, such sharing is arguably permitted at the time of acquisition. On a go-forward basis, at least in California, the target would need to share common-branding with the acquirer in order to continue the sharing of information without raising the possibility that such continued use constitutes the “sale” of information for which an opt-out right would need to be given. That said, an amendment to the CCPA deferred the full impact of the Act upon employee data until January 1, 2021.8
If a company has California employees is it subject to the CCPA?
Not necessarily.
Although the CCPA’s definition of “consumer” includes employees that reside in California,1 the CCPA applies only to a “business” — a term that is defined as being an entity that “does business in the State of California” and that meets one of the following three thresholds:
- Annual gross revenue in excess of $25 million,
- Purchase, receives for commercial purposes, sells, or shares for commercial purposes, personal information of 50,000 or more consumers, or
- Derives 50% of annual revenue from selling consumer personal information.2
The net result is that if a business meets one of the three thresholds established for gross revenue, quantity of data points, or revenue-generated by the sale of personal information, and has California employees, then it will be subject to the CCPA. If a business does not meet one of the three thresholds set forth above, but has California employees, then it will not be subject to the CCPA.
If an App asks users to consent to a privacy notice, and the privacy notice discloses that the App shares user information with AdTech partners, would that sharing be considered a “sale?”
Arguably not.
Some privacy advocates and plaintiffs’ attorneys have argued that the CCPA’s broad definition of the term “sell” might encompass the transmission of user information from an App to an AdTech partner. Specifically, they claim that the CCPA considers any “disclos[ure]” of personal information to be a “sale” when a company receives “monetary or other valuable consideration.” As the definition of “personal information” includes “unique identifiers” – a term which includes “mobile ad identifiers, or similar technology” – the act of transmitting information about a user’s device to an AdTech partner that then leads to ad revenue should be considered a “sale” for the purposes of the Act.
While the definition of “sale” under the CCPA contains an exception for situations in which information is shared with a service provider, that exception may not apply to all AdTech partners.1 Specifically, to invoke the service provider exception the contract between an App publisher and an AdTech partner must “prohibit” the partner “from retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract with the business.”2 Behavioral advertising networks that retain the information that they obtain from Apps and use that information for the benefit of themselves (or the benefit of other members of a behavioral advertising network) may not satisfy the definition of a “service provider.”
The definition of “sale” under the CCPA contains a second exception for situations in which a “consumer uses or directs the business to intentionally disclose personal information or uses the business to intentionally interact with a third party.”3 In order to mitigate the risk that sending user information to AdTech partners might be interpreted as a “sale” of information, some App publishers disclose that they transmit information to AdTech partners in their privacy notices, and then ask users to consent to those notices (and, hence, consent to the sharing of their information). If the App publisher obtains consent to its privacy notice, it could argue that the consumer has “direct[ed] the business to intentionally disclose” information and, therefore, the transfer of information is not a sale. The strength of such an argument may depend, in part, on the prevalence of the privacy notice, and the manner in which consent is solicited and obtained.
If an App asks users to consent to the sharing of their information with AdTech partners, would that sharing be considered a “sale?”
No.
Many Apps transmit information about their users to third party advertising technology companies to facilitate the placement of targeted advertising within the App which, in turn, generates advertising revenue for the App publisher.
Some privacy advocates, and plaintiffs’ attorneys, have argued that the CCPA’s broad definition of the term “sell” might encompass such activities. Specifically, they claim that the CCPA considers any “disclos[ure]” of personal information to be a “sale” when a company receives “monetary or other valuable consideration.” As the definition of “personal information” includes “unique identifiers” – a term which includes “mobile ad identifiers, or similar technology” – they have argued that the act of transmitting information about a user’s device to an AdTech partner should be considered a “sale” for the purposes of the Act.
While the definition of “sale” under the CCPA contains an exception for situations in which information is shared with a service provider, that exception may not apply to all AdTech partners.1 Specifically, to invoke the service provider exception the contract between an App publisher and an AdTech partner must “prohibit” the partner “from retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract with the business.”2 Behavioral advertising networks that retain the information that they obtain from Apps and use that information for the benefit of themselves (or the benefit of other members of a behavioral advertising network) may not satisfy the definition of a “service provider.”
The definition of “sale” under the CCPA contains a second exception for situations in which a “consumer uses or directs the business to intentionally disclose personal information or uses the business to intentionally interact with a third party.”3 In order to mitigate the risk that sending user information to AdTech partners might be interpreted as a “sale” of information, some App publishers ask users to consent to the sharing of their information. If the App publisher obtains consent, it would have a strong argument that the consumer has “direct[ed] the business to intentionally disclose” their information and, therefore, the transfer of information is not a sale.
In response to an access request, does a company have to produce all of the information that it has about an individual?
Maybe.
The CCPA requires a business to respond to an access request by disclosing all information that it has “collected” about a consumer in the previous 12 months.1 Unlike the CCPA’s treatment of a business’s obligation to delete information, the Act provides very few exceptions to a business’s obligation to provide access to information.
Although the “access” obligation is undoubtedly broad, it is somewhat limited by how the CCPA interacts with other statutes, rights, and other obligations. Under the CCPA:
- The rights of one consumer “shall not adversely affect the rights…of other consumers,2 and
- Individuals whose information has been subject to “an unauthorized access…or disclosure” can recover statutory damages.3
A business’s response to an access request must take these provisions into consideration. For example, a business may not be able to provide access to CCTV footage if there is a third party in the video, as this would infringe upon the third party’s privacy rights. Similarly, a business may not be able to provide access to internal documents regarding a consumer as it could be construed as an unauthorized disclosure of the document creator’s personal information.
A case could also be made that the right of “access” is somewhat limited by the term “collect.” Under the CCPA, “collect” means:
[B]uying, renting, gathering, obtaining, receiving, or accessing any personal information pertaining to a consumer by any means. This includes receiving information from the consumer, either actively or passively, or by observing the consumer’s behavior.4
Arguably, this definition does not include information that is “created” internally, even if it relates to the consumer. At face value, all of the terms describing “collect” refer to information that already exists, so information that is “created” by the business may not need to be disclosed. Internally developed or created information may include:
- Inferences about a consumer
- Background programming
- Background responses (e.g., internal responses to consumer requests and/or consumer activity)
- Internal information unrelated to the consumer (e.g., background data describing a web page that the consumer navigated to)
- Internal notes about a consumer
For example, if a consumer contacts a retailer to request a purchase return, some information relating to the return is “collected” and some is not. The information given to the retailer during the request phase ̶ such as the consumer’s name, phone number, mailing address, and the request made ̶ is certainly “collected” under the CCPA and would need to be disclosed pursuant to an access request. Other information generated after the request is made ̶ such as internal return protocols, the refund date, the retailer’s response to the consumer, fraud detection protocols, internal notes, and inferences made about the consumer’s purchasing behavior ̶ is arguably not “collected” under the CCPA and would not need to be disclosed pursuant to an access request.
In response to an access request, does a company have to produce information about its transactions and experiences with an individual?
The CCPA requires a business to respond to an access request by disclosing all information that it has “collected” about a consumer in the previous 12 months.1 Unlike the CCPA’s treatment of a business’s obligation to delete information, the Act provides very few exceptions to a business’s obligation to provide access to information.
Although the “access” obligation is undoubtedly broad, it is somewhat limited by how the CCPA interacts with other statutes, rights, and other obligations. Under the CCPA:
- The rights of one consumer “shall not adversely affect the rights…of other consumers,2 and
- Individuals whose information has been subject to “an unauthorized access…or disclosure” can recover statutory damages.3
A business’s response to an access request must take these provisions into consideration. For example, a business may not be able to provide access to internal documents regarding a consumer (i.e. internal notes about a customer service representative’s experience with the consumer) as it could be construed as an unauthorized disclosure of the document creator’s personal information.
A case could also be made that the right of “access” is somewhat limited by the term “collect.” Under the CCPA, “collect” means:
[B]uying, renting, gathering, obtaining, receiving, or accessing any personal information pertaining to a consumer by any means. This includes receiving information from the consumer, either actively or passively, or by observing the consumer’s behavior.4
Arguably, this definition does not include information that is “created” internally, even if it relates to the consumer. At face value, all of the terms describing “collect” refer to information that already exists, so information that is “created” by the business may not need to be disclosed. Internally developed or created information may include:
- Inferences about a consumer
- Background responses (e.g., internal responses to consumer requests and/or consumer activity)
- Internal notes about a consumer
For example, if a consumer contacts a retailer to request a purchase return, some information relating to the return is “collected” and some is not. The information given to the retailer during the request phase ̶ such as the consumer’s name, phone number, mailing address, and the request made ̶ is certainly “collected” under the CCPA and would need to be disclosed pursuant to an access request. Other information generated after the request is made ̶ such as internal return protocols, the refund date, the retailer’s response to the consumer, fraud detection protocols, internal notes, and inferences made about the consumer’s purchasing behavior ̶ is arguably not “collected” under the CCPA and would not need to be disclosed pursuant to an access request.
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.1798.100(b).
2. 1798.145(j).
3. 1798.150(a).
4. 1798.140(e).
In response to an access request, does a company have to produce its internal notes relating to an individual?
Maybe.
The CCPA requires a business to respond to an access request by disclosing all information that it has “collected” about a consumer in the previous 12 months.1 Unlike the CCPA’s treatment of a business’s obligation to delete information, the Act provides very few exceptions to a business’s obligation to provide access to information.
Although the “access” obligation is undoubtedly broad, it is somewhat limited by how the CCPA interacts with other statutes, rights, and other obligations. Under the CCPA:
- The rights of one consumer “shall not adversely affect the rights…of other consumers,2 and
- Individuals whose information has been subject to “an unauthorized access…or disclosure” can recover statutory damages.3
A business’s response to an access request must take these provisions into consideration. For example, a business may not be able to provide access to internal documents regarding a consumer (i.e. internal notes about a customer service representative’s experience with the consumer) as it could be construed as an unauthorized disclosure of the document creator’s personal information.
A case could also be made that the right of “access” is somewhat limited by the term “collect.” Under the CCPA, “collect” means:
[B]uying, renting, gathering, obtaining, receiving, or accessing any personal information pertaining to a consumer by any means. This includes receiving information from the consumer, either actively or passively, or by observing the consumer’s behavior.4
Arguably, this definition does not include information that is “created” internally, even if it relates to the consumer. At face value, all of the terms describing “collect” refer to information that already exists, so information that is “created” by the business may not need to be disclosed. Internally developed or created information may include:
- Inferences about a consumer
- Background responses (e.g., internal responses to consumer requests and/or consumer activity)
- Internal notes about a consumer
For example, if a consumer contacts a retailer to request a purchase return, some information relating to the return is “collected” and some is not. The information given to the retailer during the request phase ̶ such as the consumer’s name, phone number, mailing address, and the request made ̶ is certainly “collected” under the CCPA and would need to be disclosed pursuant to an access request. Other information generated after the request is made ̶ such as internal return protocols, the refund date, the retailer’s response to the consumer, fraud detection protocols, internal notes, and inferences made about the consumer’s purchasing behavior ̶ is arguably not “collected” under the CCPA and would not need to be disclosed pursuant to an access request.
In response to an access request, does a company have to produce its own work product?
Maybe.
The CCPA requires a business to respond to an access request by disclosing all information that it has “collected” about a consumer in the previous 12 months.1 Unlike the CCPA’s treatment of a business’s obligation to delete information, the Act provides very few exceptions to a business’s obligation to provide access to information.
Although the “access” obligation is undoubtedly broad, it is somewhat limited by how the CCPA interacts with other statutes, rights, and other obligations. Under the CCPA:
- The rights of one consumer “shall not adversely affect the rights…of other consumers,2 and
- Individuals whose information has been subject to “an unauthorized access…or disclosure” can recover statutory damages.3
A business’s response to an access request must take these provisions into consideration. For example, a business may not be able to provide access to internal documents regarding a consumer as it could be construed as an unauthorized disclosure of the document creator’s personal information.
A case could also be made that the right of “access” is somewhat limited by the term “collect.” Under the CCPA, “collect” means:
[B]uying, renting, gathering, obtaining, receiving, or accessing any personal information pertaining to a consumer by any means. This includes receiving information from the consumer, either actively or passively, or by observing the consumer’s behavior.4
Arguably, this definition does not include information that is “created” internally, even if it relates to the consumer. At face value, all of the terms describing “collect” refer to information that already exists, so information that is “created” by the business may not need to be disclosed. Internally developed or created information may include:
- Inferences about a consumer
- Background programming
- Background responses (e.g., internal responses to consumer requests and/or consumer activity)
- Internal information unrelated to the consumer (e.g., background data describing a web page that the consumer navigated to)
- Internal notes about a consumer
For example, if a consumer contacts a retailer to request a purchase return, some information relating to the return is “collected” and some is not. The information given to the retailer during the request phase ̶ such as the consumer’s name, phone number, mailing address, and the request made ̶ is certainly “collected” under the CCPA and would need to be disclosed pursuant to an access request. Other information generated after the request is made ̶ such as internal return protocols, the refund date, the retailer’s response to the consumer, fraud detection protocols, internal notes, and inferences made about the consumer’s purchasing behavior ̶ is arguably not “collected” under the CCPA and would not need to be disclosed pursuant to an access request.
Is encrypted data out of the scope of the CCPA?
In some cases yes, and in other cases no.
The CCPA defines “personal information” as information that, among other things, “is capable of being associated with” a particular consumer.1 Conversely, the CCPA refers to information as “deidentified” if it “cannot reasonably” be “associated with” a particular consumer.2
In situations in which a company encrypts personal information, but maintains the means to decrypt the information (e.g., a password or an encryption key), an argument exists that while the encrypted information remains in the possession of the business, it is “capable” of being associated with a consumer. In such a situation, most of the requirements of the CCPA would apply with one important exception. The private right of action conferred by the CCPA to bring suit following a data breach only applies in the context of “nonencrypted” information that has been disclosed.3 As a result, if the business accidentally disclosed the encrypted information (or if the encrypted information were accessed by a malicious third party), the business should not be liable for the statutory liquidated damages identified in the Act.
In situations in which a company receives, stores, or transmits encrypted information, but does not have the means to decrypt it (e.g., acts simply as a transmission conduit), a strong argument exists that the information “cannot reasonably” be associated with a particular consumer and, as a result, is not personal information subject to the CCPA.
In comparison to the CCPA, the European GDPR recognizes encryption as a security technique that may help keep personal data safe, but the GDPR does not state that encrypted data is no longer personal data; nor does the GDPR state that encrypted data is not governed by the Regulation.4 To the contrary, the Article 29 Working Party5 held the opinion that encryption does not “per se lend[ ] itself to the goal of making a data subject unidentifiable” and “it does not necessarily result in anonymisation.”6
Is it possible for a token to still be considered “personal information?”
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).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
- 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.
- 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.
- 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.
- 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
Is it possible for data that has undergone hashing to still be considered “personal information?”
Maybe.
Hashing refers to the process of using an algorithm to transform data of any size into a unique fixed sized output (e.g., combination of numbers). To put it in layman’s term, some piece of information (e.g., a name) is run through an equation that creates a unique string of characters. Anytime the exact same name is run through the equation, the same unique string of characters will be created. If a different name (or even the same name spelled differently) is run through the equation, an entirely different string of characters will emerge.
While the output of a hash cannot be immediately reversed to “decode” the information, if the range of input values that were submitted into the hash algorithm are known, they can be replayed through the hash algorithm until there is a matching output. The matching output would then confirm, or indicate, what the initial input had been. For instance, if a Social Security Number was hashed, the number might be reverse engineered by hashing all possible Social Security Numbers and comparing the resulting values. When a match is found, someone would know what the initial Social Security Number that created the hash string was. The net result is that while hash functions are designed to mask personal data, they can be subject to brute force attacks.
Whether a hash value in and of itself is 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.”1 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.”2 An argument could be made that data once hashed 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 hashed data will not be re-identified:3
- Implement technical safeguard that prohibit reidentification. Technical safeguards may include the process or techniques by which data has been deidentified. For example, this might include the hashing algorithm being used, or combining the hashed algorithm with other techniques that are designed to further obfuscate information (e.g., salting).4
- Implement business processes that specifically prohibit reidentification. This might include an internal policy or procedure that prevents employees or vendors from attempting to reidentify data or reverse hashed values.
- Implement business processes to prevent inadvertent release of deidentified information. This might include a policy against disclosing hashed values to the public.
- 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 considered hashing to be a technique for pseudonymization that “reduces the linkability of a dataset with the original identity of a data subject” and thus “is a useful security measure,” but is “not a method of anonymisation.6 In other words, from the perspective of the Article 29 Working Party while hashing might be a useful security technique it was not sufficient to convert “personal data” into deidentified data.
Is it possible for data that has undergone salted-hashing to still be considered “personal information?”
Maybe.
“Salting” refers to the insertion of a random value (e.g., a number or a letter) into personal data before that data is hashed.
Whether personal information that has undergone salting and hashing 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.”1 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.”2 A strong argument could be made that data that is salted and then hashed 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 salted and hashed data will not be re-identified:3
- Implement technical safeguard that prohibit reidentification. Technical safeguards may include the process or techniques by which data has been deidentified. For example, this might include the hashing algorithm being used or the number of characters inserted as part of the salting process.4
- Implement business processes that specifically prohibit reidentification. This might include an internal policy or procedure that prevents employees or vendors from attempting to reidentify data or reverse the salted and hashed values.
- Implement business processes to prevent inadvertent release of deidentified information. This might include a policy against disclosing hashed values to the public.
- 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 while the technique of salting and then hashing data “reduce[s] the likelihood of deriving the input value,” because “calculating the original attribute value hidden behind the result of a salted hash function may still be feasible within reasonable means,” the salted-hashed output should be considered pseudonymized data that remains subject to the GDPR.6
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. CCPA, Section 1798.145(a)(5).
2. CCPA, Section 1798.140(h).
3. CCPA, Section 1798.140(v).
4. Salting refers to the insertion of characters into data before it is hashed to make brute force reidentification more difficult.
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 20 (adopted 10 April 2014).
Is the CCPA’s definition of “biometric information” broader than the definition used by other states?
The CCPA defines “personal information” broadly as any information that “identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.”1 The statute includes a non-exhaustive list of eleven categories of data that may fall under that definition. One of those categories is “biometric information.”2
While the CCPA provides a definition of “biometric information,” it is worth noting that the CCPA’s definition differs from the definition of the term within other statutes and legal systems. The following provides a side-by-side comparison of the definition within the CCPA and the definition within the Illinois Biometric Information Privacy Act (“BIPA”). In some ways, the California definition may be broader, as it purports to include such things as “imagery” of an individual’s palm or vein patterns, and voice recordings, so long as an “identifier template” can be created from such data. It also purports to include characteristics such as “keystroke patterns or rhythms” that would rarely be considered “biometric data” by consumers or in other privacy statutes:
CCPA3 | Illinois Biometric Information Privacy Act (“BIPA”)4 |
“Biometric information” means an individual’s physiological, biological, or behavioral characteristics, including an individual’s deoxyribonucleic acid (DNA), that can be used, singly or in combination with each other or with other identifying data, to establish individual identity. Biometric information includes, but is not limited to, imagery of the iris, retina, fingerprint, face, hand, palm, vein patterns, and voice recordings, from which an identifier template, such as a faceprint, a minutiae template, or a voiceprint, can be extracted, and keystroke patterns or rhythms, gait patterns or rhythms, and sleep, health, or exercise data that contain identifying information. | “Biometric information” means any information, regardless of how it is captured, converted, stored, or shared, based on an individual’s biometric identifier used to identify an individual. Biometric information does not include information derived from items or procedures excluded under the definition of biometric identifiers.
“Biometric identifier” means a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry. Biometric identifiers do not include writing samples, written signatures, photographs, human biological samples used for valid scientific testing or screening, demographic data, tattoo descriptions, or physical descriptions such as height, weight, hair color, or eye color. Biometric identifiers do not include donated organs, tissues, or parts as defined in the Illinois Anatomical Gift Act or blood or serum stored on behalf of recipients or potential recipients of living or cadaveric transplants and obtained or stored by a federally designated organ procurement agency. Biometric identifiers do not include biological materials regulated under the Genetic Information Privacy Act. Biometric identifiers do not include information captured from a patient in a health care setting or information collected, used, or stored for health care treatment, payment, or operations under the federal Health Insurance Portability and Accountability Act of 1996. Biometric identifiers do not include an X-ray, roentgen process, computed tomography, MRI, PET scan, mammography, or other image or film of the human anatomy used to diagnose, prognose, or treat an illness or other medical condition or to further validate scientific testing or screening.
|
Is the disclosure of personal information for purposes of creating a look-alike audience a “sale” under the CCPA?
Sometimes.
Many companies today use “look-alike audiences” (a.k.a “mirror audiences” or “similar audiences”) to reach potential consumers through online advertising. A look-alike audience is created when a business sends information, typically in hashed form, about a group of its current customers (the “seed audience”) to an advertising platform who matches the seed audience to an entirely new audience (the “look-alike audience”). The matching process uses the aggregated seed audience information to identify new individuals who have similar purchase habits, preferences, search histories, or other relevant traits. After the match is complete and the look-alike audience created, the advertising platform then serves the business’s ads directly to the look-alike audience.1 While the use of a look-alike audience can offer significant advantages to a company, it can also raise concerns that a company is “selling” personal information as defined by the CCPA.
Depending on the underlying contractual terms, the business’s initial transfer of customer’s personal data to the advertising platform could be considered a “sale” under the CCPA. The CCPA broadly defines “sale” to include “selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating…a consumer’s personal information by the business to another business or a third party for monetary or other valuable consideration.”2 As such, the very act of transferring the data arguably falls within this broad definition, since the business almost certainly gets valuable consideration in return.
However, a “sale” does not include sharing information with a “service provider.” A “service provider” includes an entity who “process[es] information on behalf of a business and to which a business discloses a consumer’s personal information for a business purpose pursuant to a written contract.”4 Importantly, the contract must prohibit the entity from “retaining, using, or disclosing” the personal information for any purpose other than to perform the services specified in the contract.5 The contractual terms between the business and the advertising company governing the creation of the look-alike audience, such as the advertising platform’s terms of service, may exclude the initial data transfer from the definition of “sale” by qualifying the advertising platform as a “service provider.” Each advertising platform has different contractual terms, so in order to determine whether the creation of a look-alike audience is a “sale” under the CCPA, a business must determine the following:
- Does the contract prohibit the advertising platform from “using” the data for any purpose other than to create the look-alike audience?
- Does the contract prohibit the advertising platform from “disclosing” the data to another third party except for the purposes of creating the look-alike audience?
- Does the contract prohibit the advertising platform from “retaining” the data longer than as necessary to create the look-alike audience?
If the contract fails to do any of those three things, or the contract does not govern all of the personal information subject to the transfer, the transfer of data to the advertising platform is likely a “sale” under the CCPA.
Stop the CCPA Fearmongering: Loyalty Programs Will Survive
Anytime a new statute or regulation comes along, some law firms unfortunately flag issues that may not be of true concern to companies, or highlight problems that may not, in fact, exist. Unfortunately, that continues to happen in connection with the California Consumer Privacy Act (“CCPA”). In the context of retailer loyalty or reward programs, firms have said that the CCPA may spell the “end of loyalty programs,” or implied that the CCPA could lead to “the potential elimination of loyalty programs due to the nondiscrimination requirements.” Some law firms have gone so far as to advise retailers to “address the issue[s]” caused by their loyalty programs by “not offer[ing] preferential pricing through loyalty programs” or by “mak[ing] loyalty program pricing available to all customers” regardless of whether they are, in fact, members of the loyalty program. Such changes would, of course, destroy the business-case for having a loyalty program in the first place.
These concerns are incorrect and demonstrate a lack of understanding of the requirements of the CCPA. While the Act is, without a doubt, flawed, poorly drafted, and prone to misinterpretation, it does not lead to the conclusion that most loyalty programs are inherently problematic, nor should it cause most retailers to drastically change the terms and structure of their program. The hyperbolic treatment of loyalty programs by some law firms may also have contributed to several companies and industry groups echoing these concerns with the California legislature and the California Attorney General and alleging (incorrectly) that “the CCPA may prevent[] marketers from offering loyalty programs,” or that the CCPA, as currently written, prohibits “tiered pricing, discounts or coupons.”
The following dispels five (mis)statements that have been made in connection with the CCPA’s impact on loyalty programs.
1. Myth: The CCPA prohibits “charging different prices or rates for goods or services.”
It does not.
The prohibition against price discrimination in the CCPA only applies to situation in which a consumer exercises a right conferred by the CCPA. Nothing within the CCPA confers a right to join (or not join) a loyalty program. For more information, see FAQ: Is a business prohibited from giving discounts to loyalty program members?
2. Myth: The CCPA states that the benefit provided to the consumer through a loyalty program must be reasonably related to the value provided to the business by the consumer’s data.
It does not.
As indicated above, the CCPA prohibits a business from engaging in price discrimination when a consumer exercises a right under the CCPA. The CCPA provides an exception to that prohibition when the discrimination relates to a “price or difference” that is related to the value provided to a business by the consumer’s data.1
While some lawyers have misinterpreted this as requiring that all loyalty program benefits be related to the value provided to the business by the consumer’s data, as noted above, the operation of the loyalty program itself is not prohibited by the CCPA and, thus, does not require the benefit of this exception.
For more information, see FAQ: Does a loyalty program benefit have to relate to the value provided to a business by consumer data?
3. Myth: Businesses must honor deletion requests for loyalty members.
They generally do not.
One of the rights conferred by the CCPA is the ability of a consumer to request that a business delete personal information “which the business has collected from the consumer.”2 While numerous retailers have expressed confusion regarding whether that right requires the deletion of loyalty program related data, it is important to remember the right to deletion is not an absolute right and may rarely apply in the context of a loyalty program.
As an initial matter, because the right to deletion is limited to information that the business has collected “from” the consumer, if a business receives a deletion request under the CCPA, there is a strong argument that the business is permitted to keep information about the consumer that it developed itself (e.g., its transactions or experiences with the consumer), or information that it received from third parties (e.g., third party businesses that may participate in the loyalty program). As this information was not collected “from” the consumer, it arguably does not fall within the gambit of a deletion right.
In connection with information that is collected directly from a consumer (e.g., name, email address, enrollment details, etc.), there are several exceptions to the CCPA which would allow a business to refuse a deletion request. For more information about each of those exceptions, and a description of how they apply to most loyalty programs, see FAQ: Is a business required to delete loyalty program information if it receives a deletion request from an active member? and FAQ: Is a business required to delete loyalty program information if it receives a deletion request from an inactive member?
4. Myth: Businesses that offer loyalty programs must include a “do not sell my personal information” link.
Not necessarily.
The CCPA requires that a business that sells personal information disclose within its privacy policy a “list of the categories of personal information it has sold about consumers in the preceding 12 months.”3 The business must then include a link on its homepage titled “Do Not Sell My Personal Information” and allow consumers to opt-out of the sale.
The net result is that if a business sells loyalty program information, the business must disclose that fact and then include a “Do Not Sell” link; if a business does not sell loyalty program information, the business is not required to include such a link.
For more information go to FAQ: Is a business required to post a “do not sell” link if it offers a loyalty program?
5. Myth: Businesses that allow consumers to redeem points with third parties are selling information.
They generally are not.
The CCPA broadly defines the term “sale” as including the act of “disclosing” or “making available” personal information “for monetary or other valuable consideration” from one business to another.4 In the context of loyalty programs, it is not unusual for the operator of a loyalty program to enter into an agreement with a business partner (e.g., another company) to permit a consumer to redeem points accumulated through the loyalty program of business A in order to receive goods or services provided by business B. For example, a hotel may have an agreement with a car rental service through which a consumer can redeem hotel loyalty points to receive a free car rental.
Such redemption arrangements may require the disclosure of personal information from one business (e.g., business A) to a second business (e.g., business B), and may include the payment of money or other consideration for the ability to receive advertising or promotion as a rewards provider. As a result, and depending upon the structure of the business relationships, it is possible that, at first glance, the arrangement could fit the definition of “sale” under the CCPA.
Assuming that the transfer of information to a redemption partner did satisfy the definition of a “sale,” the CCPA contains an exception for situations in which a “consumer uses or directs the business to intentionally disclose personal information.”5 As a result, if a consumer uses a loyalty program in order to interact with another business, or directs a loyalty program to disclose personal information as part of a points redemption, the loyalty program operator arguably has not “sold” information.
For more information, go to FAQ: If a business allows consumers to redeem loyalty program benefits for products or services offered by a partner, does that constitute the sale of information?
Under the CCPA, can a conference organizer transfer personal information of attendees to sponsors?
Yes.
Conference and event organizers often provide lists of conference attendees to third parties that sponsor (or exhibit at) the conference. While nothing within the CCPA prohibits such information from being shared, the transfer of information may, or may not, be considered a “sale” depending upon the following factors:
- Did the sponsor or exhibitor provide consideration for the data? The CCPA defines “sale” to include the disclosure of personal information by one business to another “for monetary or other valuable consideration.”1 To the extent that the motivation of a business to sponsor a conference is not related to the receipt of personal information (e.g., brand recognition, speaking opportunities, etc.) they may be able to argue that the receipt of personal information was ancillary to their sponsorship and because such information was not the object of the consideration provided, consideration was not tendered for it.
- Did the sponsor or exhibitor obtain the consent of the attendees to have their information shared? The CCPA exempts from the definition of “sale” situations in which a consumer “directs the business to intentionally disclose personal information or uses the business to intentionally interact with a third party . . . .”2 As a result, if a conference organizer asks for, and obtains the consent or authorization of conference attendees to share their information with sponsors or exhibitors there would be a strong argument that the information was not sold.
What concerns do website owners have with the IAB’s final CCPA Do Not Sell Framework?
The Interactive Advertising Bureau (“IAB”) is a trade association comprised of companies that participate in digital marketing. Its members include both media companies and advertising technology (“adTech”) companies.
In October of 2019, the IAB published a draft IAB CCPA Compliance Framework for Publishers & Technology Companies (the “Draft IAB Do Not Sell Framework”).1 The draft proposed that website owners would provide consumers with a “do not sell” link, transmit a do not sell signal to IAB framework participants if a consumer opted-out, and the framework participants would agree to abide by a “Limited Service Provider Agreement” in their treatment of such data. The proposal was presented as a means of complying with the CCPA’s requirement that companies disclose if they sell personal information, and, if a sale is occurring, include a “Do Not Sell My Personal Information” link on their website.2
Numerous questions and concerns were raised by privacy advocates and the business community with the draft. In December, the IAB released a final version of the framework (the “IAB Do Not Sell Framework”) which addressed some (but not all) of those concerns. The following are some of website owners’ concerns with the viability of the framework as it was finalized:
- Website owners would be contractually limited to dealing with adTech companies that participate in the framework. The IAB Do Not Sell Framework effectuates a do not sell request by attempting to convert adTech companies that have joined the framework, and that have executed a “Limited Service Provider Agreement” provided by the IAB, into “service providers” when such companies receive a do not sell signal from a website owner. From a website owner’s perspective, however, if they participate in the IAB Do Not Sell Framework they are effectively self-restricting the adTech companies with whom they can partner to those that have joined the framework. Specifically the Limited Service Provider Agreement that website owners are required to accept requires that they represent and warrant that if a consumer clicks their do not sell link the website owner will “only” transmit “bid requests . . . to Downstream Participants that are Signatories” of the IAB Do Not Sell Framework.3 Given uncertainty concerning how many companies in the behavioral advertising ecosystem will join the framework, many website owners are concerned about the cost, and the potential disruption, that could be involved in (1) identifying which of their behavioral advertising partners have joined the framework, (2) terminating relationships with behavioral advertising companies that choose not to participate in the framework, and (3) conducting ongoing monitoring of behavioral advertising partners to ensure that they continue their framework participation.
- Website owners that continue to transmit data to non-IAB participants could be alleged to have engaged in deceptive practices. The IAB Do Not Sell Framework requires that website owners post a “do not sell my personal information” link on their website, and disclose in their privacy notice that by clicking the link a consumer’s information will no longer be sold. To the extent that the website owner continues to transmit data to non-IAB participants (i.e., companies that have neither entered the IAB Do Not Sell Framework, or agreed via a separate contract to refrain from using, sharing, or disclosing information that they receive from the website owner for their own purpose if the website owner broadcasts the IAB do not sell signal) it is possible that a regulator or a privacy advocate may allege that the website owner has misrepresented the effect of clicking on the Do Not Sell link.
- The effectiveness of the Limited Service Provider Agreement is unknown. In order for a company to be considered a “service provider” under the CCPA the Act states that there must be a “written contract” and implies that the contract must be “with the business.”4 Although the “Limited Service Provider Agreement” published by the IAB purports to be a contract between and among “all other Signatories to this Agreement” there is ambiguity about whether a court will interpret such an arrangement as a sufficient “contract” between a website owner and downstream adTech companies.5 Furthermore, although the Limited Service Provider Agreement purports to take precedence over pre-existing contracts entered into between a website owner and its adTech partners, the order of precedence identified in the Limited Service Provider Agreement may itself conflict with priority designations within those existing contracts.6 Existing contracts may also prohibit, or nullify, contractual arrangements, like the Limited Service Provider Agreement, that are created without bilateral signatures from both parties.
- IAB, and the adTech participants, refuse to accept any liability for the effectiveness of the framework. The “Limited Service Provider Agreement” disclaims any representation that the the IAB Do Not Sell Framework complies with the CCPA. To the contrary it states that “changes in the interpretation of the CCPA by an enforcement authority or court of competent jurisdiction . . . may hold that this Agreement, in whole or in part, is not permissible.”7 The IAB reiterates its reluctance to warrant that its framework complies with the CCPA in the IAB CCPA Compliance Framework for Publishers & technology Companies document itself where it states that the “IAB make[s] no representations or warranties, express or implied, as to the completeness, correctness, or utility of the information contained in this Framework and the accompanying Agreement and assume no liability of any kind whatsoever resulting from the use or reliance upon its contents.”8 The reluctance to assume any monetary liability if a CCPA penalty is assessed as a result of the use of the framework is reiterated in the Limited Service Provider Agreement where it states in all CAPS that “IN NO EVENT WILL A SIGNATORY BE LIABLE TO ANY OTHER SIGNATORY . . . FOR ANY DAMAGES OF ANY KIND . . . ARISING FROM OR RELATING TO THIS AGREEMENT, REGARDLESS OF WHETHER SUCH SIGNATORY WAS ADVISED, HAD OTHER REASON TO KNOW, OR IN FACT KNEW OF THE POSSIBILITY THEREOF.”9 It is unclear to what extent website owners who may be directly liable for a violation of the CCPA will be comfortable relying upon a compliance framework that ascribes no liability to their adTech partners.
- The Limited Service Provider Agreement may erode existing liability protections. To the extent that a website owner has entered into a separate contract with an adTech partner that provides contractual remedies (e.g., damages) if the adTech partner fails to comply with data privacy laws, the Limited Service Provider Agreement may erode those protections. Specifically, the Limited Service Provider Agreement states that in the face of a conflict with pre-existing contract terms, the Limited Service Provider Agreement will take precedence in connection with the “Sale and/or use of Personal Information.”10 As the Limited Service Provider Agreement states that “IN NO EVENT WILL A SIGNATORY BE LIABLE TO ANY OTHER SIGNATORY . . . FOR ANY DAMAGES OF ANY KIND” an adTech company may attempt to argue that any monetary recovery permitted by an underlying agreement is eroded by the Limited Service Provider Agreement.11
- Device/Browser level opt-out may not comply with the CCPA. The IAB Do Not Sell Framework appears to contemplate that when a user clicks on a website owner’s Do Not Sell My Personal Information link it would typically trigger a “Device/Browser Level Opt Out.”12 A “Device/Browser Level Opt Out means that the consumer’s instruction for their information not to be sold would only apply “to the particular device (e.g., mobile or desktop hardware unit) or browser on which the applicable Consumer has Opted Out.”13 It is unclear whether a device-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and the requirement that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”14 Put differently, while the CCPA prohibits a business from selling a consumer’s personal information after they click a Do Not Sell link, under the IAB Do Not Sell Framework it would appear that a consumer’s personal information would continue to be sold each time they visit a website owner’s site from a different device or a different browser.
- Failure to adequately disclose device/browser level opt-out could result in allegations of deception. The draft IAB Do Not Sell Framework suggested that websites notify consumers who opted out under the framework that if they visited the website from a different device (e.g., a work computer instead of a smartphone, or a smartphone instead of a personal computer) their information would again be sold until, or unless, the consumer submitted a new opt-out request on the new device.15 Specifically it required website owners to state in their privacy notices that “opt out is at a device level and how to opt out across different devices.”16 Interestingly, the final IAB Do Not Sell Framework does not contain such an explicit requirement and instead requires the website owner to generally explain “the effective scope of the opt out.”17 If a website owner does not accurately describe to consumers that the IAB Do Not Sell Framework’s opt-out mechanism appears to be limited to the device/platform used by the consumer to submit an opt-out request, privacy advocates may attempt to allege that the website owner has misrepresented the consumers’ ability to opt-out.”18
- Non-persistent opt-outs may not comply with the CCPA. When a user clicks on a website’s Do Not Sell My Personal Information link, it appears that the framework contemplates that the user’s preference would be recorded in a cookie placed on the user’s machine.19 If a user clears their browser’s cache, that preference selection would, presumably, be erased and, as a result, the user’s personal information would again start to be sold by a business. Put differently, by suggesting that website owner’s utilize cookies to store user Do Not Sell requests, the framework appears to be endorsing a non-persistent system for recording consumer preferences. It is unclear whether a non-persistent opt-out mechanism fully complies with the CCPA’s requirement that a business “refrain from selling personal information collected . . . about the consumer” after receiving an initial opt-out request and wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”20
- Offline to online sales. The CCPA arguably requires a company that receives a do not sell request to cease the selling of information that is collected by the business both online and offline. The IAB framework’s focus on the online collection, and transmission, of do not sell requests does not appear to anticipate that many organizations may not collect sufficient information about a consumer to effectuate the request in the offline environment.
- Admission that most website visitors are “consumers.” The CCPA applies to “consumers” a term defined under the Act as including only residents of the state of California. Many website owners have struggled with how to identify whether a website visitor is, in fact, a California resident. While data points that are sometimes collected by website owners (e.g., IP address, shipping information, or billing information) might bear some correlation to residency, such data points are far from conclusive. For example, a resident of Colorado who works for a company that is headquartered in Los Angeles might ship information to a California office address, present with a California billing address, and even have a California IP address (e.g., via a corporate VPN), but would not be a California resident. The Limited Service Provider Agreement requires that website owners represent and warrant that they have “undertaken commercially reasonable efforts to determine that the User [that clicks on a Do Not Sell My Personal Information Link] is a Consumer” for the purposes of the CCPA, or that the website owner “has assumed that all Users on the Digital Property are Consumers.”21 Both representations may be problematic. The former may state or imply that some effort has been undertaken to verify the residency of website visitors when most websites do not collect residency, or take efforts to verify residency. The latter would require that the website confer upon all visitors the rights of Californians. It also raises the specter that the California attorney general might use the contractual representation in an enforcement action to prevent a company from arguing that a particular visitor was not a Californian.
What concerns have been raised with the IAB’s Do Not Sell Framework?
The Interactive Advertising Bureau (“IAB”) is a trade association comprised of companies that participate in digital marketing; its members include both media companies and advertising technology companies.
In October of 2019, the IAB published a draft IAB CCPA Compliance Framework for Publishers & Technology Companies (the “IAB Do Not Sell Framework”).1 The IAB Do Not Sell Framework proposed a system for companies that participate in third party behavioral advertising to provide consumers with an option for expressing their preference that their information not be sold. The proposal was presented ostensibly as a means of complying with the CCPA’s requirement that companies that sell personal information include a “Do Not Sell My Personal Information” link on their website, and honor the preference of consumers that opt out of such sales.2
Numerous questions and concerns have been raised by privacy advocates and businesses with the IAB Do Not Sell Framework. These include, but are not limited to, the following issues:
- Websites would be limited to dealing with adTech companies that participate in the framework. The IAB Do Not Sell Framework attempts to effectuate a do not sell request by converting any adTech company that has joined the framework, and that has executed a “Limited Service Provider Agreement” provided by the IAB, into a “service provider” when they receive a do not sell signal from a participating website. From a website’s perspective, however, if they participate in the IAB Do Not Sell Framework they may be effectively restricting the adTech companies (including the behavioral advertising network providers) with whom they can partner to those that have joined the framework. Websites may incur significant disruption if they are forced to terminate current adTech partners that decide not to join.
- The terms of the Limited Service Provider Agreement are unknown. Advertising technology companies that participate in the framework (e.g., third party behavioral advertising networks) would contractually agree to be bound by a “Limited Service Provider Agreement.” Although the IAB provides a high level description of the provisions that might be included in the Limited Service Provider Agreement, as of November 20, 2019, the agreement itself had not been published.3 As a result, it is not possible to determine whether the agreement comports with the service provider requirements of the CCPA.
- The effectiveness of the Limited Service Provider Agreement is unknown. In order for a company to be considered a “service provider” under the CCPA the Act states that there must be a “written contract” and implies that the contract must be “with the business.”4 Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that the agreement will not be entered into between a website and a technology company directly as “Digital Properties lack privity with many Downstream Framework Participants.”5 It may be that the IAB anticipates that adTech companies will agree to a set of industry rules or terms to which a website will be a third party beneficiary. Assuming that is the case it is unclear whether a court will interpret such a contractual arrangement as a “contract” between the parties sufficient to create a service provider relationship.
- The Limited Service Provider Agreement will contain no indemnification of websites. Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that it will include “no indemnification provisions.”6 It is unclear to what extent websites that may be directly liable under the CCPA will be comfortable with the risk that arises from service providers that are unwilling to provide any indemnification for privacy-related violations.
- The Limited Service Provider Agreement will impose no liability on adTech companies. Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that it will include “a complete limitation of liability.”7 It is unclear to what extent websites that may be directly liable under the CCPA will be comfortable with the risk that arises from service providers that are unwilling to assume any liability for privacy related violations.
- Device level opt-out may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would trigger a device-level opt-out.8 Among other things, the IAB Do Not Sell Framework suggests that websites notify consumers that if they visit the website from a different device (e.g., a work computer instead of a smartphone, or a smartphone instead of a personal computer) their information will again be sold until, or unless, the consumer submits a new opt-out request on the new device. It is unclear whether a device-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and the requirement that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”9
- Browser level opt-out may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would trigger a browser–level opt-out.10 Among other things, the IAB Do Not Sell Framework suggests that websites notify consumers that if they visit the website from a different browser (e.g., Chrome instead of Safari) their information will again be sold until, or unless, the consumer submits another opt-out request on the new device. It is unclear whether a browser-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”11
- Non-persistent opt-outs may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would record their preference in a cookie placed on the user’s machine.12 If a user clears their browser’s cache that preference selection would, presumably, be erased and, as a result, the user’s personal information would again start to be sold by a business. It is unclear whether a non-persistent opt-out mechanism fully complies with the CCPA’s requirement that a business “refrain from selling personal information collected . . . about the consumer” after receiving an initial opt-out request and wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”13
- Offline to online sales. The CCPA arguably requires a company that receives a do not sell request to cease the selling of information both online and offline. The IAB framework’s focus on the online collection, and transmission, of do not sell requests does not appear to anticipate that many organizations may not collect sufficient information about a consumer to effectuate the request in the offline environment.
- Misrepresentation and deception litigation risk. Some privacy advocates have asserted that the IAB framework would, if adopted, “result in significant misrepresentations of the law.”14 It is not precisely clear what misrepresentations they believe would be made through the framework. However, their statements may be a signal that they intend to work with plaintiff attorneys to test whether use of the framework might be the foundation of a deception claim in litigation.
What is ‘pseudonymized’ data?
The terms “pseudonymize” and “pseudonymization” are commonly referred to in the world of data privacy, but their origins and precise meaning are not widely understood among American attorneys. Indeed, most American dictionaries do not recognize either terms as part of the English language.1 While the terms derive from the root word “pseudonym” – which is defined as a “name that someone uses instead of his or her real name” – their meanings are slightly more complex.2
The CCPA was the first United States statute (federal or state) to use either term.3 The CCPA’s definitions for the terms borrow from the European GDPR enacted two years prior to the CCPA. Indeed, the with the exception of minor adjustments to conform the definition to CCPA-specific terminology (e.g., “consumer” instead of “data subject”), the definitions are virtually identical:
Source | GDPR | CCPA | Modification from GDPR to CCPA |
Term | pseudonymisation | Pseudonymize / Pseudonymization | |
Definition | [T]he processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.4 | “[T]he processing of personal information in a manner that renders the personal information no longer attributable to a specific consumer without the use of additional information, provided that the additional information is kept separately and is subject to technical and organizational measures to ensure that the personal information is not attributed to an identified or identifiable consumer.”5 | [T]he processing of personal information data in such a manner that renders the personal information data can no longer be attributedable to a specific data subject consumer without the use of additional information, provided that such the additional information is kept separately and is subject to technical and organiszational measures to ensure that the personal data information are is not attributed to an identified or identifiable natural person consumer. |
Confusion surrounding the term “pseudonymize” largely stems from ambiguity concerning how the term is intended to fit into the larger scheme of the CCPA. Besides defining the term, the CCPA only refers to “pseudonymized” on one occasion. Within the definition of “research,” the CCPA implies that personal information collected by a business should be “pseudonymized and deidentified” or “deidentified and in the aggregate.”6 The conjunctive reference to “research” being both pseudonymized “and” deidentified raises the question about whether the CCPA gives any effect to the term “pseudonymized.” Specifically, the CCPA appears to assign a higher threshold of anonymization to the term “deidentified.” As a result, if data is already to be deidentified it is not clear what additional processing or set of operations is expected by also pseudonymizing the data.
The net result is that while the CCPA borrows the term “pseudonymization” from European data privacy law, and introduces it to the American legal lexicon, it does not appear to apply the term or give it any independent legal effect or status.
What personal information does an employer typically collect about its employees?
- Benefits elections.
- Correspondence to/from the employee and the employer.
- Correspondence to/from the employee and other employees.
- Correspondence to/from the employee and customers or clients of the employer.
- Complaints made about the employee.
- Complaints made by the employee.
- Disciplinary actions and related investigation files..
- Employment eligibility verification information (e.g., I-9, Social Security Number).
- Job application.
- Pay details (e.g., direct deposit information).
- Pay history.
- Performance reviews.
- Personnel files.
- Salary and salary history.
- Time and attendance.
What qualifies as aggregate or de-identified information under the CCPA?
The CCPA defines both “aggregate consumer information” and “deidentified information.” Aggregate consumer information is defined to mean “information that relates to a group or category of consumers, from which individual consumer identities have been removed, that is not linked or reasonably linkable to any consumer or household, including via a device. “Aggregate consumer information’ does not mean one or more individual consumer records that have been deidentified.”1
Deidentified information is defined under the CCPA to mean “information that cannot reasonably identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer, provided that a business that uses deidentified information:
(1) Has implemented technical safeguards that prohibit reidentification of the consumer to whom the information may pertain.
(2) Has implemented business processes that specifically prohibit reidentification of the information.
(3) Has implemented business processes to prevent inadvertent release of deidentified information.
(4) Makes no attempt to reidentify the information.”2
Notably, the definition of “aggregate consumer information” explicitly excludes deidentified information from its scope, even though it is possible that both definitions could apply to the same data set. The functional difference between the two definitions is primarily that the definition of aggregate consumer information applies solely to the data itself, whereas the definition of deidentified information also incorporates and considers the conditions under which such data is held. In any event, the effect is the same: whether aggregated or deidentified, the data is no longer “personal information.”
What type of contractual provisions are included within service provider agreements in connection with consumer deletion requests?
Although the CCPA does not itself require that a service provider honor a deletion request that it receives directly from a consumer, a service provider may be contractually obligated to do so by a business.
Many businesses include a contractual provision in their agreement with a service provider requiring the service provider delete personal information that is processed on the business’s behalf at the direction of the business. A less specific “reasonable assistance” provision is also common, which obligates the service provider to reasonably assist the business in fulfilling a deletion request. Although here a service provider retains an argument that facilitating deletion when not required to do so by the CCPA may not be “reasonable assistance,” the existence of this provision signals that a business may be expecting the service provider to honor its deletion requests.
A business may assert that the contractual provisions which are required to meet the definition of “service provider,” imply that a service provider must honor a business’s deletion requests. However, the CCPA specifically allows a service provider to process personal information outside of its relationship to the service provider if such processing is “otherwise permitted by [the CCPA].” 1 As discussed above, the CCPA permits a service provider to refuse a deletion request for a variety of reasons.2
Beyond CCPA specific provisions, a business may argue that other provisions in the agreement with a service provider require deletion of personal information at a business’s direction. If personal information fits the agreement’s definition of confidential information, the confidentiality provision may require confidential information be deleted or returned at the disclosing party’s direction. A provision where a service provider has agreed to abide by the business’s privacy policy may also create an argument that the service provider must delete personal information, depending on the drafting of the privacy policy. If a data protection agreement containing the GDPR’s required Article 28 processor provisions applies, the definition of “personal data” in those provisions may be broad enough to apply to CCPA personal information and thus require deletion.