If you are representing a Software-as-a-Service (SaaS) company that is handling Personally Identifiable Information (PII), you’ll likely be required by your Enterprise customers to sign a Data Processing Agreement in addition to your standard Terms of Service/Sales Agreement.
In case you’re not familiar, a Data Processing Agreement (DPA), sometimes called a Data Processing Addendum, is a legally binding document entered into between you (the Processor of data and the Provider of Services) and your customer (the Controller of data and the Customer) that regulates the specifics around data processing – like scope, purpose, and the relationship between your companies.
DPA’s used to be required only if you’re doing business with Customers who host data subject to the European Union General Data Protection Regulation (GDPR), but more recently, have become a standard if you’re handling any PII due to the continuing onslaught of data privacy regulations worldwide. DPA’s are not just for your customers, either. You should enter into DPA’s with your vendors to also ensure that they are appropriately protecting and processing any PII that you may be handling.
This post will give you a high-level overview of a Data Processing Agreement – specifically from the view of you being the Provider/Processor of PII.
Your DPA should lay out specifics around what you define as PII, and what data privacy regulations you are referring to (such as the CCPA, GDPR, etc.). Further, this section should also lay out what you consider a security breach, and any other undefined terms throughout the agreement. A key element here is to define PII only as the data you will be processing in delivering services, and nothing further.
Personal Information Types and Processing Purposes
Explicitly lay out what type of PII you will be processing, and what the legal basis/purpose of your processing is. This can refer out to an Appendix to the agreement if necessary, so you can go into more detail. The key here is to leave out any overreaching and overarching terms, and specifically define what type of information you will be processing and nothing more.
Assuming you are the Provider/Processor in this particular agreement, specifically lay out what your obligations are – including what you are using the data for, what you are to do if there is a deletion request, what to do in case there is a breach, and any additional requirements.
Provider’s Employees and Independent Contractors
Specifically mention that the responsibilities laid out in the DPA forward to your employees and independent contractors – meaning anyone working for you in providing services to your Customer is responsible for this DPA as well.
This section calls out the security requirements you must have in place – including technical, administrative, and physical security safeguards. Enterprise customers may also request or require that you have a third-party security certification or report, such as SOC 2 Type II, or ISO 27001.
Security Breaches and Personal Information Loss
This section lays out your requirements of notifying of any security breaches, and the remediation steps that must be taken in notification – including requirements of gaining access to relevant data.
Many countries require additional safeguards in place for transfers of PII out of their borders. This section should lay out what those additional safeguards are, including references to additional documents such as the EU Standard Contractual Clauses (required by companies that handle EU data). As of July 2020, Standard Contractual Clauses (SCC’s) are generally required to be attached to DPA’s to offer additional required safeguards. A new version of the SCC’s were released June of 2021. The EU and US are actively working on releasing a new “Privacy Shield” framework, which will set out specific information security and data privacy requirements of the parties involved – and can replace the need for entering into SCC’s.
Subcontractors and Vendors
An important section where your Customer will require that you may only authorize a third party subcontractor or vendor to process PII if they’ve essentially entered into DPA’s as well. This means that if you have a subcontractor or vendor that handles the PII of your customers, you should be entering into DPA’s at least as restrictive as the one you’re signing with your customers. Data privacy and information security involves a chain of liability – which means that if one of your vendors has a data breach, and that data breach affects the data of your customers, you may face lawsuits and liability.
Data Subject Rights
Many data privacy laws have laid out strict rights that data subjects have, and how you should respond in case there is a request. This section lays out those requirements, and what is expected of you if a data subject request comes through. This may include requirements of notifying your Customer, and a strict and specific policy to follow in delivering data subjects what they are asking for.
Certain regulated industries have additional requirements for data privacy. Healthcare, financial technology, insurance technology, and government/defense related technology may require additional safeguards. This section will call those out specifically.
Term and Termination
How long does this agreement last? It should generally expire when the underlying agreement expires, and according to any applicable data privacy regulation.
Data Return and Destruction
Carve out how a Customer can request that you return or destroy the Customer’s data after the completion of the term of the agreement, or upon request and in accordance with applicable data privacy laws.
In accordance with applicable data privacy laws and regulations, Providers should keep detailed and up-to-date records of the processing of PII.
Controllers like to reserve the right to audit Processors to ensure that they are indeed following the requirements of the DPA, and this section lays out those specifics. The key here is to limit how often and how invasive an audit can be, and ensure that Customers cover the cost of these audits.
The appendices to the DPA generally include information around Processing Information, Processing Purpose, and Details, as well as the text of the Standard Contractual Clauses.
* * *
This post is just a high-level overview of what should be in a Data Processing Agreement. These agreements are negotiated and signed with almost every enterprise deal, and you should have proper guidance around navigating these and what they mean. There are many more nuances and specifics around this type of arrangement, and you should have an experienced attorney help you through drafting the right one to make sure you and your customers are protected. Kader Law can help you draft, edit, or negotiate your Data Processing Agreement. If you’re interested, feel free to contact us.
This post is not legal advice, and does not establish any attorney client privilege between Law Office of K.S. Kader, PLLC and you, the reader.
Shahed Kader, Esq is Founder and Managing Attorney of Law Office of K.S. Kader, PLLC. His practice is focused on helping Software as a Service and Information Technology companies with their legal needs. He is licensed to practice law in the District of Columbia (Washington, D.C) and the State of Maryland. Shahed took a different route to law. Before launching the practice, he worked in sales and growth for software companies for 10 years while attending law school at night – giving him an exceptional understanding of software business transactions and needs. Shahed regularly shares his insights on the Kader Law blog, and covers subjects ranging from SaaS Agreements, to Privacy Policies, to Fundraising.