It's a cliché that many contract negotiations come down to predictable battles over price, termination and liability.
In the first year of the General Data Protection Regulation (GDPR), we've seen data clauses join that list of regular contract debates. So, what leads to conflict in negotiation, are those conflicts necessary and what can be done to achieve win-win outcomes in negotiations?
One of the most helpful parts of the GDPR has been the list of clauses required in all controller-processor contracts. That list creates a useful framework in discussions. Where it gives clear direction (for example, that people handling personal data must be under a duty of confidentiality) it shortcuts debate – it's difficult for a company to reject a clause where there's a simple legal obligation to have it in the contract.
Where the list has caused more difficulty is where there is discretion around how a requirement is fulfilled. In particular, we have seen both controllers and processors encounter difficulties in reaching agreement on data protection audit rights.
We often see controllers demand that processors allow unrestricted audit rights. We then see processors push back, particularly where they handle personal data for large numbers of controller clients. Processors see unrestricted audit rights as disruptive, as posing inherent confidentiality risks, and as of limited benefit to many controllers.
We tend to see successful compromise where controllers reflect on what they actually need in order to show compliance with the GDPR and how that can be achieved with minimal disruption to processors, and processors consider how they can efficiently support legitimate audit requirements.
The key is often for controllers to recognise that the requirement is not for controllers to conduct audits themselves (a common misunderstanding). The requirement is for a controller to have a contract provision requiring their processor to "make available… all information necessary to demonstrate compliance… and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller".
That language leaves plenty of room for manoeuvre. First, processors will often feel more comfortable where there are reasonable parameters around audit rights. The most obvious are requiring fair notice of an audit, agreeing an audit scope in advance, conducting the audit during business hours, limiting audit frequency and recognising restrictions will be necessary to protect the confidentiality of other customers of the processor.
For controllers running a programme of periodic audits of their key processors, accepting those parameters isn't normally too much of a challenge. What controllers tend to expect, though, is that they can bypass the normal requirements in urgent situations – typically if there's been a breach by the processor, or the controller's industry regulator or the ICO requires a short-notice audit. In our experience, a sensible discussion of what works for both parties will quickly lead to a fair solution.
Secondly, controllers can often save on the costs of conducting audits and potentially get more useful outputs if they agree to rely on periodic data protection and cyber security audits of their processors. These would be conducted by reputable independent third parties.
As long as it is clear that controllers will be deemed to have mandated those audits and be able to access and rely on their results, agreeing that approach can benefit both parties. Controllers get the validation of knowing an expert external audit is being conducted on their processors, perhaps more frequently than controllers would conduct audits themselves. Processors get the advantage of limiting disruption to their business and knowing that audit findings will give them the opportunity to remedy any identified problems before they result in costly data breaches.
In the next article in our GDPR Periscope series, which you can find on our GDPR hot topic page, we will look at another key area of dispute – sub-processing clauses – and examine how a willingness to move away from standard template clauses can make life easier for both controllers and processors.