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:
- 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;
- 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!
- 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).
| Activity | Controller | Processor | Liferay as Data Processor |
|---|---|---|---|
| Comply with data protection principles under art. 5 GDPR | AR | I(C) |
As the party in control of Personal Data, Customer is at all times responsible for assessing if the contractual assurances offered by Liferay are appropriate for the Personal Data Customer intends to upload to the Cloud Services in accordance with the Data Protection Laws (see Section 11 of Liferay Appendix 4 - Liferay DXP Cloud Services at https://www.liferay.com/legal) Liferay, in turn and for its part, shall comply with all applicable Data Protection Laws in the Processing of Customer Personal Data and follow the Customer’s instructions according to our DPA. |
Write and provide privacy notices |
AR | (C)(I) |
Liferay solutions offer many functionalities that may help our Customers publish their privacy notice in an easy and effective way (See, for instance: |
Keep records of processing operations (Art. 30(1) GDPR) |
AR | (C) |
The Customer may find some useful information here: https://www.liferay.com/legal/cloud-services-data or otherwise ask Liferay to make available the further information we may have for keeping record of the processing we carry out on its behalf |
Keep records of processing operations (Art. 30(2) GDPR) |
(C) |
AR | We do maintain and keep updated the Record of processing activities according to Art. 30(2) GDPR and shall make it available to the Customer (upon written request) according to Section 11 of our DPA |
Ensure the overall security of processing (Art. 32 GDPR) |
AR | IC |
|
Ensure the security of the entrusted processing activities carried out on behalf of the Data Controller, within the agreed-upon scope, its premises and the boundaries of the technical and organizational deployed means (Art. 32 GDPR) |
IC |
AR |
The list of the Technical and Organizational Measures (TOM) we adopt in the provision of our services is available here: https://www.liferay.com/legal/cloud-services-data Furthermore, our certification program includes: https://www.liferay.com/resources/product-info/Liferay+DXP+Cloud+Data+Security+and+Protection |
Choose an appropriate data processor (as the controller has the duty to use “only processors providing sufficient guarantees to implement appropriate technical and organizational measures”, Art. 28 GDPR) |
AR | C |
Since Liferay provides standardized services, it outlines the implemented Technical and Organizational Measures (TOM) towards its customers, who have a detailed understanding of the envisaged processing activity, and are therefore in a much better position to assess if the outlined TOM are appropriate for the data processing as envisaged by the controller. |
Obtain the authorisation of the controller before engaging a new sub-processor (and give the controller a possibility to object) |
CI | AR | The list of Liferay’s sub-processors is available here: https://www.liferay.com/legal/cloud-services-data Liferay shall give Customer prior notice of the appointment of any new Subprocessor (see Section 6 of our DPA for more information) |
Detailing in a binding contract the controller-processor relationship (Art. 28 GDPR) * According to the BABOK - ©IIBA, only one stakeholder receives the assignment of being accountable, but for this specific activity we deem an exception to the rule must be made as both parties are accountable and responsible for signing the DPA. |
A*RCI |
A*RCI |
Please find our DPA template here: https://www.liferay.com/legal |
Provide the process with documented instructions on how to process personal data on its behalf (Art. 28 GDPR) |
AR | I |
|
Process the personal data only on documented instructions from the controller (Art. 28 GDPR) |
CI |
AR |
Liferay and Liferay Affiliate do not Process Customer Personal Data other than on the relevant Customer Group Memberʼs documented instructions (unless required by Law), except in order to generate anonymous aggregated statistics Liferay uses for its own purposes, including price calculation and improvement of its products and services. For more information see Section 3 of our DPA in conjunction with Section 12 of the Appendix 4 (for Liferay PaaS) and Section 4.14 of the TOS (for Liferay Analytics Cloud). |
Ensure that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28 GDPR) |
I | AR |
Liferay’s policies guarantee the obligation of confidentiality of employees in the performance of their duties. All employees are subject to confidentiality obligations included in their employment or contractor agreements, as applicable. |
Delete or return - at the choice of the controller - all the personal data to the controller after the end of the provision of services relating to processing, and delete existing copies (Art. 28 GPR) |
CI |
AR | Customers may request access to Liferay service for purposes of retrieval of customer data within 14 days upon expiration or termination of customer's subscription. Upon request, Liferay will provide the customer with access to the services for these purposes for a term of 14 days following receipt of the request. Liferay will irretrievably erase customer’s data from the systems 30 days after the expiration/termination of customer’s subscription. For more information see Section 10 of our DPA |
Notify personal data breaches to the relevant EEA data protection authority (Art. 33 GDPR) and to individuals (Art. 34 GDPR), where applicable |
AR | C(I) |
|
Notify personal data breaches to the data controller (Art. 33(2)) |
I |
AR | Liferay has a Data Incident Response Policy in place and provides for a contractual commitment to notify customers in any event of a data breach without undue delay. For more information see Section 8 of our DPA |
Observe data protection by design & by default principles (Art. 25 and Recital 78 GDPR) |
AR | RCI | We do our best to design our products, so that the Customer can process personal data according to the principles of Privacy by Design and by Default. You may find some related information here: https://www.liferay.com/gdpr |
Carry out data protection impact assessments (Art. 35 GDPR) and consult with Supervising Authorities (Art. 36 GDPR) when necessary |
AR |
(C)(I) |
|
Assist the controller, where necessary and upon request, in ensuring compliance with the obligations deriving from the carrying out of data protection impact assessments and from prior consultation of the supervisory authority (Recital 95 and Art. 28 GDPR) |
CI |
AR | Liferay shall provide reasonable assistance to the Customer with any data protection impact assessments (DPIA), and prior consultations with Supervising Authorities, which Customer reasonably considers to be required, taking into account the nature of the processing and information available to it. For more information see Section 9 of our DPA |
Comply with the data protection obligations on international transfers of personal data (Chapter V) |
AR |
(C)(I) |
|
Ensure that international transfers are authorized by the controller and comply with the GDPR (Chapter V) |
CI |
AR |
For purposes of onward transfers to third countries, Liferay implements Standard Contractual Clauses as outlined in the DPA. In addition, Liferay provides a list of its sub-processors, including their location, applicable transfer mechanism and the outcome of our assessment of the jurisdiction for data transfers in third countries at, to support customers’ Transfer Impact Assessment(s): https://www.liferay.com/legal/cloud-services-data |
Make available to the controller all information necessary to demonstrate its compliance and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller (Art. 28 GDPR) |
IC |
AR |
Liferay and each Liferay Affiliate shall make available to a Customer Group Member, upon written request, all information necessary to demonstrate compliance and give access, upon reasonable notice, to their premises for purposes of audits and inspections. For more information see Section 11 of our DPA. |
Respond to data subject’s requests (Arts. 15-21 GDPR) |
AR | (C)(I) |
|
Assist the controller by appropriate technical and organizational measures - insofar as this is possible and taking into account the nature of the processing - for the fulfillment of the controller's obligation to respond to data subject’s request (Art. 28 GDPR) |
CI |
AR |
Liferay shall assist Customer by implementing appropriate technical and organizational measures, insofar as this is possible and taking into account the nature of processing, in responding to requests from Data Subjects according to Section 7 of our DPA. |
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.