In one of my first interviews after leaving law school I was asked by several interviewers, “If you had 10 minutes to review an agreement, what would you do?”
After some carefully bought time sipping water, pausing, contemplating, and putting my thoughts together, I laid out a very simple roadmap that goes to the heart of every contract—specifically reviewing high-risk areas of the contract i.e. termination, liability, and services before deciding on whether to sign. Fortunately, this thought process proved that I was not that much of a risk and helped me land my first job as a paralegal, prior to my training contract. In a way, we all work through checklists when approaching new tasks. In my capacity as a technology lawyer, I’ve created a similar mental process when reviewing Data Protection Agreements (DPA) that are frequently attached to SaaS agreements.
As a lawyer based in the UK, the majority of deals I work on involve the exchange of personal data between counterparties governed by the Data Protection Act 2018, UK GDPR, or EU GDPR. The consequence of non-compliance with these data privacy laws is large administrative fines and significant reputational harm. That’s why it is imperative to pay particular attention to data protection issues where personal data is involved. This article is split up into two parts and looks at the more densely negotiated controller-processor relationship and some of the key negotiation points parties often encounter in the DPA, with my go-to negotiation tips for customers/controller.
1. Type of Personal Data
Its always good to get a handle from the outset of a transaction and understand the following:
- What personal data is being processed?
- How much personal data is being transferred and for what purpose?
- What category of data subjects are involved?
- For how long will the data be processed?
- What technical measures are in place to protect the data?
Fortunately, this level of information is usually set out in a table at the back of a DPA, the details of which are required under Article 28 of the GDPR. It’s always good to read through this first and check this through with the business for accuracy so that you can take a view as to how great the data protection risk is.
If for example the only data being exchanged are low levels of contact data of several employees within your organization, you may not need to spend much time reviewing the DPA. However, if the processor is for example handling payroll across your organization you are likely to review the DPA more carefully.
2. Location of Origination and Transfer of Data
Ideally, you will want to ensure your data stays in the UK or EU to avoid the international transfer restriction (see Article 46 of the GDPR). Check with the SaaS provider to see whether you have the option to determine where your personal data is stored and if you can implement a data localization policy. This will allow you to control the location of where your personal data is stored.
If your data does need to be sent outside the UK or EU, then it should be done in a compliant way. You should seek to have assurances that either the EU Standard Contractual Clauses or UK Addendum are in place for transfers outside of the UK or EU respectively. Following on from the Schrems II case, you should also consider as part of your due diligence process conducting local country risk assessments, to ensure that the jurisdictions you are sending data have equivalent privacy laws to protect your data and consider if any additional measures are required to protect your data. Some providers do provide copies, on request, of their local country risk assessments, which they conduct when on-boarding their sub-processors.
The risk here is if your personal data is sent to a country with data privacy laws that do not provide data subjects with an adequate level of protection, you may be in breach of the international data transfer restriction (see Article 46 of the GDPR). By way of example, you may be in breach of the regulation if a foreign public authority accessed your personal data held in a data center where they had jurisdiction. A German company was fined last year by the regulators for failing to consider if additional measures were required to protect personal data sent to US-based Mailchimp.
3. Approval for Sub-Processors
Moving down the supply chain where the SaaS provider uses subcontractors (aka sub-processors), data privacy laws require that data processors notify data controllers of any sub-processors being used and obtain the data controller’s permission or general authorization.
Practically speaking, it’s always a good idea to request a list of who may access your personal data and what they will be doing with that data so that you can conduct your own due diligence on these sub-processors to determine if they are credible and in particular their history with regulators. In most cases, the SaaS provider will be using sub-processors with an established history, your key concerns may be more related to where sub-processors are located. Some providers may allow you to select which sub-processors can access your personal data, in which case you may set out a list to the provider of your approved sub-processors.
It’s also useful to ensure that you are notified in advance of any changes or modifications that have been made to the list of sub-processors so that you have a chance to object or move your personal data to another platform. You can usually request email notifications.
Fortunately, most established SaaS providers are aware of this issue and can make accommodations in their DPAs.
4. Notification Requirements
Article 28 of the GDPR specifies a range of clauses that must be included in a DPA. These include confidentiality of personal data, notification of data breaches, and responding to data subject access requests. it’s a good idea to review these requirements and, in particular, the notification requirements to ensure they are sufficiently well drafted to protect your position.
The standard position in the GDPR is that a data processor “should notify the controller without undue delay,” whilst the responsibility to notify the supervisory authority sits with the data controller (i.e., you) and the timeline for a data controller to provide such notice is “without undue delay and in any event within 72 hours of becoming aware”. Where the data protection risk is significant, you should rightly push for the notification window to be within 24 hours and for the data processor to provide you with as much information and detail about the data breach as possible.
5. Limitation of Liability
Given the large fines issued by regulators in this area, SaaS providers are keen to ensure that their contracts reflect a balance of risk.
It is common to see parties negotiate separate larger caps (aka super caps) on liability to address this issue. Ideally, if you can secure an uncapped indemnity from the data processor, that would be the best option for you. However, this is only really worth the paper it’s written on if the SaaS provider is financially stable enough and has the necessary insurance policies in place to give this transfer of risk any grounding.
A middle ground would be to negotiate a super-cap for data privacy breaches that is separate from and higher than the general cap on liability. This could be a set six-figure sum or a multiple of the fees paid under the Agreement.
What you want to avoid is lumping data privacy breaches in with the general limitation of liability cap. For example, most limitation of liability caps are calculated using the 12-month rule. Namely that the monetary cap will be the amount payable or paid by the customer in the 12 months preceding the claim. This amount is usually insufficient to capture the risk of a data privacy breach which could be the greater of €20 million or 4% of global turnover under the GDPR, depending on the number of individuals who were impacted by the breach and the level of sensitivity of the data breached.
Another point to watch out for are attempts by SaaS providers to exclude liability for any unauthorized access to personal data (i.e. if there has been a data breach). Ideally, you should push back on this, as it would significantly limit the damages that may be recovered in a data breach scenario. To get an idea of how much non-compliance with data privacy laws could cost a controller, it is worthwhile to review the regulator’s enforcement notices (link to ICO’s page provided here). Interestingly the UK is softening its approach on international transfers and a new bill is currently passing through parliament which prescribes a more “risk-based” approach to international transfers.
* * *
SaaS providers operate on a one-to-many services model and are usually reluctant to make changes to their contracts. However, in recent years, SaaS providers understanding of their customer’s regulatory pressures have matured and they have developed appropriate fall back positions and operational mechanisms to ensure their customers can meet their compliance objectives.
DPAs are an interesting contractual beast that set out how parties will work together in handling personal data. Its useful to be aware of some of these key issues before you review a DPA as these will feed into the wider contractual negotiation on price and expected service levels. As a technology lawyer, it pays dividends to understand the technology that the service provider is offering, and in particular how it can interact with privacy-enhancing technologies and techniques (i.e. encryption, access control, anonymization, pseudonymization) so that you can ensure data you send outside your organization is protected. Stay tuned for Part II of this post with five additional data protection issues in SaaS agreements.