Part 1 of How to Approach DPAs in view of Final CCPA Regs: A Series

This is the first in our series of blog posts on top considerations for approaching data processing terms required under the state privacy laws that have, or will, come into effect this year, namely the California Consumer Privacy Act, as amended by the California Privacy Rights Act (“CPRA”) (collectively the “CCPA”), the Colorado Privacy Act (“CPA”), the Virginia Consumer Data Protection Act (“VCDPA”), the Utah Consumer Privacy Act (“UCPA”), and Connecticut’s Act Concerning Personal Data Privacy and Online Monitoring (“CTPA”), which we collectively refer to throughout as “U.S. Privacy Laws.” This post will focus on the statutory and regulatory requirements on provisions that must be in contracts with data recipients (notably, we use “recipient” for ease of reference, although recipients may, in fact, collect directly from a consumer). For a handy list and chart summarizing the required provisions, you can jump to the end of this article. We will publish additional blog posts as part of this series, including with a focus on customer-specific considerations for DPAs, as well as one on vendor-specific considerations.

Note: Where we use a defined term from one of the U.S. Privacy Laws, we will put it in quotation marks in the first instance it is used. We use “personal information” and “PI” to refer to both “personal information” and “personal data” interchangeably. As indicated above, reference to the CCPA is as amended by the CPRA unless stated otherwise. Certainly, the required contractual provisions do not necessarily need to be included in data processing addenda or agreements (“DPAs”) that are separate from a master services or other agreement, but we have drafted this post under the assumption that many companies will approach contracting requirements in that manner, and in many instances companies will have to incorporate these requirements into their DPA templates that already address existing privacy and related requirements, such as under the CCPA (pre-CPRA amendments) and global privacy laws such as the EU and UK GDPR (referred to collectively here as GDPR).

Entering into appropriate data processing terms is one of the most challenging aspects of a privacy compliance program. A number of factors affect a company’s ability to enter into compliant DPAs, including the sheer number of existing processor agreements that pre-date the requirements of new U.S. Privacy Laws, bargaining power as between the parties, timing (e.g., contract renewals and regulatory deadlines), and which states’ laws apply, among others. In addition, different companies and their counsel have different interpretations of, levels of sophistication with regard to, and understanding of, the U.S. Privacy Laws generally, the prescriptive requirements that exist across them, and the parties’ roles in processing data.

Despite having at least draft CCPA Regulations (also referred to as “Regs”) for the CPRA’s updates for about nine months now, some vendors have been reluctant over the last year or so to update their MSAs or DPAs to include certain required provisions. Both vendors and customers have correspondingly been reluctant to commit the substantial resources required to amend or enter into DPAs with to-be-required language in view of the regulatory uncertainty and prospect of it changing as the regulations change. Now that we have some regulatory certainty, given that the California Privacy Protection Agency (“CPPA”) has submitted final Regs to the Office of Administrative Law for administrative approval, this will likely – or rather, it should – spur companies into action to address the contracting requirements under the CCPA and other state privacy laws by July 1, when the CPRA’s amendments become enforceable and the Colorado and Connecticut laws become effective and enforceable. As many are aware, contracting requirements are among many others on the compliance checklist to be completed by July 1.

While there are a number of issues and considerations to address with respect to DPAs, one of the foundational issues is meeting the prescriptive contracting requirements, which is particularly important under the CCPA. This is because failure to have a compliant contract in place results in the data transfer being deemed a “sale” and/or “sharing.” Yet, at least in our experience, this is an area where both vendors and customers struggle to agree. Below, we provide some practical guidance on this topic, starting with understanding the roles of the parties involved and key provisions that are required to be in DPAs.

High Level Takeaways

• The CCPA’s terms are arguably the most important. Tracking the CCPA’s required provisions closely, and making sure they are in your contracts, is of utmost importance because they are required to avoid the consequence of sale and/or sharing. This continues to be an area of focus of enforcement by the Office of the Attorney General of California (“OAG”), as indicated in enforcement summaries issued by the OAG, and will almost certainly be one of the CPPA, which will share enforcement responsibility of the CCPA with the OAG.

• C2C terms are only required under CCPA. So-called controller-to-controller terms, or C2C terms, are only required in California (in certain situations). “Businesses” must have contracts in place with certain “third party” recipients where sale or sharing is implicated, but “controllers” under the other U.S. Privacy Laws do not have a corresponding or similar requirement.

