8 Things for Customers to Look for in a DPA (Data Protection Addendum or Agreement)

DPAs (Data Protection Agreements or Exhibits (Addenda)) are common in commercial arrangements involving access to the personal data of end users. When you are the customer in such a transaction and your end users’ data will be accessed by a vendor, it is important that you fully understand the scope of the protections being afforded this data under the DPA, especially when the DPA is drafted by the vendor.

When reviewing a DPA as a customer, we suggest looking for 8 specific provisions that can help to protect your end users’ data:

1. Scope (Jurisdiction). Some vendors may attempt to limit the scope of a DPA’s protections by restricting its applicability to only European user data subjects under the General Data Protection Regulation (GDPR). However, it is better to have all user data protected to the same level; therefore, customers should seek to have the DPA apply to any and all personal information, regardless of the country of origin or processing. For example, as more U.S. states pass their own privacy legislation (e.g., CCPA in California), the broader scope will be beneficial. Although the precise legal requirements may vary by jurisdiction, you want to strive for a “best of breed” DPA which covers all jurisdictions comprehensively enough to meet the legal requirements in each applicable location.
   
   


2. Direction of Obligations. The purpose of a DPA, broadly speaking, is to ensure that the vendor processing data on your behalf will properly protect that data. In this respect, the DPA is generally a one-way document with obligations primarily being imposed on the vendor. Of course, there may be exceptions to this, such as when a customer is required to certify that it has secured the requisite consents to data sharing.
   
   However, some vendors try to make DPAs mutual, or worse, flip the obligations so that they primarily come from the customer to the vendor. For example, a DPA might obligate a customer to send only data which is necessary to perform services, as opposed to restricting the vendor to only collecting and processing the necessary data. The core focus of any DPA should be to place obligations on the vendor relating to data protection efforts, privacy, and compliance with applicable laws. If you see a one sided DPA going in the wrong direction, this is a “red flag” that this is not a template you should be working from as the basis for edits.
   
   


3. Processing. The DPA will govern what the vendor does when “processing” personal data. Definitions can be important. “Process” or “Processing” should be defined broadly, as it is under applicable law, to include, without limitation, collection, storage, retention, processing, disclosure, transmittal, and/or use of data, and as it is otherwise defined or understood under industry standards or applicable laws.
   
   


4. Security Incidents. Another crucial provision is how broadly you define a “Security Incident” (or any similar term used in the DPA), requiring notice, remediation and penalties. Customers should seek to include in the definition (i) not just data breaches, but also, other mishandlings or failures by the vendor to use the required levels of care (because a customer should receive notice and mitigation for any incident involving a vendor’s missteps, even if such failure doesn’t actually result in a data breach); and (ii) not only “actual” or “confirmed” incidents, but also, any “suspected” ones (because, as a customer, you want mitigation and remediation to begin immediately when there is a suspected Incident, as opposed to waiting (possibly weeks) for the vendor to complete its due diligence into whether a breach actually occurred).
   
   


5. Notice. The vendor should be obligated to give the customer immediate notice (i.e., within 48 hours) of any actual or alleged security incident.
   
   


6. Remediation. The vendor should be expected to use its best efforts (and at least in accordance with industry standards) to remedy each security incident by working in collaboration with the customer and to take appropriate steps to ensure that the incident does not repeat.
   
   


7. Indemnity. Customers should request an indemnity from the vendor for any damages, costs or expenses arising from a security incident, including such industry standard costs as credit monitoring.
   
   


8. No Liability Caps. The vendor’s liability should be uncapped for the aforementioned indemnity.

A customer’s ability to negotiate for the inclusion of these added protections will of course depend on the relative bargaining power of the vendor. That said, since the primary purpose of a DPA is to protect the personal data of the customer’s end users, it is worth going the extra mile to ensure those protections are meaningful. Your end users will thank you. If you would like assistance with a DPA, Outside GC can help. Please reach out to Brian Heller at (202) 365-3940 or [email protected].

Brian Heller is a Member of Outside GC’s Washington D.C.-based team, and is an experienced technology and deal attorney, specializing in SaaS licensing, digital and social media, online advertising, mobile apps, cloud services, terms of use, data use and protection, content licensing and other technology deals. Brian has represented both vendors and customers and uses this experience to present reasonable positions on behalf of his clients. Brian can be reached at [email protected].