Data sharing and processing agreements: the details you might be missing that will put you at risk

Written by

and

December 20, 2022

Since GDPR was about to come into force, organisations have been considering the best ways to jump from a vague and generic data protection clause that was included by default in services agreements to a longer set of Article 28 GDPR controller-processor clauses and data sharing protocols. Since organisations started using controllers and processors modules to implement Article 46.2 GDPR Standard Contractual Clauses as an approved mechanism to transfer personal data to international organisations or third countries, they now seem to be more familiarised with long and detailed data protection arrangements.

So, what is further needed to ensure the agreements are compliant with GDPR? This article covers the position taken by the European Data Protection Board ("EDPB") and the UK Information Commissioner's Office ("ICO") as supported by relevant cases ruled by the Court of Justice of the European Union ("CJEU") concerning what needs to be included in a contract to really ensure compliance and how to avoid unnecessary risks.

The importance of agreeing on “the how”‍

This is something that I usually advise on and that has become even more relevant since regulators started stressing the importance of getting data processing arrangements right and to the case. The key to ensuring that a data protection agreement is effective and compliant is discussing and agreeing on the "how". This has been stressed in particular in a controller-processor relationship but clearly applies to joint controller contexts and, as we saw in the judgement of the CJEU in the Schrems II case, it is relevant to have these discussions on a case-by-case basis.

Controller-processor arrangements

Even though we have seen some progress in attention to detail thanks to the Schrems II case, I still see a tendency to break down data processing agreements into two main (broad) sections, namely:

a clause in which the generic provisions consisting of the mandatory content set out in Article 28 (3) and (4) of the GDPR are copied in with a major or lower level of detail, but mainly generic and applicable to every possible situation; and
a schedule in which details of the subject-matter, nature, purpose and duration of the purpose are broadly described along with the type of personal data, categories of data subjects and obligations and rights of the data controllers.

However, this does not seem to be enough. The European Data Protection Board expressly stated "… a contract under Article 28 GDPR should further stipulate and clarify how the provisions of Article 28 (3) and (4) will be fulfilled" [1]. The EDPB considered this issue when analysing a set of Article 28 GDPR controller-processor Standard Contractual Clauses ("Article 28 Clauses") issued by the Danish Data Protection Agency in 2020. The approved version of these Article 28 Clauses is available on the EDPB website [2] and it is a recommended option to ensure all necessary details are included, along with the version approved by the European Commission.

Following the details incorporated into the Article 28 Clauses and in line with the ICO's guidance on controllers and processors, the relevant points that your organisation should consider discussing in more detail can be summarised as follows:

The instructions given by the controller to be more specific and detailed - if not in the agreement then by sending regular updates on what the instruction is (an email would suffice and ideally this would be made clear in the agreement).
Better evaluation of risks to rights and freedoms of individuals, which means that the controller must provide information to the processor for the processor to be able to understand such risks and take appropriate measures to mitigate them.
The processor should inform the controller of the technical and organisational measures implemented in order to protect the data processed under the controllers' instructions so that the parties can agree on further measures if the controller finds that additional measures should be implemented.
List of sub-processors (even if a general authorisation is the alternative chosen by the controller) and how information on additional sub-processors will be provided to the controller.
The data processor to include a third-party beneficiary clause in its agreements with sub-processors so that the data controller will be entitled to claim against the sub-processor if appropriate (for instance if the data processor becomes insolvent).
Specific instructions concerning international transfers of data by the data processor and confirmation of processing locations (e.g. if the parties agree that the data is to be processed in specific locations only).
How and when the data processor will notify the controller in case of a data breach and what information should be provided.
How the data processor will assist the data controller in fulfilling the relevant obligations;
How the data controller will carry out audits or inspections (e.g. by requesting the data processor to instruct a third party and to share the report with the data controller or for the data controller to organise and carry out the audit or inspection).
Whether the processor is obliged under law to keep the personal data for longer than the processing activity instructed - and if so, under which law.
Agreeing on contact points for communications between the parties.

What could help your organisation with the incorporation of these details?

There is no doubt that including an appropriate level of detail is a challenge. It is time-consuming, requires compromise between the parties, and although this is to be done with a case-by-case, risk-based approach, the following may be of some help:

