Data controllers, data processors, please hold the frame!

“Look, spaghetti arms. This is my dance space. This is your dance space. I don't go into yours, you don't go into mine. You gotta hold the frame. Frame!” Johnny Castle says in the  ‘80s cult movie Dirty Dancing as he begins teaching Baby to dance.

I never learnt to dance, but yes, I suppose it is a matter of coordination while maintaining the right posture and respecting the other’s dance space, that is, holding the frame. The same principle extends beyond dance: it can be applied in less romantic spheres, in countless contexts where collaboration and a clear understanding of each other's tasks is the key to achieve a common goal, while minimizing time loss and avoiding misunderstandings. For instance, in the context of business and project management, where coordination between stakeholders is crucial to avoid confusion in the execution of activities and to effectively achieve the goal. This is, I guess, why tools like the well-known RACI Matrix have been conceived for: to provide people involved in the same project with a clear idea of the frame in which they’re supposed to act. 

The processing of personal data shares many similarities with projects that require coordination between involved parties, particularly between controllers and processors, whose relationship, as it is well known, takes shape in the fact that the former are responsible for defining the purposes and means of processing, while the latter act on their behalf. This is the condensed version. 

However, there's a lot more to clarify in the space between the two dancers. In its Guidelines 07/2020 on the concepts of controller and processor in the GDPR the European Data Protection Board (EDPB) writes that “[...] the concepts of controller [...] and processor are functional concepts in that they aim to allocate responsibilities according to the actual roles of the parties”. So the two roles are associated with a set of activities or tasks, and even if those are clearly defined by the GDPR, the practical allocation of responsibilities is sometimes dim. 

Clarifying dance spaces

First things first: Art. 5 of the GDPR says that “the controller shall be responsible for, and be able to demonstrate compliance with”, principles relating to processing of personal data, that is, lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. 

In order for processing to be lawful, personal data should be processed on the ground of a legitimate basis that could be the necessity for compliance with the legal obligation to which the controller is subject or the performance of a contract to which the data subject is party, as well as the consent of the data subject concerned or some other, like the legitimate interest. The lawfulness assessment is up to the controller,  who ensures its respect not only, as obvious, towards the data subject but also to the data processor it engages. 

Any processing of personal data should be fair as well as lawful. That means that it should be transparent to those data subjects whose personal data are collected, used, consulted or otherwise processed. Transparency is mainly achieved through the privacy notice meant to provide subjects with all the relevant information related to the specific processing, including the legal basis and the purpose, which should be well defined, explicit and specific, as it can certainly not be unlimited. Indeed, the opposite. 

The same goes for data that should be collected consistently with the purpose - are you sure you need to know the name of my cat? - and cannot be stored indefinitely, but unless there are valid reasons, must be erased as soon as the purpose of the processing is achieved. It is (mainly) a controller responsibility also to assure that data are accurate and adequately protected. 

Can a processor assist a controller in achieving these objectives? Yes, at least some of them. It can certainly contribute to the secure processing of data, working on the actual implementation of the security framework and using its technical expertise to suggest the most adequate security measures to the controller, who is the ultimate supervisor. More than that, it shares this responsibility with the controller, in its respective (delegated) area of activity (Art. 32 GDPR). After all, the controller has the duty to use “only processors providing sufficient guarantees to implement appropriate technical and organizational measures” (Art. 28 GDPR), but it’s up to the processor to show its ability and its security and organizational posture (Spaghetti arms!), also ensuring the controller will be kept timely informed if something goes wrong, i.e. in case of a data breach (Art. 33(2) GDPR).

When choosing a processor, it is very likely that the controller could also take into account to what extent the processor’s solutions will help it in - for instance - keeping data accuracy, in pursuing transparency towards the data subjects and in implementing storage and access limitations, in other words in achieving its goal to implement the processing  with Privacy in mind by default and by design (Art. 25 GDPR). That’s why, although it is not formally responsible and accountable for this aspect, the processor is encouraged to take Privacy by Design and by Default into account when developing and designing products, services and applications, so as to enable the controller to fulfill its data protection obligations (Recital 78 GDPR). In any case, the processor shall (and shall be able to) implement the Privacy-consistent design plan according to the controller’s requirements and its instructions (also ensuring its employees will do so). 

