Over the last few years we had our hands full discussing and negotiating Data Processing Agreements (DPAs). The 6 tips below are based on our practical observations and things we have learned. We hope this will offer useful insights to DPOs, legal, procurement and outsourcing stakeholders who come across DPAs in their daily work. Please note that the tips we share are not a legal advice.
In this piece we focus on the difficult art of DPA negotiation, and will not discuss the topic of data protection roles (controller, processor, joint controller). If you would like to know more about this, you may read our previous blog post: The importance of data protection roles in product development.
1. Context is king for your DPA.
There is no way to negotiate an effective DPA without understanding the subject matter of the contract. This means that your starting point must be to understand:
- What the service is about
- What data you will share
- In which territories personal data will reside.
Once you have good grasp of the above, you can start completing your DPA template. The DPA should accurately reflect what data is transferred and why. Without understanding the context, it will be challenging to address the disagreements between parties. Let us take indemnity given by the processor as example. The context will drive how aggressively you might need to negotiate your position. If the data you are sharing as part of the services is low risk in nature, liability caps may be accepted, and you can move on. On the other hand, be careful when sharing data that is sensitive to your business. Any compromise to it could risk your license to operate due to loss of trust. In this scenario, you may need to take a firmer position. In certain cases, you may even decide to walk away if the processor is not willing to accept your terms.
2. Common pitfalls when negotiating liability in the DPA.
As a controller, you would typically like to leave liability uncapped. The true cost of a privacy breach is difficult to accurately estimate. Experience teaches us that it can be many times higher than the value of the service contract. This is why you need to watch out for proposals that would defer liability to the main contract. The main contract may include a liability cap assessed purely on the commercial impact of a sudden loss of services . It would typically not include the business consequences of losing or compromising personal data. What should you do if the processor wants to refer to the caps agreed in the main contract? Think about the context and negotiate accordingly. Never accept deferring to the liability caps of the main contract without assessing the context and assuming that it would be satisfactory if this is what the parties had already agreed.
3. The clock ticking? A breach notification timeline.
There are very few DPA negotiations where parties do not debate the timeline for notifying personal data breaches. The controller typically proposes 24 hours and the processor wants to extend it, or not include any time limitation at all. Rather, they would propose to use a term like “immediately” or “without undue delay”. Each option may meet the legal requirements set out in GDPR for this.
From an operational perspective, certain solutions may be preferable to others. Again, and back to point one, the extent to which it makes sense to argue for 24 hours depends on the context. When sharing personal data that has lower risk of harm, you may accept a vague ‘without undue delay’ solution, because the risk of any negative scenario is very low anyway. Consequently, you can accept some extra risk that you and the processor will have a different perspective on the meaning of undue delay. However, when the personal data has a high potential of causing harm to individuals, and by extension your business, you would insist on 24 hours or another time limit, to ensure notification reaches you quickly. This will give you more of an opportunity to respond appropriately.
4. DPA clauses that may put your GDPR compliance at risk
Some processors may insert clauses around personal data re-use into your DPA. This carries real risk, as accepting this practice may be contrary to what you stated in the privacy notice provided to the individuals. It is best to reject such provisions. Only in rare scenarios where any such re-use would be in line with the privacy notice and other applicable privacy principles, it may be ok to accept. What if you would like to reject but the other side insists on re-use clause? You may insert a condition whereby such re-use is only permitted after the data was successfully anonymised, so that it is taken out of the remit of GDPR. Remember, to reach a level of sufficient anonymisation you need to alter the dataset in such a manner that it is impossible to re-identify a person from that dataset, or by using other data sources.
5. One DPA to rule them all?
Large organisations often deal with a complex matrix of vendor relationships. Many vendors are also large institutions with an extensive product range. This means that a company can have several service contracts with the same entity, and a certainty that more will come in the future. In order to streamline current and future contracting, there is a temptation to sign one overarching DPA. For example, it would name all data elements imaginable, and a wide array of potential services. The motivation behind this solution is typically reducing the DPA negotiation time. This sounds effective, but there is a trap. For one, the supervisory authority may challenge this. By listing too much you lose control over what you actually shared, and control over personal data is a big theme in GDPR. Secondly, this may also introduce larger operational challenges.
We have witnessed many situations in which a vendor caused a data breach. One of the first things a Data Protection Officer does upon receiving such a report is checking out the DPA. A well drafted DPA will give you a good sense of what data you shared, so that you can measure your risk. If you, on the other hand, listed all the data categories you could name at the time, it will be a meaningless piece of paper which doesn’t help you to assess the gravity of the situation.
Need a practical solution?
We understand the challenge of having to constantly negotiate new DPAs. The solution that may help, without putting you at risk of losing control, is splitting your DPA into two parts. One part contains all key terms that are mandatory and standard for all services. The second part details the actual data shared in relation to a given service and a given purpose. Much like a relationship between Master Service Agreement and a Service Order. This way, you can sign one ‘master’ DPA with your large vendor, and then every time you need to add a new service, you sign part two only, detailing that particular data transfer scenario. In our experience this goes a long way in streamlining the DPA negotiation process.
6. Think beyond what the GDPR requires
Many DPA templates mirror the language included in GDPR art. 28, concerning contract requirements. This can be enough to satisfy the data protection law and steer clear of any immediate administrative fine, but it will not prevent operational headaches. Areas in which we recommend thinking more broadly are those where the controller and processor will need to collaborate.
For example, in most negotiations, you would spend time discussing whether a breach reporting timeline will be 24 or 72 hours, or without undue delay. But there is no discussion and no corresponding provision in the contract that will lay out how to report. Who should get them? What they should contain? Our experience shows that this becomes a real challenge. Significant percentage of data breaches are reported to the incorrect stakeholder (e.g. commercial contacts, who are not necessarily aware of the time sensitivity, or can be away from the office).
The internal cycle that a notification needs to go through before reaching a competent person who will initiate an appropriate reaction can be very lengthy. This almost guarantees a breach of the law. The GDPR requires reporting a personal data breach in due time, and no later than 72 hours after becoming aware. In addition, even when notification finally reaches the right person, in many cases the notice does not contain the information necessary to make the severity assessment. What is worse, you need to send out a reply, which may again follow a similarly lengthy route to the competent person. You can avoid this by discussing it at the time of signing a DPA. Consequently, consider including the following elements in your contract:
a) who must be notified (ideally select a way of notification through a channel that ensures continuous monitoring), and
b) what information that notification should contain.
Our top six DPA tips summary
- Take time to fully understand the context and always negotiate with reference to this context.
- Be wary of the terms of any liability caps, in particular an argument that a cap was agreed in the main contract.
- Breach reporting is one of the most critical arrangements and there are different ways of setting a compliant timeline. Select an option that aligns with the service in question.
- Keep an eye out for any data re-use clauses.
- A one-size-fits-all solution will not work for DPA, but there are ways to streamline your process.
- Remember a good DPA is also about setting out the ‘how’ of your collaboration with the processor.
If you would like to learn more, or you would like to spread this practical know how in your organization, we have a dedicated training offering around privacy vendor management and DPA negotiations. In this training module we share additional practical tips and cover a wider array of privacy challenges. All in the context of vendor management. Please reach out to us for more details and a quotation.