Review the data protection and information security policies in your organisation. If you are a controller, they may help you assess how the assistance provided by the processor fits into the procedures in place. For example, the security measures approved as part of your organisation's information security policies can be considered for the processor to implement or confirm an alignment to the level of security and confidentiality set out in the controller's policies. Equally, in order to set out how the processor will assist the controller if a data subject exercises their rights, considering the internal steps that your organisation takes according to the policies may help assess what to agree with the data processor in that respect. If you are a processor, reviewing your policies will help to confirm how your organisation will be able to assist the controller.
Ensure fluent and effective communications: while providing one email address might be enough information to be incorporated into the agreement, it is important to ensure that communications are received on time by someone who is able to take immediate action if necessary and in particular when it concerns data breaches. A simple step such as internally setting the email address to be redirected to at least two to four relevant staff or board members ensures that communication is not missed due to, for example, vacation periods or illness.
Take time to discuss and confirm what data processing activities are carried out by the data processor so both parties will be better able to include details such as defined and clear instructions as well as types of personal data and categories of data subjects involved.

In the UK, this is also in line with the ICO's recommendation of these contracts being as clear as possible about how the processor will help the controller to meet its obligations. Moreover, since the EDPB approved the Danish Article 28 Clauses, the ICO expressly mentioned this tool in its controllers-processors guidance [3] in order to encourage organisations to use them as a valid mechanism that ensures compliance with Article 28 GDPR.

Joint controllers' arrangements

Identifying joint controller scenarios and having in place the Article 26 arrangements has become relevant given the broad interpretation provided to this term by the CJEU in cases [4] such as the Jehovah's Witness case (Case C-25/17) (which dealt with personal data collected by Jehovah's Witnesses in the course of door to door preaching and the joint controller role of the Jehovah's Witnesses Community) or the Fashion ID case (case C-210/16) in which the CJEU considered the position of a fan page used in Facebook.

The criteria applied in these and other cases of related nature were summarised by the EDPS in its "EDPS guidelines on the concept of controller, processor and joint controllership under Regulation (EU) 2018/1725" [5], which was directed to European Union Institutions and bodies ("EUIs") under the data protection regulation that applies to them but it is also useful for entities subject to GDPR due to the similarities and the case law considered in the document.

According to the EDPS guidelines, the decisive elements for joint controllership are:

Each controller has a chance to determine the purposes and the essential elements of the means of a processing operation.
A general level of complementarity and unity of purpose could already trigger a situation of joint controllership if the purposes and essential elements of the means are jointly determined.

‍

A relevant element to always bear in mind is that a joint controller does not need to access nor otherwise process personal data to be considered a joint controller. In the words of the European Data Protection Supervisor ("EDPS"), a controller will be a joint controller if it "determines the purposes and means of the processing, has influence on the processing by causing the processing of the personal data to start (and being able to make it stop), or receives the anonymous statistics based on personal data collected and processed by another entity."

Examples include contexts in which different bodies are allocated with different tasks that a priori seem to be developed independently. However, considered joint controllers since "neither of the parties involved in the processing operations would be able to achieve the purpose independently" [6] and if in the context, both parties jointly develop the essential means of the processing operations (for example: the type of data and data subjects required to achieve the purpose or the parties allowed to access the data).

The ICO also included a checklist in its GDPR guidance in order to help organisations with this task, according to which the joint controller elements stressed whether the parties involved have a common objective with others regarding the processing, process data for the same purpose, using the same dataset, have common information management rules, or have designed the process together.

When in doubt, the recommendation is to include the Article 26 arrangements in an agreement and to incorporate a caveat for it to apply only if a joint-controller data processing scenario effectively happens.

What should joint controller arrangements look like?

Article 26.2 GDPR states that the joint controller arrangements must reflect "the respective roles and relationships of the joint controllers vis-à-vis the data subjects". A clear allocation of responsibilities is required according to Recital 79 of the Regulation. The key here is to allocate responsibilities in proportion to the level of involvement and the type of processing activities that each joint controller carries out. For example:

