You have decided that you want to engage with a specific processor. Your next step in this -sometimes long- journey to compliance is the signing of a Data Processing Agreement (DPA) with them. Apart from it being an obligation set out by the GDPR, the DPA is also a very useful tool for Processor Management. In the DPA you will make your rights and responsibilities clear, you will clarify the procedures that the processor will have to follow to help you fulfil your obligations as a controller, and you will legally bind the processor to impose the same obligations it has towards you to any sub-processor it uses.
Not everything you will include in the DPA is negotiable, as article 28.3 of the GDPR sets out all the points that must be addressed. Nevertheless, some parts of a DPA are of negotiating interest, and this article is all about them.
As a controller, you are first and foremost accountable for any data breach that occurs to your processors. The reason for this, as we mentioned in a previous blog, is that the GDPR obliges the controllers to ensure that the processors they choose to share any personal data with have appropriate technical and organisational measures in place to ensure information security. The processor also has a direct legal obligation stemming from the GDPR to implement them. Through the DPA, in which these measures are specified, the processor also becomes contractually liable on its own for any data breaches it suffers due to the lack of said measures.
In case of a data breach, you as a controller have to investigate and contain the breach and take appropriate action for the notification of your Data Protection Authority and the data subjects affected, if needed. For you to fulfil these obligations, the processor has to cooperate with you promptly and in good faith. The details around this cooperation must be clearly stipulated in the DPA. For example, DPAs usually include a clause that specifies how many hours the processor has to notify the controller of the breach. This is a point of negotiating interest since you’ll want to keep this timeframe as short as possible, while the processor will intend to provide himself with as many hours as possible.
Auditing the processor and making sure that they comply with both their legal obligations and contractual commitments, is practically the third part of Processor Management, the most tricky thing after Due Diligence and DPAs. There are many questions regarding this matter that need to be answered in the contract. For example;
- Will the audits be onsite or offsite?
- Will they be conducted by your organisation or by third-party auditors?
- How often?
- Does the controller need to provide a certain period of notice before conducting an audit?
- What information will the processor make available to the auditor?
Moreover, it is a common practice for processors to hire a third-party auditor to conduct the audit at specific intervals (e.g. annually) and provide controllers with a written report of the audit. In case this does not satisfy you, you will have to negotiate the details of any further auditing.
Any kind of interaction between you and the processor may involve extra costs. For example, this may occur when the processor assists you with data subjects’ access requests, or with the carrying out of a Data Processing Impact Assessment. The same may happen when you wish to audit the processor. Answering the question of “who pays for what?” beforehand and setting out everything clearly within the DPA is definitely a good practice to avoid confusion or misunderstandings.
Last but not least, the liability of the parties is a matter that concentrates a lot of attention during negotiations. Something to keep in mind here is that your due diligence as a Controller will always be held to account first unless it is absolutely clear that any breach of the regulations was caused by the processor’s negligence or ‘bad action’. For that reason, you need to exercise and document your due diligence and regularly audit and monitor the processor.
Despite the above mentioned, liability can still be a commercial consideration. You can always try to specify the liability in the contract with the aim to cover your costs incurred as a direct result of any breach of the GDPR by the processor. These could include costs of remediation (e.g. writing to customers, paying for credit monitoring services etc.). Of course, it is only logical that each party will want to limit as much as possible their liability from breaching the GDPR. In practice, however, it is not to be expected that the processor will accept unlimited liability. The most common business practice at the moment is that the liability cap is the value of the service agreement.
Before signing a DPA with any processor, you will want to negotiate on some important matters. Data breaches, audits, costs and liability are some matters of negotiating interest. Of course, both sides will intend to insulate themselves as much as possible from potential GDPR violations. The market dominance of the parties should not be overlooked. Giants like Microsoft and Google provide their controllers with their DPA template, in which they include all terms pre-decided from their part. Our final thought is that, for the contract to stand up as fair, it is not a good practice to try to impose unlimited liability or illogical obligations on one of the parties.