Similarly, the processor should be able to assist the controller when it is obliged to carry out a DPIA (Arts. 35, 28 & Recital 95 GDPR), or when it is unfortunately facing a data breach, or when it decides for some reason to transfer data abroad (outside the EU, for example), or when it has to respond to a data subject’s request (Arts. 15-21 GDPR), but even if it were willing to do so, none of these things can and has to be done by a processor alone, including determining the purposes, the actual means and the legal basis of the processing, the scope of the personal data involved or the categories of data subjects, as well as writing the privacy notice or obtaining consent in the right way. 

On the other hand, the responsibility for some other tasks lies solely with the processor. That’s the case, for instance, when a processor would take the initiative to engage another processor for carrying out specific processing activities on behalf of the controller: selecting the right additional partner - the one that provides sufficient guarantees to implement appropriate security measures, as it already does - is up to the processor, as well as binding the newcomer to the same data protection obligations that it has agreed with the controller, as long as the latter has provided its authorization to do so, of course. However, remember that notwithstanding any controller's authorization, the processor still remains both accountable and responsible (i.e. fully liable) for the performance of the other processor's obligations. 

One more thing: all this applies provided that a processor is actually a processor. A  controller is not that fluid, as it is and will remain the controller, exactly like the unforgettable Patrick Swayze, forever Johnny in our hearts. And, just like him, the controller can also be an amazing solo performer. In any case, before starting, better make sure that the processor does indeed process personal data, otherwise, there will be no need to sign a Data Processing Agreement (DPA). Maybe in the next round, who knows…

By the way, after a while, Baby learns to dance and when John, who is now in love, gets too close to her, it's she who reminds him, “This is my dance space, that's yours… 

Let's cha-cha!”

Can the relationship between controllers and processors be framed using a RACI matrix?

Well, we think an attempt is worthwhile. The RACI Matrix is a tool that provides a concise yet comprehensive and detailed overview of the scope of analysis. It is easy to understand and very common in the IT context - Hey… After all, at Liferay, we have a nerdy soul! - In addition, it closely resembles legal jargon: for those who are used to reading the GDPR, the term 'accountable' is likely to be a familiar one.

In our RACI Matrix version, which you may find below, we have applied a couple of slight modifications to the original notation: 

1. Sometimes the two types of responsibilities I and C are between brackets - (I) and (C) - and this means that the controller or the processor may be informed or consulted, but it’s not mandatory to do so;
2. According to the BABOK ©IIBA, only one stakeholder receives the assignment of being accountable for a specific task or action. However, in our context, we think there’s an exception to this rule. But we won't tell you in which case, you'll have to discover it!
3. Finally, we added an additional column to the original matrix to specify how Liferay, as processor, performs the activities for which it is accountable and responsible. Please remember that Liferay is not a processor when it provides Liferay DXP, or simply Liferay Self-Hosted (i.e. the on-premise version) to its customer as it doesn’t process any personal data on behalf of the controller. So, the specifications below apply only to cases where Liferay provides cloud-based solutions, namely Liferay SaaS (previously known as  Liferay Experience Cloud, or just LXC), Liferay PaaS (previously known as Liferay Experience Cloud Self-Managed, or just LXC-SM),  Liferay Analytics Cloud (AC), Managed Services and certain Professional Services assignments, to the extent customer provides Liferay with access to its personal data. 

That’s all! And remember… “The Matrix is everywhere” (but that’s another movie).

1. Ardolino, Emile. Dirty Dancing. Vestron Pictures, 1987

2. According to the BABOK Guide - A Guide to the Business Analysis Body of Knowledge by International Institute of Business Analysis (IIBA), v. 3, 2015, “RACI stands for the four types of responsibility that a stakeholder may hold on the initiative: Responsible, Accountable, Consulted and Informed. 
Responsible (R): the person who will be performing the work on the task. 
Accountable (A): the person who is ultimately held accountable for successful completion of the task and is the decision maker. Only one stakeholder receives this assignment.
Consulted (C): the stakeholder or stakeholder group who will be asked to provide an opinion or information about the task. [...]
Informed (I): a stakeholder or stakeholder group that is kept up to date on the task and notified of its outcome. Informed is different from Consulted as with Informed the communication is one-direction (business analyst to stakeholder) and with Consulted the communication is two-way.”

3. EDPB, Guidelines 07/2020 on the concepts of controller and processor in the GDPR, v. 2.1. (Adopted on 07 July 2021), p. 3. 

4. Ardolino, E. (Footnote nr.1)

5. Wachowski, Lana, and Lilly Wachowski. The Matrix. Warner Bros., 1999.