The Chain of Processors (Revisited)

Over four years ago I wrote an article here about the importance of contractual agreements between Data Controllers and Data Processors in Data Protection compliance. It is an issue that we deal with on a regular basis. It’s an issue that raises challenges in Cloud Computing and Outsourced projects (here’s an article from 2010 on that, and another one). And it is an issue that is going to get both simpler and more complicated with the forthcoming Data Protection Regulation.

A number of years ago we hired a very good lawyer (he’s been to the CJEU a few times and so far hasn’t lost there) to help us develop a standard form Data Processor contract that addressed the needs of Data Controllers under current legislation as well as anticipating the worst case scenario under the draft General Data Protection Regulation. It’s a contract that underpins data processing in a number of very high profile public sector projects as well as dozens of smaller scale engagements.

It is an agreement that has been pushed back against, negotiated against, and reviewed extensively by a number of teams of lawyers (and the DPC). In the course of that we’ve learned a few lessons about the trials and tribulations of the coming Data Protection world. Indeed, I can still recall the conference call on one project where the very highly paid lawyer acting for a Data Processor complained that he’d “never seen the like of this” when presented with the agreement.

Ultimately, the agreement between Data Controller and Data Processor is a key element in your System of Information Governance and provides the means to give effect to checks and balances to ensure risks are correctly mitigated, processes appropriately controlled, and models for decision making, responsibility, and accountabilty clearly understood.

While we don’t give legal advice (we can introduce you to a very good lawyer who does), our experience in the trenches has given us some practical insights, which we tend to channel through the mantra of the Great Sage: Mr Kenny Rogers.

You’ve got to know when to hold ’em, know when to fold ’em,

Know when to walk away.

Know when to run.

The Current Legislative position

Under the current Data Protection laws building off Directive 95/46/EC, the obligation is on Data Controllers and Data Processors to ensure that there are “appropriate organisational and technical controls” in place to prevent unauthorised access to, alteration of, or disclosure of data.

Security is the minimum requirement. Even Data Processors have an obligation to ensure security that can give rise to liability if not met.

Everything beyond that is up for grabs and needs to be dealt with in the contractual agreement between the Data Controller and Data Processor. Issues such as what the service provided by the Data Processor is (or should be), and whether or not data will be transferred ide the EEA, and if it is, on what basis that will happen (e.g. security controls, adequacy of data protection controls etc), the overall governance controls to be followed when changes to processes/processing/jurisdiction etc, compliance with Breach Notification or Data Subject rights (e.g. Access), and the questions of indemnification or dispute resolution mechanisms.

As the buck stops with the Data Controller, from a statutory basis, under current rules, it pays for the Data Controller to invest some time and effort into setting out the terms under which they will engage a 3rd party to process data on their behalf. So, what should you include? Here are some example items:

1. Definitions of key terms. Avoid the temptation to use “lawyer words” when real words will do the trick. Reference relevant legislation where necessary though.
2. The scope of application of the Data Processor Agreement: What data does it cover, and from what point in time?
3. A contractual clarification of Data Controller and Data Processor roles (who’s doing what role) – although beware of the “factual relationship” interpetation that the A29 Working party defined and which will be applied by Regulators.
4. A control on “scope creep” on the part of the Data Processor. If they go “off reservation” and act without instruction you need to be clear what that will entail. This means you need a CHANGE CONTROL process.
5. Require the Processor to process data in a manner consistent with legislation and relevant guidance that may be issued
6. Specifically mention security (because it is specifically mentioned in the legislation)
7. Require training of staff to an appropriate level
8. Require notification of Data Security breaches (so the Data Controller can in turn assess risk and notify Data Protection Authorities/Law Enforcement/Data Subjects as appropriate)
9. Require Sub Processors to be held to a substantially similar set of terms
10. An enforceable right of audit, inspection of organisational and technical security measures, and the right to inspect contract terms for any sub-processors
11. Defined actions to be taken in response to a Subject Access Request

Balancing Risk

A common misconception is that a Data Processing Agreement allows a Controller to avoid liability or “pass the buck” in the event of a breach of legislation or obligations. That is, sadly, not true. What is possible is for the Data Controller to share the risk and spread the load by requiring a Data Processor to take actions at their own expense to fix problems, to bear costs of investigations, or to indemnify the Data Controller against the direct and consequential costs and losses arising from any breach of the relevant Data Protection legislation or the Data Processor agreement.

So, including language requiring the Data Processor to cover costs of investigating breaches, and specifically seeking indemnification for costs and losses arising from the acts or omissions of the Data Processor or their sub-contractors would be a good idea. It’s also a good idea to spell out in the Agreement (either in the body or in a Schedule) what the scope of the actual processing is. We use the POSMAD framework in our master template with clients as that aligns the activities that are to be undertaken with key steps in the life cycle of Information: Planning, Obtaining, Storing/Sharing, Maintaining, Applying, and Disposing.

The Processor’s Perspective

As Muhammad Ali once said: “Everyone has a plan, until they get punched in the face”. Part of balancing risk in the context of Data Processor Agreements is the perspective of the Data Processor. And here is where the mantra of the Great Sage Kenny Rogers comes into play:

