Data processing agreements (DPAs) are legal contracts that outline the terms and conditions between a data controller and a data processor about the processing of personal data. What personal data or personally identifiable data is is a very broad category. One of which most startup companies are involved in in one way or another. The fact that email addresses fall into this category means that almost all SaaS companies will trigger a DPA when a customer merely signs up. This agreement is critical in ensuring that data processors who process personal data on behalf of a controller do so in compliance with any applicable data protection regulations and guidelines.
The General Data Protection Regulation (GDPR) introduced way back in 2018 was said, at the time, to be something that was going to throw the anchors on the wild west that was technology companies. It mandates that data controllers and data processors must have a DPA in place. This agreement is legally binding and outlines the obligations, responsibilities, and expectations of both parties. DPAs are important because they help to establish trust between the data controller and processor, protect the rights of data subjects, and promote accountability, cutting down on the sharky tactics that a lot of tech companies were leaning into before its implementation.
What is a data controller and a data processor?
A data controller is an organization or individual that collects, uses, and manages personal data – this is generally the startup company that is selling their software. They are responsible for ensuring that personal data is processed by the law and that data subjects’ rights are respected. On the other hand, a data processor (usually your customer) is an organization or individual that processes personal data on behalf of the controller. They are responsible for ensuring that they process personal data according to the controller’s instructions and do not use it for any other purpose.
DPAs contain several provisions that aim to protect personal data and ensure that it is processed lawfully. The agreement will typically specify the purpose and duration of the processing, the types of personal data that will be processed, the categories of data subjects, and the measures that will be put in place to ensure data security as well as what happens to the data when a customer churns.
One essential provision in a DPA is the data processor’s obligation to implement appropriate technical and organizational measures to ensure the security of personal data. This is a wide purpose, but it’s one of the core things that protects people’s data. This can include encryption, access controls, and regular security testing. The data processor must also notify the data controller promptly if there is a personal data breach, and there are usually standards set out for how and when this notification must happen.
Another critical provision is the data processor’s obligation to process personal data only by the data controller’s instructions. The processor cannot process personal data for any other purpose, except where required by law. This prevents companies from passing data on to third parties. The data processor must also ensure that anyone who processes personal data on their behalf is subject to the same obligations as they are.
DPAs must also contain provisions relating to the transfer of personal data. If the data processor intends to transfer personal data to a country outside the European Union, it must ensure that appropriate safeguards are in place to protect personal data. This may include entering into standard contractual clauses or relying on an adequacy decision. A lot of enterprise companies have their requirements of where data has to be stored, a classic example of this is payroll data needs to be stored in the country that the payroll is for so that the local tax authorities don’t lose control of it.
A data processing agreement is a legal contract between a data controller and a data processor (software seller and buyer, or user) that outlines the obligations, responsibilities, and expectations of both parties. It is essential to ensure that personal data, in all its varieties, is processed by data protection regulations and guidelines, and that data subjects’ rights are respected. DPAs promote accountability, trust, and transparency between data controllers and processors, and although not only for customers in the European Union, they are a critical component of compliance with the GDPR.
When do I need a DPA in my customer contracts?
As you’re scaling up as a startup company you’ll probably only look to have a DPA put into place when a customer asks for it. The more you scale and the more you realize that replicating this process every time a customer asks for a DPA (which is getting more and more frequent) you may look at building out a security and data package that is pre-made and built to meet the needs of even the pickiest customers. By getting this in place you can get ahead of the game.
Before you get to that point it’s good to understand if your product will require a DPA with your customers and how often your customer base will likely be asking for one to come along with your master service agreement. So, here are seven times that you may (and probably will be) asked for a DPA during your contracting process.
-
When the software seller processes personal data on behalf of the customer
If your startup processes personal data on behalf of their customer, they may need to have a DPA in place. And, let’s be honest, what startup doesn’t process personal data? A lot of companies will argue what is defined as personal data and have predefined buckets or tiers for these. But one of those tiers will include the humble old email, a requirement to process for almost any product out there at the moment. The General Data Protection Regulation (GDPR) mandates that data controllers and data processors must have a DPA in place. The software seller (you) becomes a data processor in this scenario and must ensure that they process the personal data according to the customer’s instructions and comply with all data protection regulations.
-
When the software seller (again, you) processes all that beautiful data in the cloud
Cloud-based software services (pretty much every SaaS product) involve storing personal data on remote servers, making it accessible from anywhere with an internet connection. In this scenario, the software seller is processing personal data on behalf of their customer, and a DPA is necessary. The DPA should specify the measures that the software seller will put in place to ensure the security of the personal data stored on their servers.
-
When the software seller provides software that collects “personal” data
If the software seller provides software that collects personal data, such as a customer relationship management (CRM) system, they need to have a DPA in place. The more personal the more the DPA needs to be squeaky clean. The DPA should specify how the personal data will be collected, processed, and stored, and the measures that will be put in place to ensure its security. Think of companies that process data like driver’s licenses, social security numbers, or credit cards – DPA’s everywhere.
-
When the software seller provides software that integrates with other systems that collect personal data
If the software seller provides software that integrates with other systems that collect personal data, you guessed it, DPA. If your product uses an API to integrate with an e-commerce platform or a payment gateway, it needs to have a DPA in place. The DPA should specify how the personal data will be transferred between the different systems, how it will be processed and stored, and the measures that will be put in place to ensure its security.
-
When the software seller provides software that processes sensitive personal data
If the software seller provides software that processes sensitive personal data, such as health information or financial information, they need to have a DPA in place. The rise of FinTech is a great example of where DPA’s are very seriously worked on. The DPA should specify the measures that will be put in place to ensure the security of the personal data, and how it will be processed and stored.
-
When the software seller provides software that is subject to specific data protection regulations
If the software seller provides software that is subject to specific data protection regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) or the Payment Card Industry Data Security Standard (PCI DSS), they need to have a DPA in place. The DPA should specify how the personal data will be processed and stored, and the measures that will be put in place to ensure compliance with the specific data protection regulations.
-
When the software seller provides software that is used by customers in the European Union
This can be a tricky one. Sometimes your customer or buyer may be in the USA but the end user in their company might be all the way over in the EU. If the software seller provides software that is used by any users in the European Union, that’s right, they need to have a DPA in place. The GDPR states that data controllers and data processors must have a DPA in place, and failure to comply can result in severe penalties, ouch. So buckle up if you’re expanding into the EU.
DPA’s have become a staple part of the legal documentation that you swap with customers when you’re selling software these days. You should build tracking of who has a DPA and who doesn’t into your contract management policy. There are very few circumstances where you’ll be able to build an enterprise piece of software without having to have a DPA in place for a majority of your customers. To get on top of this you should work with your sales team, engineering team, and legal team to have all of the parties involved understand the way your product collects and processes personal data on behalf of the customer, as well as how it integrates with other systems that collect personal data. DPA’s will be something that you need to get right to scale, so don’t just blow them off as something that can be done on a customer-by-customer basis. Build for scale, just like the rest of your business.