In a context in which an organisation does not directly process personal data or has contact with individuals at all and it is therefore the other organisation that collects and processes the personal data as well as directly liaise with individuals, it will be reasonable to agree that the latter will be responsible for ensuring that all processing is carried out in compliance with the data protection legislation and that the joint controller will be responsible for informing individuals as required by law and in particular by Article 26 GDPR (informing of the essence of the joint controller arrangements which, in practice, may consist of an inclusion in their privacy notice in which it is stated that this activity is carried out in partnership with the other joint controller and that the one providing the privacy notice is the main point of contact and responsible for their processing activities as well as - ideally - including clear information concerning data subjects' rights concerning the joint controllers), or
When two organisations are processing different sets of personal data in a different manner and for different purposes but in order to achieve a joint, higher objective which none of them could achieve at without the acticities of the other, Article 26 clause may be drafted to clarify precisely which task is carried out by each joint controller so the allocation of responsibilities is clear.

When it is not clear whether or not the parties might be considered joint controllers, I would recommend using, at least, a more generic type of clause by default. This will help to clarify that despite having a broad objective in common, the processing activities are fully independent and so each party will be responsible for ensuring compliance with the data processing carried out by each party and to be the main point of contact for the individuals each party deals with. Note that when doing so, it is also relevant to align privacy notices accordingly.

Otherwise, when a joint controller context is clear and in particular in cases of complex multi-parties projects, my recommendation (in line with the approach and guidance seen concerning controller-processors clauses) is to include details on how each party will fulfil their responsibilities and how each party will assist the other. In my opinion, a joint controller detailed clause would - at minimum - looklike the following example:

EXAMPLE OF JOINT CONTROLLER CLAUSE

The parties acknowledge that they make joint decisions over the processing of the personal data set out in this clause:

‍

1. In order to ensure compliance with the Data Protection Legislation [this term should be defined in the agreement], the parties agree on the following allocation of responsibilities:

a. ‍The [company name] is responsible for: [points i to vi to be allocated to one party if appropriate or distributed between the parties]

i. Collecting the joint personal data [include steps agreed]

ii. Informing joint data subjects as obliged under the Data Protection Legislation [include steps agreed]

iii. Implementing appropriate measures to protect the joint personal data [include measures agreed]

iv. Being the main contact point for data subjects

v. Being the main contact point for the ICO

vi. Informing individuals about the essential elements agreed under this clause

b. The [company name] is responsible for:

i. Collecting the joint personal data [include steps agreed]

ii. Informing joint data subjects as obliged under the Data Protection Legislation [include steps agreed]

iii. Implementing appropriate measures to protect the joint personal data [include measures agreed]

iv. Being the main contact point for data subjects

v. Being the main contact point for the ICO

vi. Informing individuals for the essential elements agreed under this clause

2. Regarding the remaining obligations under the Data Protection Legislation, each party shall take steps to ensure compliance in accordance with the level of involvement in the processing of the Joint Personal Data.

3. Unless agreed to otherwise in this clause, the parties agree that in order to deal with issues concerning the processing of personal data, [company name] shall send any communications to [company name] by email to [email] and [company name] shall communicate with [company name] by email to [email].

4. The parties shall cooperate in the undertaking of Data Protection Impact Assessments where this is mandatory in relation to the joint processing [include steps agreed].

5. A party will not engage a data processor for the processing of joint personal data unless this is jointly agreed [include steps agreed].

6. A party shall notify the other party immediately (in any event within 24 hours) if it receives any other request, complaint or communication relating to either party's joint obligations under the Data Protection Legislation; receives any communication from the Information Commissioner or any other regulatory authority in connection with joint personal data processed according to this clause; receives a request from any third party for disclosure of personal data where compliance with such request is required or purported to be required by applicable laws; or becomes aware of a data breach, in which case, in addition, it will immediately take internal steps in order to mitigate the breach [include immediate steps agreed].

7. The Parties agree on the following procedures:

a. To handle joint data subjects' rights requests: [include steps agreed]

b. To handle data breaches: [include steps agreed]

c. To handle complaints: [include steps agreed]

d. To deal with ICO communications: [include steps agreed]

8. Each party shall, to the extent it is obliged under the Data Protection Legislation, maintain complete and accurate records and information to demonstrate its compliance with this clause.

The details included in a joint controller clause are not only relevant to ensure compliance with the formal requirements set out in Article 26 GDPR but also facilitate criteria to calculate a percentage of liabilities placed on each party. So if a data subject claims against the joint controller that had a minor level of involvement (or was not involved at all) in the processing activity that caused the damage, it will be easier for this joint controller to prove the extent to which it is entitled to claim back from the other joint controller.

In conclusion, whichever data processing or sharing scenario you are dealing with, it is essential that you clarify data protection roles and that you invest time in considering each clause, agree on the “how” and allocate clear responsibilities.

‍