PART 3: GDPR : where we are now

In the previous articles we examined the changing landscape of processors and controllers under GDPR and then some of the challenges facing processors, post GDPR. We continue our examination of why the introduction of the GDPR has encouraged service providers to re-brand themselves as controllers.

 

Why providers are pursuing controller status post-GDPR

Within the new controller/processor landscape created by the GDPR described above, the motivations for providers to re-brand as controllers are summarised below:

  • avoiding the practical difficulties/unworkability of needing customer authorisation to use subcontractors and IT services involving transfers of personal data outside of the EEA
  • avoiding excruciatingly long and complex Article 28-compliant customer contracts
  • avoiding high-risk, one-sided liability exposure and indemnities generally demanded by customers in controller-processor data processing contracts
  • avoiding having to disclose personal data breaches that it would otherwise have discretion to disclose as a controller

 

Mutual benefits of providers being controllers?

Now that processing contracts between controllers and processors have become so complicated thanks to Article 28, life is simpler for both parties if they accept that the provider is a controller – where that is a reasonable conclusion on the basis of the facts of the processing involved.  If contentious controller-processor terms that tend to involve months of negotiation can be replaced with controller-to-controller terms simply requiring customer and provider to comply with data protection law when processing relevant personal data, cooperating with each other regarding data subject requests and supervisory authority involvement, and have mutual, sensibly-limited liability to each other, this can keep contracts simpler, shorter and easier to agree, avoid both parties spending time and resources on protracted negotiations, and actually encourage a more cooperative and responsible approach to the processing.  Such an approach is also likely to operate to the benefit of data subjects as well.

 

Personal data breach reporting

The GDPR introduced new obligations on both controllers and processors to report personal data breaches (meaning a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed).  This reporting is subject to tight deadlines – within 72 hours of becoming aware of the breach for notifications to supervisory authorities and ‘without undue delay’ for communicating the breach to data subjects.  A controller doesn’t have to report every breach: they have a discretion that involves making an assessment of the risks arising from the breach.  Controllers don’t have to notify 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’.  Although, as noted above, processors have no such discretion or flexibility and are compelled to notify controllers of any breach ‘without undue delay’ after becoming aware of it.

With no clear definition or guidance on what constitutes a ‘risk’ or ‘high risk’, the risk assessment involved in determining whether to report breaches is proving troublesome, and has led to what could be described as ‘panic data breach reporting’.   The Information Commissioner’s Office (ICO) have reported a spike in reports with 3,146 incidents reported between April and June, jumping to 4,056 in the following three months.  In September, the ICO said that it was receiving more than 500 calls per week to its breach helpline, with a third of these either unnecessary or relating to incidents that failed to meet the threshold for a reportable personal data breach.  As there is widespread uncertainty about what breaches need to be reported, organisations are erring on the side of caution and over-reporting, out of fear of being fined for failing to report a notifiable breach.  This over-reporting isn’t surprising given the potential fines for making the wrong determination, compounded by the fact that often when a breach occurs, it might not be possible to obtain enough information about the extent of the breach within the 72-hour notification period to be able to conduct the risk assessment.    

Controllers are caught between a rock and a hard place: report the breach and risk being fined for failing to implement adequate security measures and suffering financially from negative publicity; don’t report the breach and be fined for failing to report the breach if it somehow comes to the attention of the supervisory authority anyway, possibly suffer even greater negative publicity for apparently ‘covering-up’ the breach and still risk being fined for failing to implement adequate security measures.

When you tot-up the potential fines and reputational damage of either course of action, it’s not surprising that organisations are tending to report breaches where there is any uncertainty about whether it is or isn’t notifiable.  The ICO’s guidance on breach reporting doesn’t really provide organisations with any comfort or confidence in not notifying a breach.  And many smaller companies, sole traders and self-employed individuals don’t have the benefit of being able to seek advice from lawyers, data protection professionals or IT specialists when an incident occurs, so it’s no wonder they look to the ICO for help and guidance.

Breach reporting may well be a case of ‘be careful what you wish for’ on the part of supervisory authorities, who now find their human resources stretched in responding to breach notifications and breach helpline calls rather than pursuing their proactive investigatory and monitoring roles.

Despite the long lead time in the run up to GDPR, many organisations failed to prepare for breach notification, often because more externally-facing compliance issues such as privacy policies and email marketing lists were prioritised.  However, it is highly advisable for all organisations to have a data breach response plan in place, make sure people know their roles and responsibilities and conduct regular training on it.

 

Liability for personal data processing breaches

The huge fines that can now be imposed under the GDPR have increased financial risk in relation to personal data processing for all organisations, whether controllers or processors.  The fact that processors as well as controllers can now be fined by supervisory authorities and sued by data subjects, and that various processors and controllers can be held jointly liable for damages paid to data subjects, has dramatically altered the risk-allocation context.  This has led to organisations revisiting liability-related provisions in contracts to make sure they are generous enough, or limited enough – depending on their perspective.

Traditionally, contracts between providers and contracts would firstly deem the provider to be a processor (as discussed above) and then make the provider solely responsible and liable in respect of personal data processing, often including one-way indemnities from the provider to the customer, and often with little or no limitation of liability under the indemnities or for processing-related breaches – depending on the bargaining strength of the provider.

Now, under the GDPR regime, providers in particular are keen to change this traditional approach.  

The combination of direct liability for processors, potential joint liability between processors and controllers and dramatically increased fines means that providers have an incentive and a justification to argue for changes to liability provisions.

Providers, whether controllers or processors, can now potentially face regulatory fines or damages claims that may have been caused or contributed to by their customers’ breach of data protection law or contractual processing terms, and/or be held liable by a court for the entire damages paid out in respect of a particular processing activity, regardless of the provider’s role or culpability.  In light of this, providers are asserting that both provider and customer should have liability to each other and that mutually acceptable limits to that liability are needed to apportion risk in a way that reflects the changed liability regime of the GDPR and the nature of the relevant processing.

With potential fines increased so significantly under the GDPR, providers are no longer willing to give wide, uncapped indemnities or have unlimited liability in relation to data protection breaches.  This type of liability was just about acceptable when the maximum fine under the DPA 1998 was £500k, but now that the same liability provisions could result in a provider being liable to pay fines incurred by their customers of up to €20m/4% of their customer’s annual global turnover, for SME providers with limited resources to purchase sufficient insurance but providing services to large, multinational customers, a single claim could result in the provider’s insolvency.  As a result, providers are being more assertive, refusing to give indemnities or reducing their scope and insisting on liability caps within their insurance limits.