GDPR Fun Fact #17: He Who Shall Not Be Named

There is a scary beast under every privacy attorney's bed. We try not even to look vaguely into its direction, let alone poke it, lest we wake it up. Please meet: Joint Controllership.

No organisation is fond of the notion of tying its fortunes – and liabilities – to the deeds and misdeeds of another. So understandably, in most cases where two organisations engage in a commercial relationship involving the processing of personal data by both of them, they will endeavour to disclaim any joint controllership under GDPR Article 26:

1. Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation (...).

2. The arrangement referred to in paragraph 1 shall duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects. (...)

In most cases, one organisation will be positioned as the data controller and the other as the data processor. Sometimes the roles can be interchanged for some parts of the processing operations. And in many other instances, parties will consider themselves and each other as independent data controllers acting each for their own purposes in their own remits. This is especially common in the area of employee benefits procured by an employer for their workforce and delivered by a third-party service provider.

For the rest, it is rare for two organisations to agree that anything they do outside of one executing the data processing instructions of the other constitutes joint controllership. Even where a commonality of purpose exists in the commercial relationship, it is customary to stipulate that each party acts as an independent controller, solely responsible for its own compliance with applicable data protection rules. One area where this practice is definitely prevalent is the provision of cybersecurity technology. But how defensible is that approach in reality?

Cybersecurity technology comes in many forms: It can be shipped in hardware appliances, licensed as on-prem software, provided as cloud offerings, delivered as managed services, or packaged in any and all hybrid combinations of these. Regardless of the deployment model though, as discussed in several previous articles of this series, a common requirement for the technology to remain effective in the face of ever changing threats is the uninterrupted reliance on the most recent threat intelligence and the permanent availability of the latest defense capabilities. Cybersecurity vendors acquire threat knowledge, distil it into threat intelligence, and derive and deploy the corresponding countermeasures on the job and on the fly, as an integral part of delivering their technology to their customers.

So what? Well, it can of course be argued that in the context of providing cybersecurity to its customers, the cybersecurity vendor is solely acting as a data processor to each of its customers when processing personal data in their respective environments, for the purpose of securing the networks and information of each customer independently.

Meanwhile, in the context of aggregating threat knowledge, deriving threat intelligence and developing countermeasures based on all the threats observed across its customer base and in the wider ecosystem, it can also be argued that the cybersecurity vendor acts as a distinct data controller, independent from each and all of its customers.

However, the reality is that there are way too many commonalities between the cybersecurity vendor and its customers to disclaim any notion of joint controllership with absolute certainty:

• What is the purpose of processing? It is cybersecurity, divided in two parts. For the customer, it means resisting cyberthreats. For the vendor, it means enabling the customer to resist cyberthreats. In practice though, these are two sides of the same coin, and one couldn't survive without the other.
• Who determines the purpose then? In a way, each customer does so for itself, and so does the vendor. Except that by electing to use the vendor's technology, each customer contributes to the vendor’s ability to keep that technology up-to-date over time, and each of them benefits from what all others have contributed. Most importantly also, the vendor would be a lot less effective (or maybe even completely ineffective) in fulfilling its purpose of keeping its technology current, weren’t it for the threat knowledge and insights it gleans from its installed base. In that sense, cybersecurity is not the isolated purpose of each organisation taken independently, but an overarching purpose shared among all of them. And at the very least in the context of each bilateral commercial relationship between the cybersecurity vendor and its customer, the customer’s ability to meet its cybersecurity needs and the vendor’s ability to fulfill its cybersecurity promise are intimately linked. The argument that these constitute two independent purposes of processing is tenuous at best.
• Ok but then what are the means of processing? Well, the means of processing are… the cybersecurity technology at play.
• Who determines those means? The commonly accepted approach is to consider that the customer decides for itself what technology to buy, how to deploy it, how to configure it, how to operate it, etc. Including, as the case may be, the decision to outsource part or all of the job to the cybersecurity vendor acting as a processor on the customer’s instructions. This legal construct sounds reasonable... until you start probing the hard facts of reality. Who really determines what processing operations (what data processing means) are actually involved in providing, say, a data loss prevention, an intrusion detection, a malware protection, a messaging security or an incident response capability? Obviously the cybersecurity vendor, whom the customer hires precisely for that expertise.

So I leave it up to everyone to think it through, and to find their own honest answer to this question: Given how cybersecurity technology works, where one business provides such technology to another, how likely is it that the purposes and the means of processing are actually determined – at least in part – jointly? What matters is not what the contract says, it is what happens in reality. And if a supervisory authority or a court were to find that the reality contradicts what the contract says, then the requirements of Article 26 would kick in, no matter how hard the parties have tried to contract them away. And this conundrum will only get worse as more AI gets thrown into the mix.

What a nice cliffhanger to end this series upon! Thanks to all for reading, and wishing everyone a lovely summer recess.