2023 Data Security Incident Response Report Get the Full Report

Transactional Data Privacy and Security Update

Share this chapter

Drowning in Data Processing Addendums

Privacy and commercial transactions attorneys have spent the last year inundated with addendums. It has become common for businesses to address privacy requirements by slapping a data processing (or “privacy” or “security”) addendum on an otherwise form contract. The practice is especially evident in digital services where third parties are collecting, hosting, or otherwise processing data on behalf of a business. The continued concern for data breaches combined with the evolving coverage of state and federal privacy laws have turned the trickle of DPAs from the past few years into a tsunami.

On the one hand, few would argue that the increased attention on breaches, privacy, and data security in contracts is a bad thing overall; on the other hand, however, the lack of uniformity, potential conflict with other contract terms, inconsistencies in the laws, incorporation by reference, and year-over-year updating have caused confusion and headaches for transactional privacy lawyers and their corporate counterparts. Of course, some businesses still include applicable and necessary privacy and security terms in their master agreement rather than in a DPA, but the speed at which privacy law and security technology are evolving has established the data privacy/security addendum as the preferred method for negotiating privacy and security terms in contracts.

DPAs are often considered through the lens of privacy statutes and regulations, but these documents also often deal with important topics like data security measures and rights and obligations in the event of a data security incident. When a data security incident occurs, a business not only needs to determine what data and third parties may be involved, but also the applicable notification terms in the contracts (including DPAs) with any potentially involved third parties. The incident notification terms in the DPA may differ from those under applicable laws.

For international businesses and businesses with a presence in the EU, variations of DPAs have been fairly common since GDPR came into effect. For U.S.-centric businesses, the practice didn’t become widespread outside of a few specific industries (e.g., HIPAA requirements for healthcare entities and state and federal requirements for certain financial services) until CCPA became law. CCPA (as amended by CPRA) made proper privacy and security contract terms imperative for businesses sharing personal information with vendors. Without the proper privacy contract language in place, sharing data with a vendor could be considered a “sale” of personal information, giving rise to a number of additional obligations under CCPA. Companies that do not otherwise sell personal information are incentivized to ensure the proper contractual language is in place with all vendors to avoid inadvertently doing so. Under CPRA, even when a company is selling personal information, the contract must include specific privacy and security terms. In light of this, you would be hard-pressed these days to find a contract between sophisticated parties for services involving personal or sensitive information without some additional data privacy or security terms.

The matter is further complicated, though, because the contractual requirements under data privacy laws have evolved over the last couple of years. While the basic requirements for contracting between controllers and processors under GDPR haven’t materially changed since the law went into effect, the transfer mechanisms have changed, and that has had a significant impact on DPAs for companies subject to GDPR. Similarly, in the U.S., the service provider contracting requirements required under CCPA were modified by CPRA and the draft implementing regulations that go into effect this year. Additionally, other comprehensive state privacy laws (e.g., Virginia, Colorado, etc.) have requirements (and definitions) that are significantly different from California’s. These statutory requirements are all fairly specific regarding the language that should be used in these contracts. For example, recent updates in CPRA require specific auditing rights, review, and monitoring of the DPAs and privacy compliance. Thus, businesses that signed a CCPA-compliant DPA prior to CPRA may need to update those terms. It also means these addendums require continuous monitoring and testing – these are no longer sign-and-forget contracts.

DPA review and approval can be a challenging process for privacy and transactional attorneys because DPAs come in different shapes and sizes. Some DPAs only contain the required privacy language – others also include substantial security terms and commercial terms. There is no one-size-fits-all DPA, and companies need to establish a process for evaluating DPAs and a benchmark for when DPAs are acceptable and when they should be negotiated.

DPA Review and Negotiation Checklist

Determine the roles of the parties

Which party is the business/controller and which party is the service provider/processor? Is the business/controller selling personal data or sharing it for a business purpose?

Determine which party’s DPA will apply

Determine the applicable laws

EU/UK, U.S., both, other?

Determine the scope of the DPA

Privacy, security, both? Identify and note any applicable incident notification terms.

Does the DPA only cover required privacy terms

or does it also include negotiatble terms like indemnification?

Confirm that the DPA covers all requirements for applicable laws

For a California DPA, this would include, among other things, the requirements in Section 7051 or 7052 of the regulations.

Review the order of precedence

for commercial and legal terms also covered in the main agreement.

Review for material changes

to terms also covered in the main agreement.