Rocketseed as GDPR-compliant Processors have tackled some of the complex issues regarding indemnity and thus, through our experience in shark-infested waters, let us help you to find your way to safe shores… in time for the BBQ.
Once upon a time there was GDPR…
General Data Protection Regulation (GDPR) was like a roaring ocean of regulations and novel definitions, under which horrible shark-like predators called “major fin(e)s” were swimming and threatening to swallow companies. Bobbing along this ocean and trying to make sense of it, I spoke to an expert who said the whole issue is like a “balloon”; you press one side to solve a problem and another bulges out. What has bulged out in the wake of GDPR is a heated discussion between Controllers and Processors in the context of contractual negotiations. In other words, law in theory versus law in practice, and avoiding to fall under the gavel whilst hammering out a legal bulge called “Indemnity” between the two bearing legs of a contract and leaving negotiations rather limp.
Before I jump into this zesty discussion on things to consider in contractual negotiations between Controllers and Processors, allow me to define a few concepts.
- Controller: Individual or company controlling and/or is responsible for the keeping and use of personal information; i.e. determining the purposes and means of processing personal data
- Processor: Individual or company responsible for processing personal data on behalf of a controller
Why should I read this?
Because you’re curious about hammering out this bulge!
Well, the first hiccup in the wake of the GDPR, has been the demand by Controllers for uncapped, open-ended indemnity clauses in contracts to cover for costs incurred if it is the fault of the Processor. But how realistic is this in practice?
Data protection liabilities, pre GDPR, have on average been capped at 2x-5x the value of a contract, but Controllers consider those caps insignificant in comparison to the [threat of] 4% of annual worldwide turnover, if found accountable by no fault of their own. The issue arises since GDPR sets out obligations from the perspective of a Controller (Art 5(2)) and includes accountability for failing Processors, and subsequently may also have to compensate individuals for damages suffered. But this is not entirely the case, although some lawyers do like scaremongering to spark lengthy, hard-to-resolve-discussions where the hourly payments quickly ramp up.
Processors can be held directly liable by Data Subjects for breach if they have either been non-compliant to GDPR or acted outside of the scope of a contract (Art.82(1)-(2)). Additionally, if Processors act outside of the scope of a contract, they are treated as Controllers in respect of that processing activity and are directly liable for any issues arising thereof (Art.28(10)). Also, if they transfer data outside of the EU, they are directly responsible to having appropriate transfer protocols in place (Art.44). Other obligations are set out further below.
A few things worth taking into consideration when negotiating
1. How to pacify the sharks… Have a conversation!
GDPR and Data Protection Authorities (DPAs) really have no solid answers to provide, since the legislation and surrounding issues are much too recent. Thus, one must proceed with sensible risk management and honest discussions between Controller and Processor. Curb the fear and smell the coffee over some Danish and engage in constructive negotiations.
2. More sharks or just bigger sharks?
One has to ask; is the perceived risk of being fined justified, or has it inflated along with concern? Although GDPR will require more than a few months of implementation to give a statistical value on the topic, it would not seem likely as many companies have exercised caution and will necessarily have to be more vigilant going forward. Everyone fears to be made an example of, but one would appreciate DPAs have more tasks on their agenda than scouting for a prospect to annihilate. If you’re reading this as a Controller, what is your take on it? Feel free to respond and let’s exchange knowledge.
3. Are the sharks really that big and do they always attack full force?
DPAs have a number of tools, and suite of sanctions, to help organisations comply before unleashing Jaws, and these include; i) warnings, ii) reprimands, iii) corrective orders, and lastly vi) fines. It will not go straight to pocket, but knowing Jaws is out there, may be uncomfortable enough to make businesses comply.
The recent maximum penalty of 500k GBP has been given to Facebook for major trust and data breach. But since Facebook makes about 400k USD every five minutes, some might say they got off easily. Overall, the ICO has been reasonable with regards to fines; below are a few, recent examples of shark-bitten organisations.
- Medical centre in the UK fined ~£40,000 after it left highly sensitive medical information about patients (personal medical records) unsecured for nearly two years.
- Independent Inquiry into Child Sexual Abuse (IICSA) fined £200,000 for revealing identities of abuse victims in mass email by not using BCC.
- Lastly, Yahoo! was fined 250k for its security breach in November 2014 that affected 500 million users, but wasn’t reported until 2016. Yahoo! had been the subject of a very sophisticated attack, which led to Russian IP addresses.
As depicted above, there is a perspective to the fines; they depend on the type of data (personal, sensitive, or highly-sensitive), as well as the number of people affected or at risk.
4. What goes around comes around?
There are many other pertinent considerations to take into account during negotiations, such as i) the life of the contract, ii) the value of it and iii) the degree of exchange within it. Otherwise, there is the chance that the Processor may insist on unlimited liability from the Controller – counter-indemnity.
Exceeding the value of a contract and resorting to excessive figures may lead to the Processor simply filing for bankruptcy, leaving the Controller shouldering problems on its own. Hence, in some cases it may be worth bringing up the topic of Cyber Security Insurances and the scope it covers. If budget allows and specific conditions are needed, perhaps consider ringfencing contract for a particular client with included Cyber Security Insurance. These insurances are quite costly and need to be put into perspective of the contract value and risk of breach. Additionally, some Processing services also offer depersonalisation of data that may be an option for Controllers.
5. What triggers the shark?
Apart from previously mentioned examples of direct liability, Processors need to inform and ask for permission when appointing sub-processors (Art.28(2), (4)) and make sure these have proper procedures in place to be compliant with GDPR before appointing them. Processors also need to ensure that Controller requests/instructions comply with EU law (Art.28(3)(h)), strictly process data for purposes set out by Controller, and implement appropriate technical and organisational security measures to protect personal data against accidental or unlawful destruction or loss alteration, unauthorised disclosure or access (Principle 7 in the Data Protection Act or Principle f in GDPR, Art.28(1), (3)(e), (4), and Art.32).
Following GDPR, the pattern of breaches have not changed, but awareness has. According to the ICO data security incident trends are still dominated by breaches to Principle 7 and include the following:
- Data posted, faxed or emailed to incorrect recipient
- Loss or theft of paper work
- Failure to redact data
- Failure to BCC
6. “Please sir, I want some more…”
One of the most frustrating statements to be faced with, in any setting, is; “It needs to be reasonable.” This is often dealt with in processes involving property issues when trying to make sense out of fees, contracts or lease extension [trust me]. No one really knows what is reasonable at the moment just by looking at businesses with similar products or services, because it depends on so many various factors; size of business, type of data, instructions for processing, possible transfer outside the EU, value of contract, risk of breach etc. The best way to set the new rules is by creating them through honest discussions between Processors and Controllers. Bottom line is, it’s a two-way street and if Controllers like your service they are willing to work with you.
7. Be complaint as it’s your lifeboat!
A useful Lifeboat, which Rocketseed has utilised, for GDPR and future upcoming legislations, is GDPR365. This platform provides the necessary steps with guidance to become GDPR ready. Additionally, it also collects the data making it easy in case of audits to present your company profile. Register now!
We are all in the same boat, even if some Controllers may be in a large cruiser and Processors bobbing behind in a small dinghy. The bottom line is, We Can All Sink, so let’s try to help each other to stay afloat in this big ocean called GDPR.
Let’s go to the shores and throw a shrimp on the BBQ.
