While there may still be the occasional team that handles everything themselves, most software products are made up of a variety of services from different vendors. From data storage to customer management, third party data processors are a nearly unavoidable part of any organization.
If your company has customers in the EU or processes the data of individuals in the EU, you need to have GDPR compliance in mind. The data processing agreement (DPA) is how data controllers and data processors ensure that all parties are meeting the data privacy expectations that the European Commission has established. For example, a services company (the controller) may use an HR and payroll management company (the processor) to handle part of their business. In addition to their service agreements and contracts, they would also need a DPA to protect the privacy of their employees and applicants.
What is a data processing agreement?
Data processing agreements are a type of legal contract that covers the rights of everyone involved, as well as the expectations on how they will handle data. GDPR requires one for each data processor, but a DPA also shows businesses that the processor is capable and understands the legal requirements for handling your data.
Whether you are the processor, controller, or sub-processor, you will have a DPA with whichever party you interact with.
The main elements of a data processing agreement
The agreements can differ from company to company, but the GDPR does describe eight areas that must be included.
- Processors can only process data when instructed to by the controller.
- Anyone with access to the data must be required to keep the information confidential.
- Appropriate security measures must be taken to protect the data. Details can be found in Article 32.
- The controller must approve any sub-processors before they are used. The DPA may also include a list of all sub-processors.
- Processors must assist the controller in fulfilling any data requests made by the individuals whose data is being processed.
- Processors will help controllers maintain security and compliance, particularly for any high-risk processing.
- Controllers can request data be deleted or returned, unless a country’s laws require the data to be stored longer.
- Processors will provide controllers with any information necessary to demonstrate compliance.
How all of this often manifests is in a series of clauses that describe who controls what, exactly what kind of processing will be done, and explicit statements of the rights of each group. If we look at the DPAs from SaaS companies, we also see portions that detail how data transfers are handled, any standard contractual clauses (SCCs), lists of sub-processors, the duration of processing or data storage, and the data categories that the personal data belongs to.
Due to the constantly expanding world of global privacy regulation, you’ll also see sections dedicated to individual laws. The CCPA’s data processing addendum is a common occurrence in DPAs for any processors serving customers in the California.
What risks do SaaS companies face for not having a data processing agreement?
If you are subject to GDPR, not having a DPA in place is an easy way to be fined. Beyond that, the largest risk is liability. Failing to obtain a DPA as a controller could make you liable for any mishandling of personal data by your processors.
As a software company, you often sit on both sides—a controller for some data, and a processor for other data. Let’s look at an example: A helpdesk/chat service sells a plug-in that businesses can embed right in their application or website. The plug-in tracks interactions, collects some personal data about the user interacting with it, and allows the businesses to link that customer data to their own internal data. In this case, the chat service will need to provide a DPA to each business. In this case, the chat app is the processor and the businesses are the controllers. If the chat app uses a third party service, for data storage or analytics, they will need their own DPAs from those services as well. Now they have sub-processors for any data that the businesses are providing.
If you are selling a software product to businesses (such as B2B SaaS), a DPA is essentially a requirement for any serious company to do business with you. You’ll need your own, and agreements from every sub-processor—more on that shortly. If you don’t have a DPA prepared, your prospective clients will request one. If they don’t, you should be concerned with their capabilities and their commitment to protecting the data of their customers.
Do you need DPAs for every service?
The short answer is yes. The GDPR requires it, and technically requires a DPA for every sub-processor as well. In practice, this looks less daunting. Many processors provide publicly accessible DPAs for all customers, making acceptance of the terms of the DPA part of the sign-up process.
When it comes to sub-processors, the DPA of a processor will normally cover that. You won’t need individual DPAs from all sub-processors, but your contract with the vendor processing your data will assure you that they have contracts in place with all the sub-processors. They are also obligated, by your DPA, to only add new sub-processors with your approval.
What does a standard DPA look like?
While we covered the topics that a data processing agreement normally contain, it can be useful to see how different companies set up their own DPAs. Here are a few examples from companies that span developer tools, marketing, social, and communication:
Other companies often offer their DPA by request, and many can provide a signed copy as well. If you aren’t finding a DPA from any of your service providers, reach out to their data privacy team or your sales contact.
Can DevSecOps help catalog DPAs?
Solid DevSecOps practices can absolutely solve this problem. Requiring DPAs should be part of your security and data management policies. The best way to enforce policies is by incorporating them in the SDLC (software development lifecycle). Component inventory and data flow mapping solutions often have a way to directly attach documentation and legal forms to specific components and services. This way, you always have an accurate view of which components have up-to-date DPAs, and which don’t. From there, the inventory can aid your teams in building out any necessary regulatory requirements, like assembling a ROPA, thanks to all the information existing in a single place.