• GDPR-like schedules will become commonplace. The non-CA states require the types of personal information processed by a “processor” to be disclosed, which effectively necessitates a GDPR-style schedule in your DPA templates that sets forth various details of processing. Similarly, CA’s requirement of specifying business purposes for processing more specifically than referring to the services or the underlying agreement also makes boilerplate DPAs technically deficient.

• Going beyond the bare minimum requirements will assist with broader compliance. Given the complexity of operationalizing consumer requests, the need for considering how vendors and data recipients’ processing is implicated, and requirements under U.S. Privacy Laws, contracts between vendors and their customers necessitate addressing specifics on how the parties will address these issues.

• An interim approach? Assuming existing DPAs provide that the processor must process the business’ PI pursuant to its instructions, as provided from time-to-time (which is a typical provision found in many DPAs), a short-term solution to shoring up existing DPAs may be to provide written directions that confirm the new obligations and restrictions. While this remains untested, for some businesses it may be the only practical path to addressing multitudes of existing agreements.

Service Providers/Processors, Contractors, and Third Parties

To implement data processing terms required by U.S. Privacy Laws into DPAs, it is important to first understand the roles of the parties involved. The U.S. Privacy Laws require certain language to be included in DPAs depending on the parties involved, data use, and data sharing.

While the determination of a party’s role under the U.S. Privacy Laws can be nuanced at times (which we do not discuss in detail in this blog post), a quintessential service provider/processor relationship is a traditional vendor relationship where the vendor processes PI on behalf of a customer (the business/controller). There are not many factual situations that align with the “contractor” designation under CCPA, though there are limited situations (such as auditors) where the business simply “makes available” PI to the counterparty that may be appropriate. The third party designation under CCPA is appropriate where the recipient cannot qualify as a service provider, such as where it processes for purposes that disqualify it as such (for example, using its customer’s PI to provide services to another customer), where the services are processing of PI for cross-contextual behavioral advertising, or where a sale is clearly implicated (e.g., selling a list of email addresses to a recipient for the recipient’s purposes for cash). The requirements to enter into contracts under the CCPA are even further nuanced; by way of example, though a data recipient may qualify as a third party, a contract is not required if a business makes available data to the third party under an available exception that would avoid a sale/sharing from occurring (such as an “intentional interaction”). (Contracts with non-processor recipients are not required under the non-CA laws.) You should certainly consider all of these nuances in your vendor and third-party management program to classify data recipients appropriately. 

The CCPA has three categories of recipients of personal information — (1) service providers, (2) contractors, and (3) third parties. The CCPA requires particular contract terms to be in place with each type of recipient, and the language that is required differs across the three, which we touch on below. Also very notable is that the CCPA prohibits third parties from receiving PI from a business without the proper contractual provisions in place with the business. As a result, the CCPA imposes direct contracting obligations on third party recipients as well.

Virginia, Colorado, Utah, and Connecticut require both “controllers” and “processors” to enter into contract terms that govern the processing of PI. These laws all generally follow the same blueprint in terms of their required contractual provisions, although there are some variations between the states regarding the specific language or provisions that must be included in these contracts. The non-CA laws do include the concept of a “third party” but, unlike the CCPA, they do not require controllers to impose contractual requirements on recipients of data that qualify as third parties, nor do they require third parties to have certain terms in place with controllers to receive PI. The failure of the required contract in the non-CA states is a statutory violation, but it does not convert the transfer into a “sale” as does the CCPA.

What data processing terms should be included in contracts between businesses/controllers and service providers/processors?

For the remainder of this blog post, we will focus on the provisions that are required to be in place between a business/controller and its service providers/processors under the U.S. Privacy Laws. You will note (as you likely have already) that there is overlap between a number of the provisions required in the CCPA and in the other U.S. Privacy Laws, as well as under the GDPR. As a result, in many instances, having a DPA which amalgamates the states’ requirements (and where applicable, the GDPR and other jurisdictions) is likely a sound approach. That said, such an approach may not be appropriate or desirable for certain parties that, for example, have the technical ability to apply differential requirements to California PI vs. PI of consumers from other states or jurisdictions, or that are not subject to the laws of certain jurisdictions. Details on third party transfers and agreements will be addressed in a future blog post. However, at the end of this blog post we provide a handy chart that compares the requirements across the various U.S. Privacy Laws and the GDPR, and includes the CCPA’s requirements for contracts with third parties.

