I’ve been spending a lot of time helping clients with third-party due diligence lately. This involves digging through terms and conditions, privacy policies, contracts and marketing materials, which is fun in a data-protection-bloodhound-scents-prey sort of way, but is also an activity that usually pushes me up onto one of my soapboxes to have a rant. This one is called ‘Processor Shenanigans’, and it’s a favourite.
Okay, so the GDPR says there are two types of organisations; Controllers and Processors. An organisation is a Controller if it is making its own decisions about the purpose and the means of processing personal data (the ‘why’ and the ‘what’). An organisation is a Processor when it carries out processing of personal data on behalf of a Controller who is making the decisions about purpose and means. (This is nice and confusing, because all operations that touch on personal data are ‘processing’, no matter who is doing them or in what kind of format. Just remember that the noun ‘Processor’, when spelled with a capital P means ‘an organisation that’s doing a Controller’s bidding’, whereas the verb processing (spelled with a small p) means ‘doing anything at all with personal data’).
So, there are Controllers and there are Processors. In a tidy, ideal world, organisations would be one or the other, and always would stay in their respective lanes – but real life is not as easy as that, especially when processing is outsourced to take advantage of skills or infrastructure that aren’t available in-house.
The Controller is in control – theirs is the final word on the processing. A Processor just does what they’re told by a Controller. That’s the theory, anyway.
There’s a tendency for people to assume that a Controller is always and only a Controller, while a Processor is always and only a Processor. Lordy, if only things were that simple! Or that if Company X is paying Company Y; Y will therefore only be a Processor. It’s definitely more complicated than that though.
Hats
These roles are like hats. Hats can be taken off and swapped for other hats, depending on the weather or the occasion. A company can wear a Controller hat for some processing activities, and a Processor hat for others. For example, a company providing online payroll services will wear a Processor hat when working with a customer’s payroll data. However, when they process personal data relating to their own internal functions, like HR, marketing and sales, facilities management, health and safety etc, the payroll company wears a Controller hat. One organisation may have many hats. One hat may have many wearers!
It’s jolly tempting for organisations to want to declare themselves Processors, because Processor liabilities under the GDPR are much smaller than those for Controllers. Processors have to follow the terms of their Processing contract, and have ‘appropriate’ security; whereas Controllers are responsible for upholding all of the Principles and data subject rights, as well as ensuring that their Processors do too. So, contract relationships and data sharing agreements become a tangle of deniability as each side seeks to disclaim as much responsibility as possible, while still extracting maximum benefits from their processing activities. All too often, the resulting texts bear very little resemblance to the realities of the data flows and decisions being made.
The Paperwork-Reality Gap
Now here’s the thing….Controller and Processor roles are determined by the facts of the processing – the behaviours, decisions, actions and degree of autonomy that each party has over why the personal data is being processed, and how that processing is carried out. Not what the paperwork says. If the paperwork says Company A is a Controller and Company B is a Processor, but Company B is putting the personal data to uses which are desired and specified by Company B without Company A having any say in those uses; then Company B is wearing a Controller hat and the paperwork is wrong.
If the paperwork says that Company B is a Processor, but that Company B can also re-use the data it has acquired through being a Processor for Company A, for its own purposes; then Company B is both a Processor and a Joint Controller with A for the ‘disclosure’, of that data from under one hat to another; but a solo Controller for whatever it is they’re doing after that
For instance; Microsoft is a Processor for the content that business users put into Office 365, but they are also a Joint Controller with the organisations that use them, for ‘productivity analysis’ of O365 user activity; and when they track user activity data across multiple tenants and platforms for profiling and advertising, they are wearing a solo Controller hat.
In theory:
A -> “Hello B, here is some data, pls do X and Y with it so we can achieve Z” -> B=Processor
A -> “Hello B, [here is some data], pls do whatever you need to achieve Z for/with us” -> A+B=Joint Controllers
A -> “We need to get X done, and B needs to get Y done, let’s combine data/processing operations and do them alongside each other” A+B=Joint Controllers
A -> “Hello B, here is some data, off you go and do whatever you need to do with it; not our problem” = separate Controllers
In reality; what we’ve got at the moment is this:
A -> “here is B; an online platform that provide tools for us to do X and Y with this data in order to achieve Z, but we can only use these tools if we say that B can also do N and M with the personal data in whatever way they specify for reasons that they came up with themselves, which we have no influence over, but which they claim we must assume liability for, because they insist they are only a Processor.”
NOPE
There are very few pure Processors (ie; organisations who do NOT also process personal data which was only acquired as a result of having a Processor contract, for their own purposes and by their own means) out there in the wild, especially as it seems everyone wants to jump on board the analytics and machine learning bandwagon. All that juicy Big Data, full of insights waiting to be mined and put to use! Yummy!
The clue is in the name
A Controller has control. As in; authority over why personal data is processed, or the substantive points of how it is processed (there’s wiggle room in the tech/config area; like whether to use component A or B when both do the same sort of thing).
A Controller ‘instructs’ a Processor, who must adhere to the Controller’s instructions. As soon as the Processor ventures outside those instructions without getting permission to do so, they have made themselves into a Controller – and will likely be processing the data unlawfully.
‘Instructions’ is a fuzzy grey area that a lot of rogue Processors hide their secret Controller hats in. It goes like this:
C: “I need some processing done”
D: “We can do it for you if you agree to our terms, which include allowing us and our network of partners to mine the data for training machine learning systems, profiling users for targeted advertising, and devising ever more ingenious vendor lock-in strategies.”
C: “Can I negotiate these terms to restrict what you are allowed to do with the data, or exclude some sets from your partners’ processing?”
D: “No.”
C: “Agh, but I need this done and I don’t have the skills or funds to do it in-house.”
D: “Take it or leave it. Oh, by the way, you’re still the Controller for allowing us to do all those other things with the personal data you’re bringing us. You have to get consent or whatever”
C: “Er, ok, can I see the details of your DPIA?”
D: “No. Commercial confidentiality and all that. It’s proprietary information.”
C: “So…..you want me to accept liability for the stuff you and others are doing which benefits you; but which I’m not allowed to know the details of? And it’s my responsibility to be transparent with the data subjects about the things you refuse to explain to me?”
D: “Take it or leave it”
C: “What if I take my business elsewhere?”
D: “LOL, good luck finding anyone who’ll agree to your terms. Hope your wallet is feeling nice and full. Signed, Just A Processor, haha”
C’s control is limited to deciding whether to accept D’s terms, or not accept them. That’s control over the supply chain, not control over the processing of personal data (subtle yet profound distinction). It seems to me, and many other data protection nerds, that there should really be more to ‘instructions’ than merely nodding along to immutable conditions which are set independently and unilaterally by the supplier. However, this has yet to be tested in a courtroom, as far as I’m aware.
The Definite Article
The idea of Controller and Processor being fixed, mutually-exclusive binary positions in regard to all of the processing, or all of the data that bounces between them; is common, but incorrect.
In the scenario illustrated by the previous section; despite what the paperwork says, A is not ‘The Controller’, C is ‘A Controller’ (1 of n). D is a Processor, but also a Controller, and if D’s ‘partners’ are acting independently around processing the data that C makes available to them; they are Controllers as well. This means that the service contract should address the liabilities, boundaries and lines of accountability for each set of relationships, rather than making generic but vague statements about what Controllers and Processors generally do. There’s really not much point saying “to the extent that Party D is a Processor”, then not actually describing what that extent looks like – and yet, nearly every set of Ts and Cs or ‘Data Processing Agreement’, or ‘Data Sharing Contract’s I see every week does it this way.
Maybe this isn’t all just a grand conspiracy to exploit personal data, but a genuine lack of understanding.
With that in mind, I have designed this rather tongue-in-cheek flow diagram (attached) for self-designated Processors to help them assess whether their claims stand up to the test of reality.
(NB: Not legal advice, no substitute for scrutinising contract terms, not guaranteed to be 100% applicable or accurate in all cases. You’re welcome to re-use it with credit to me, for non-commercial purposes)