PART 2: GDPR : where we are now
In the last article we examined the changing landscape of processors and controllers under GDPR. We continue our examination of why the introduction of the GDPR has encouraged service providers to re-brand themselves as controllers.
Processing contracts more complex and increase processor burden
The GDPR has added further complexity to contracts between controllers and processors and has significantly increased the burden on processors. Under Article 28, any contract by which a controller engages a processor must:
- prohibit the processor from subcontracting any processing without the controller’s authorisation
- Prohibit the processor from transferring data outside the EEA other than on the controller’s instructions
- oblige the processor to assist the controller with its controller obligations under the GDPR to respond to data subject requests, implement security measures, report breaches, carry out data protection impact assessments and consult with supervisory authorities
- oblige the processor to delete all copies of personal data ‘after the end of the provision of services relating to processing’
- oblige the processor to provide all information necessary to demonstrate compliance and allow and contribute to audits and inspections
These mandatory terms can take months to negotiate, arguing over points such as whether the provider can charge for the assistance it has to provide or for providing information requested by the customer (e.g. completing lengthy customer due diligence questionnaires), whether the ‘self-service’ tools available via the provider’s software fulfil the assistance requirements, which third party sub-processors the provider can use in providing the services – both at the time of the contract and in the future, what international data transfers are permitted, whether the provider can limit its liability in relation to the processing, whether the customer will have corresponding liability to the provider, whether indemnities will be granted, by whom, and whether they will be limited in scope and amount, what data deletion processes will apply and how will these be enforced on sub-processors, who will pay the costs of audits and inspections, what the ‘appropriate’ security measures should be...
These contracts also now have to include comprehensive detail about the processing, including the subject-matter, duration, nature and purpose of the processing, types of personal data and categories of data subjects. This exercise can prove challenging in itself and often reveals that neither party fully understands what personal data the provider will process as a processor or a controller, and in some cases that the provider doesn’t actually process any personal data as a processor.
The restrictions on using subcontractors to process personal data and transferring personal data outside the EEA without authorisation from controllers are particularly tricky to deal with in contracts and barely workable in practice for many providers. This is especially true for providers of software and platform-based services that use third party digital infrastructure, data storage and software applications as an integral part of the IT environment through which they make their services available to customers. Those third parties will generally be ‘sub-processors’, and using them often involves international transfers of data – particularly as so many market-leading tech companies are based in the U.S. This means that customer contracts have to become longer and more complex to try to obtain the required customer authorisation for the use of third parties and any data transfers involved at the time of the contract, with processes to notify customers of future changes, enable customers to object and specify the possible outcomes of a customer objection. It would be much easier for such providers to be controllers, free to use, add and change third party services in the most technically and financially efficient way (subject to complying with the GDPR) and avoid long and complex customer contracts.
And let’s not forget the ‘elephant in the room’ of Article 28: a processor who engages a sub-processor has to impose ‘the same data protection obligations’ on that sub-processor as are imposed on the processor in the contract between the controller and the processor. A large majority of processors are probably in breach of this requirement, because it just isn’t possible in the real world: what SME service provider, compelled by their customers to accept onerous data processing obligations and liability due to unequal bargaining power, is able to impose those same onerous obligations and liability (including indemnities?) on the likes of Microsoft, Amazon or Facebook?
Unfortunately, for many providers for whom Article 28 poses the most difficulties, the nature of their processing for customers makes it impossible to escape the designation of ‘processor’ and the resulting requirement for arduously long, complicated contracts with their customers.
New breach reporting obligations more detrimental to processors than controllers
The new breach reporting requirements of the GDPR are arguably more disadvantageous to processors than to controllers: whilst controllers can avoid reporting a breach to the supervisory authority if the breach is ‘unlikely to result in a risk’, and only have to tell data subjects about a breach if it is ‘likely to result in a high risk’, processors have no such discretion or flexibility – they have to notify the controller of any breach ‘without undue delay’ after becoming aware of it. Failure to comply with this obligation to notify controllers is subject to the €10m/2% of annual worldwide turnover fine. Plus, the contract with the controller will often impose even more stringent requirements on the processor, such as a 24-hour notification deadline, notification of suspected or attempted breaches as well as actual confirmed breaches and breaches affecting the processor and any sub-processor even if the controller’s personal data isn’t affected. So whilst controllers can, working within the law, retain some control over disclosing breaches and avoid the inevitable bad publicity and reputational damage following a publicised breach, processors lose all control over such disclosures by virtue of being designated a processor rather than a controller. Even worse, because the underlying IT infrastructure used by providers to process personal data on behalf of customers as a processor will often be the same infrastructure that it uses for its own processing as a controller, providers could find themselves forced by the law to disclose data breaches in their capacity as a processor that they would otherwise have a discretion over whether to disclose in their capacity as a controller. This inequitable impact of the new breach reporting requirements is a compelling reason for providers to try to re-position themselves as controllers rather than processors when providing their services.