Locations
Closing data-related deals seemed so much simpler pre-GDPR, didn’t it? Remember the days when every enterprise customer was a controller and every vendor was a processor. Of course, in reality, not every vendor was a processor (controllership and processorship is a question of fact, you know!) - but, still, this was the basis upon which the great majority of data contracts were concluded.
Now, post-GDPR, things are changing somewhat. Many of those vendors that previously called themselves processors are now calling themselves controllers - or perhaps their customers, having become a little more savvy after emerging from GDPR-readiness programs, are telling those vendors that they are, in fact, controllers.
What’s brought about this change? There are a few reasons, but to understand them you first have to step back a little into European data protection history.
Horrible histories: The popular data processor
Historically, many vendors positioned themselves as processors because, as every European privacy professional knows, processors had no direct statutory liability under the old Data Protection Directive regime. This meant they had a direct incentive to avoid being a data controller, and so many would either try to avoid controller-like activities or would characterise themselves as processors in their contracts (what I would call “square peg in a round hole” contracting). By calling themselves a processor, and their customer the controller, they sought to pass liability risk over to their customers.
You might think customers would object, but many - the majority - didn’t. Partly because many customer procurement teams had been trained, wrongly, to believe that the word “vendor” was synonymous with “processor” (and so insisted on deals that every vendor MUST be a processor), and partly out of a misplaced fear that vendors who were controllers could run wild and do whatever they liked with their customers’ data (they couldn’t - the law doesn’t allow it, for one thing).
The problem for vendors was that by “agreeing” to be a processor they accepted strict limitations on what they could do with the data they received - namely, that they would use it only as their customer “instructed”, leaving no opportunity for autonomous data innovation. However, in the early days of the Directive - and before the seemingly unstoppable advent of ad tech, cloud and machine learning - this seemed a relatively small price to pay. Yes, vendors ran analytics on their customers’ data, and that might seem like a controller activity, but most worked around this by seeking some kind of customer authorisation (read: instruction) to do so in their contracts, keeping their feet in the processor camp.
Vendors re-evaluate their processor strategy
This brings me back to the original question: why has this changed with the GDPR?
The first reason concerns the scope of liability: under GDPR, processors now attract direct statutory liability for breaches, just like their controller cousins. While it’s true that the majority of things a processor can screw up fall into the “2% fine bucket”, when you start talking numbers that large, the difference in risk terms between a 2% fine or a 4% fine starts to feel immaterial - kind of like that argument you used to have with friends when you were kid about whether 2x infinity was bigger than infinity. Hence a key incentive for vendors to want to be processors was lost.
The next reason concerns the GDPR’s mandatory terms for data processor agreements. Under GDPR, data processing agreements between controllers and processors have to include a number of mandatory data protection terms, all set out in Article 28(3). Put bluntly, many of these are not terms that many vendors want to accept. Controls on the vendor’s ability to subcontract? No thanks! Audit rights? You must be kidding! By contrast, the terms that processors had to accept under the prior Directive - namely, act on instructions and keep it secure - were things that vendors would have done as a matter of course anyway.
Are you keeping track? After removing the processor liability incentive, the GDPR then threw in prescriptive, mandatory data protection terms for processors to boot. Controllers, by contrast, have no mandatory terms explicitly imposed on them by the GDPR (with the exception of some minimal terms for joint controller arrangements); the thinking behind this presumably being that controllers are already fully subject to the GDPR so any contractual terms would be largely redundant - but from a contracting standpoint, controllership looks increasingly attractive (less contractual risk and fewer terms to negotiate).
This brings us on to the third, and most important, reason: data innovation. How many companies nowadays have a “data strategy” or call themselves a “data first company”. Using sophisticated analytics, machine learning and AI, vendors are increasingly slicing and dicing their customers’ data to do new and clever things, in order to continually evolve their products and identify new services to sell. However, the level of data processing autonomy involved in these activities falls outside of the scope of a processor role; simply put, they are not activities “instructed” by the customer. For this reason, many vendors are examining the restrictions a processor role would place on their ability to innovate and concluding that a processor suit just won’t fit after all.
Looking forward to the future
With the arrival of the GDPR, many vendors have seen their liability increased, their contractual terms become more onerous, and their processor roles increasingly frustrate their data ambitions. Processor incentives have been gradually eroded to the point that many vendors are reconsidering their roles and instead contracting, and behaving, as controllers. Consider, as just one example, how many ad tech companies that formerly called themselves processors now call themselves controllers.
That’s not the end of the story though, because there are still considerable processor incentives: most significantly that many customers still think of their vendors as processors, placing huge commercial pressure on vendors to “concede” processor positions in order to avoid deal friction. Further, transparency obligations placed on controllers are difficult for vendors to fulfil, given that they typically will not have direct relationships with the end data subjects.
Despite that, there has been a notable shift in vendors seeking to become controllers, and that shift reflects the fact that the boundaries between controllers and processors have become (even more) blurred over time. It seems reasonable to predict that even more vendors will review their controller / processor strategies in future, and perhaps switch camps.
This unintended and unforeseen consequence of the GDPR combined, more broadly, with continuing vendor data innovation, inevitably raises the question of whether the binary universe of controllers and processors still has any place in today's sophisticated data processing world. But that, dear readers, is a discussion for another day...