• You’ve got to know when to hold ’em

Your opening version of the Data Processor Agreement will contain a set of clauses, terms, and conditions that you want. You need to know what your non-negotiables are. Security is one. Support for security obligations is another, clarity about the governance of changes to the agreement is another. Essentially, I’d suggest that anything about the control of doing things with data needs to be a red line issue. Any changes should be for equivalent or superior obligations or undertakings. How much of a change you accept is a function of the Risk Appetite in your organisation and how “bullet proof” you might want to be (note: nothing is bullet-proof, just “ballistic resistant”)

• You’ve got to know when to fold ’em

​There will be clauses and terms in your agreement that you can give ground on. Generally, these will be clauses relating to indemnification or the allocation of risk on to the Data Processor (strangely, they don’t seem to like that). Strategically, these should be clauses that you define at the outset to be very onerous so you can dial that back to a point where the other side will agree. However, this is a function of your commercial risk appetite in the context of the Data Processor and the nature of the data they are processing. How much of a hit could you afford to take? What other avenues would you have to recover from losses (e.g. other avenues of litigation)? Can either party get insurance for the risk?

It is at this juncture that Data Controllers and Processors often have their collisions. Ultimately, there is a decision to make about what the bottom line needs to be and what can be sacrificed from your “ideal” to achieve a functional and enforceable agreement. Legal advice is advised here to make sure you don’t dilute your controls as a Controller. Often, this is the element where the Processor’s legal advice will be to not accept the agreement, so appropriate commercial sense will need to be applied.

• You’ve got to know when to walk away

​Data Processor Agreements are a negotiation. Sometimes the best option is a “win win or no deal” approach where you are haggling. Walking away gives a chance to reopen discussions, talk to other potential providers, but all the while keeping on cordial commercial relations. Sometimes you need to walk away from some elements of the agreement, but only if you are clear what the red line items are that you can’t work without. Applying standard software development priortisation techniques like “MoSCoW” (Must/Should/Could/Would) can help.

• You’ve got to know when to run

My personal rule of thumb: If the Data Processor refuses to negotiate or entertain any discussion about your requirements, RUN.

The exception is cloud service providers or hosting providers who will have standard terms and conditions that will be applied to all but the largest clients. In general terms, you should pay close attention to their service level agreements and what liabilities they exclude themselves from. Anything other than security controls, access to your data, disclosure of your data, or transfer of your data outside the EEA is a matter for negotiation. But those elements should be red line items as they are the minimum standard in current legislation.

As it is unlikely that a hosting provider or PaaS provider (e.g. Microsoft Azure or AWS) will be actively processing your data other than providing storage, data transfer, and backups, this may be sufficient (but check what additional things they might be doing!).

For SaaS offering such as Salesforce, Office365, BaseCamp or similar you would be advised to read their standard T&Cs carefully to see what actual processing is done and the control you, as Data Controller, will have over it.

What’s coming in the GDPR that affects things?

This is a topic I’ll explore in more detail in a later post (when the ink is finally dry on a finalised text so I’m not hitting a moving target). However, the key change for the Data Controller/Data Processor relationship will be that Data Processors who act beyond the scope of their defined processing purposes under a Data Processing Agreement will be considered to be Data Controllers in their own right and will be subject to the full rigours of the Regulation. And as they will be unlikely to have obtained data fairly for this new purpose, they will have a challenge avoiding the significantly increased penalties that will exist under the new legislation.

These penalties apply to breaches of security as well. While the obligation on a Data Processor won’t change to a substantial extent here, the penalty for not having appropriate organisational and technical controls in place will likely be a significant order of magnitude higher than under current rules. This should lead to Data Processors adopting higher standards, or adopting standards proportionate to the types of data being processed. This may lead to higher costs, but robust investment in appropriate security is something organisations should be doing anyway. The GDPR changes the business case and priority.

Data Controllers who have traditionally operated on a nod-and-handshake basis with their Data Processors will need to implement more formal Information Governance controls (themselves a requirement under the GDPR), at the very least a mechanism to record changes to the scope and purposes of processing activites under the Data Processing Agreement. Absent that, expect to see litigation bunfights erupting as “he-said/she-said” disputes arise as a result of dumb instructions being given by phone or misunderstood. It would be worth all organisations reviewing their rules around who can negotiate or change contracts on their behalf and making it clear who the “decider” is for any Data Controller/Data Processor relationship.

Conclusion

Data Processor Agreements are all about risk mitigation and control. Current legislation sets minimum standards that will be carried over into the GDPR with some additional obligations and requirements. These minimum standards, regardless of whether you are basing your strategy on current legislation or the “coming attractions” are ultimately about balancing commercial risk between operators and ensuring that there is clarity about who is expected to do what, when, and why. Organisations that bite the bullet now and invest in going beyond a handshake in the formality of their agreements with Data Processors will likely find themselves in good stead once the Regulation comes to pass.

When the text is finalised, it would be a prudent step to sit down with your legal advisors, your compliance team, and your Data Processors to review all existing agreements and assess compatibility with the Regulation and then evolve your agreements over the coming 2 years to be ready for when enforcement will commence.