Below is a summary of provisions that are required under the CCPA to be in contracts with service providers (in some instances, we have paraphrased for sake of efficiency):

• Identifying the specific business purposes (and not by mere reference to the services or underlying agreement) and specifying that such purposes are the only purposes for which the business is disclosing the PI to the service provider;

• Setting forth prescriptive prohibitions on the service provider’s data processing (e.g., cannot sell/share; cannot retain, use, or disclose except for certain, limited purposes; cannot use outside of direct relationship with the business; cannot combine with other PI it has)

• Requiring the service provider to comply with the CCPA and to provide the same level of privacy protection required by CCPA businesses (examples provided in the Regs include assisting with compliance with consumer requests and implementing reasonable security);

• Requiring the service provider to enable the business to comply with consumer requests made pursuant to the CCPA or requiring the service provider to comply with a request upon a business informing it of one;

• Requiring notice by the service provider if the service provider can no longer meet its legal obligations;

• Granting the business the right to stop & remediate unauthorized use of PI;

• Granting the business the right to take reasonable and appropriate steps to ensure that the service provider uses the PI consistent with the business’ obligations under the CCPA (e.g., through annual audits);

• Requiring the service provider to enter into written contract with subcontractors to comply with the CCPA (i.e., effectively mirroring these obligations); and

• If the business makes available deidentified data to the service provider, incorporating the specific requirements from the CCPA that apply to deidentified data (not having this provision will not prevent the service provider designation from being in place).

The CCPA requires the same for contracts with contractors, with the addition of a certification made by the contractor that it understands the restrictions set forth in the contract and will comply with them.

The following is a summary of what the non-CA U.S. Privacy Laws (the CPA, VCDPA, UCPA, and CTPA) require contracts between controllers and processors to include:

• Instructions for processing, including the nature & purpose of processing (specific to the transaction and services);

• Types of PI being processed (specific to the transaction and services);

• Duration of processing (specific to the transaction and services);

• Rights and obligations of the parties;

• Provisions requiring the processor to:

• Enter into a written contract with its subcontractors;

• Provide the controller an opportunity to object to subcontractor engagement (arguably implied contractual requirement under certain of the non-CA U.S. Privacy Laws);

• Require all persons processing PI to be subject to duty of confidentiality;

• Delete/return PI (required by all non-CA U.S. Privacy Laws except UCPA);

• Allow, and cooperate with/contributes to, reasonable assessments/audits (required by all non-CA U.S. Privacy Laws except UCPA); and

• Make info available to demonstrate compliance (only for certain of the non-CA U.S. Privacy Laws).

A table summarizing and comparing the required data processing terms is provided in Appendix A.

Though not required, it may be desirable in many instances to include provisions that address processors’ statutory obligations and other issues and risks, such as:

• Details regarding how the parties will operationalize the passing through of deletion and other requests or how the service provider/processor will assist with access requests;

• Limitations on processing of sensitive PI (e.g., so as to avoid the CCPA’s right to limit from being invoked);

• Specifics and/or limitations with respect to audits;

• Specific information regarding protecting PI and security obligations;

• Restrictions and obligations with respect to the use of tracking technologies by the recipient, or access to the business’/controller’s IT systems;

• Provisions requiring data breach notification and assistance with investigation, remediation, etc., by the recipient;

• Shifting of liability for losses related to data processing (e.g., indemnity), and reimbursement of costs and expenses arising out of a data breach; and

• Intellectual property and other non-data privacy related considerations on use of data.

Conclusion

Implementing appropriate data processing terms is a vital aspect of complying with U.S. Privacy Laws. Coming into compliance requires a number of considerations including identifying the roles of the parties involved and whether the roles require a contract to be in place. Most importantly, it requires assessing which terms are required and keeping in mind that the bargaining power between the parties may weigh on where they land in terms of the specifics of data processing terms, such as the parameters of required audits, assistance with consumer rights, and so on. Now that there is some regulatory certainty in California, companies should, if they have not already, prioritize addressing data processing contracting requirements under the U.S. Privacy Laws.