On the Concepts of Controller, Joint Controllers, and Processor

The European Data Protection Board (EDPB) issued guidance on the Concepts of Controller, Joint Controllers, and Processor following public consultation on 7 July 2021. The different concepts are important under the General Data Protection Regulation (GDPR) because the regulation assigns distinct roles and responsibilities based on an organisation’s classification. 

Wrangu’s Privacy Hub can help with your privacy and data protection concerns and assist your organization with GDPR.

Controller  

A controller can take the form of an individual such as a CEO or CPO or a group of individuals, but in practice is usually an organisation. The key aspect of a controller is determining the “purposes and means” of processing. This is the decision making over key elements of data processing that answers the questions of the why and how of the processing.  

A controller can be self-designated or arise out of the factual elements or circumstances. This includes the distinction between a controller and subsidiaries of the controlling corporation. While a specific person may be appointed to ensure compliance with data protection rules, they are serving on behalf of the organisation, which will ultimately be responsible in the case of violations. 

Where the “purposes and means” of the processing is determined is also crucial for determining an organisation’s “main establishment,” and the lead supervisory authority. 

The key terms the EDPB defined were what it means to determine the “purposes and means” of the data processing.  

“Determines”  

Control of processing relates to exercising decision-making power. This can arise in two ways, from legal provisions such as a contractual designation of controller or from an assessment of the factual situation. This means the role of controller does not stem from the nature of the entity but its concrete activities in determining the purposes and means of the processing.  

“Purposes and means” 

The EDPB cites unnamed dictionaries to define “purpose” as “an anticipated outcome that is intended or that guides your planned actions” and “means” as “how a result is obtained or an end is achieved.” Determining these factors is important to conform to the principles that data be collected for “specified, explicit and legitimate purposes.” This amounts to answering the questions of why processing takes place and how those objectives will be achieved.  

The controller must decide both the purposes and means. It cannot leave the goal defined without specifying the way to get there. This does not mean the processor has no leeway to make certain decisions. The EDPB delineated essential v. non-essential means. What is essential must be done by the controller. The “means” are closely linked to the purpose and the scope of the processing. For example, determining the type of personal data processed, for how long, and who has access to the data. Non-essential means concern more practical aspects of implementation like what type of software is used.  

Controller Obligations 

The controller is responsible for compliance with the GDPR, in particular the requirements under Articles 24 and 25. These include implementing and being able to demonstrate technical and organisational measures designed to effectuate the principles of the GDPR including data minimisation, purpose limitation, and storage limitation. This requires considering the nature scope, context, and purposes for the processing as well as the risks to the rights and freedoms of individuals.  

Additionally, the controller is obligated to keep Records of Processing Activities with the requirements of information to be kept listed under Article 30. Where processing may present a risk to the “rights and freedoms” of data subjects, a Data Protection Impact Assessment must be carried out according to Article 35. Controllers are also obligated to notify the supervisory authority within 72 hours of becoming aware of a data breach unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. In situations where there is a “high risk to the rights and freedoms” of individuals, the controller must also communicate the data breach to the data subject “without undue delay.” 

The GDPR explicitly includes the accountability principle (Art. 5(2)). This means the controller is responsible for compliance with the other principles set out in Article 5(1), and the controller must be able to demonstrate that compliance. While the accountability principle is directly addressed to the controller, there are obligations that apply to both controllers and processors and open both parties up to fines for noncompliance 

In the choice of a processor, the controller has the duty to use “only processors providing sufficient guarantees to implement appropriate technical and organisation measures.” The responsibility is placed on controllers to assess the sufficiency of a processor’s guarantees and capabilities. This assessment is like a DPIA (Data Protection Impact Assessments), often called a “vendor risk assessment,” and depends on a variety of factors including the nature, scope, and context of the processing as well as the risks to the rights and freedoms of natural persons (Recital 81). In assessing the guarantees of the processor, controllers should consider the processor’s expert knowledge, reliability, and available resources.  

Joint Controller 

The assessment of joint controllers also requires a determination over what organisation determines “the means and purposes” of the processing and should follow the above assessment for a single controller. Article 4(7) and provides that “where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.”  

The most important criterion for determining the existence of joint controllership is joint participation in determining the means and purposes of processing. Joint participation can arise from a common decision made by two or organisations or arise out of a converging decision where decisions complement each other. Case law from the Court of Justice of the European Union suggests that decisions converge “if they complement each other and are necessary for the processing to take place.” An important question to ask in determining convergence is “whether the processing would not be possible without both parties’ participation” for a particular processing activity. 

Jointly Determined Purpose(s) 

Joint controllers exist when the organisations involved process the data for the same, or common, purposes. Even when the purposes are not the same a joint controllership may exist if the purposes are closely linked. For example, in the case Fashion ID, the Court of Justice of the European Union (CJEU) clarified that a website operator and the provider of a social plug-in (FB like button) embedded on the website were joint controllers as the operations were in the economic interests of both parties. The website operator was able to increase the visibility of its products while Facebook acquired more data on browsing habits. 

However, the existence of joint goal is not the only situation where jointly determined purpose exists. See for example the case Wirtschaftsakademie. In this case the CJEU held that administrators of a Facebook fan page and Facebook were joint controllers as both parties were involved in determining the purposes and means of the processing of the associated personal data even when they were pursuing different interests. Facebook was able to optimize its system of advertisements while the administrator of the fan page obtained statistics to manage the promotion of its activity. 

Jointly Determined Means 

Joint controllership requires two or more entities exert influence over the means of the processing. It may be the case that one organisation provides the means of the processing and makes it available to the other organisation. Again, as an example is Wirtschaftsakademie where the administrator of a Facebook page used target audience and other tools provided by Facebook. 

The use of a common data processing system or infrastructure does not automatically qualify as a joint controllership. The relevant analysis must determine whether the processing could be carried out alone by one party without intervention from another. The shared use of data alone will not give rise to a joint controllership. 

Joint Controller Obligations 

Joint controllerships can be made up of two or more organisations. The joint controllers must determine their respective responsibilities to comply with the GDPR including how data subjects exercise their rights and the responsibility to provide information in Articles 13 and 14 (Art. 26). The distribution of responsibilities should also cover the legal basis for processing with each joint controller ensuring they have one. Other considerations include response and notification obligations in the case of a data breach, conducting data protection impact assessments, using processors, transferring data abroad, and communication with the supervisory authority. 

The legal form of the arrangement is not specified by the GDPR. To comply with the principles of transparency and accountability, the EDPB recommends such arrangements be formalised in a binding agreement reflecting the roles, responsibilities, and liability between controllers.  

Processor 

A processor is defined under Article 4(8) and processes personal data on behalf of the controller. There are two basic criteria for a processor. It exists separately from the controller and processes personal data on behalf of the controller.  
 

A processor can be a person, public authority, agency, or organisation that processes data in accordance with the controller’s instructions. These instructions generally take the form of a data processing addendum that may still leave discretion for the processor to determine certain aspects of the processing. The agreement must set out the “subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.” At the end of the contract, the processor is often obligated to delete and return all the personal data to the controller. The processor must also be able to demonstrate compliance with the GDPR to the Controller. 

When a processor goes beyond those instructions to determine its own “purposes and means” it is then considered a controller and may be subject to sanctions for beyond the controller’s instructions.  

Processors have a host of limitations on their processing activities and Article 28 lays out a processor’s responsibilities. These include implementing appropriate technical and organisational measures and limitations on engaging with further processors without prior approval from the controller. The obligation to process data only on the instructions of the controller has an exception if processing is required by Union or Member State law.  

Processor Obligations 

A new feature of the GDPR applies obligations to Processors. Processors must ensure the individual authorised to process the data has committed themselves to confidentiality (Art. 28(3)(b)), maintain a ROPA (Records of Processing Activities) (Art. 30(2)) and has a duty to assist the controller in ensuring compliance, for example, conducting a DPIA. In the case of a data breach, the processor has an obligation to notify the controller “without undue delay after becoming aware of it.”  

What to Include in the Controller/Processor Data Processing Agreement 

Any processing by a processor must be governed by a contract or other legal act in writing or electronic form (Art. 28(3) and (9)). The contractual requirements to be included are laid out in Article 28(3) and all elements must be covered. The standard contractual clauses (SCCs) may be used and provide helpful guidance. These SCCs are distinct from the SCCs used for data transfers under Article 46(2).  

The EDPB guidance notes that the processing agreement should not merely restate the provisions of the GDPR but should include “more specific, concrete information as to how the requirements will be met and which level of security is required for the personal data processing.” The processor is then limited to processing data pursuant to the documented instructions (Art. 28(3)(a)). When a processing processes data beyond the controller’s instructions this amounts to a determining the purposes and means of processing, the processor is in breach of its obligations, and will then be considered a controller. This includes data transfers to other divisions of the processor that may be in third countries. If the controller has not acceded to these transfers they are not allowed.  

The contract must state the processor ensures that anyone it allows to access personal data is committed to confidentiality. This may occur as a specific contractual agreement, or due to statutory obligations (Art. 28(3)(b)). 

Article 32 requires the implementation of appropriate technical and organisational security measures. This must be reflected in the contract and the level of detail must enable the controller to assess the appropriateness of the measures according to Article 32(1).  

The agreement must specify the limitations on the processor to engage another processor with the controller’s prior written authorisation. It is recommended the process for this authorisation be included in the contractual provisions. This authorisation can be either specific, referring to a specific sub-processor at a specific time, or general. General authorisation should include guidance on criteria for choosing sub-processors. The difference is based on interpreting a controller’s silence. Under general authorisation, the controller’s failure to object within a certain time frame can be interpreted as authorisation. When the processor engages another processor, a contract must be put in place between them imposing the same data protection obligations as those imposed on the original processor. The processor is then liable to the controller for the sub-processors’ compliance with the obligations.  

Ensuring data subject requests and how they are dealt with is up to the controller. However, the contract must stipulate that the processor has an obligation to provide assistance. The assistance may simply consist of forwarding requests received to the controller or may include more detailed processes. While the practical management of data subject requests can be outsourced to processors, the controller bears the responsibility for complying with such requests.  

The processor must also assist the controller in responding to data breaches. The processor must notify the controller whenever it discovers a personal data breach “without undue delay” and help the controller in obtaining the information to include in its report to the supervisory authority (Art. 33(3)). Notification of the supervisory authority and data subjects can be delegated to the processor, but the controller still maintains the responsibility to conform with obligations under the GDPR.  

When the processing period has ended, contractual terms dictating how and when the processor must delete or return the data should be stipulated (Art. 28(3)(g)). The processor must then comply unless EU or Member State law requires further storage. 

The contract should also include details on how often and how the flow of information between the processor and the controller should take place so that the controller is fully informed of the processing details ensuring compliance with Article 28 processor obligations. For example, the relevant portions of the ROPA may be shared with the controller.  

What to Include in the Joint Controller Data Processing Agreement 

Article 26(1) states that joint controller must in a transparent manner determine and agree on their respective responsibilities for compliance. This relates to the duty to provide information to the data subjects under Articles 13 and 14 and responding to data subject requests. Including the obligations laid out in Article 26, the EDPB also suggests clauses that consider: 

  • Implementation of general data protection principles (Article 5)  
  • Legal basis of the processing (Article 6) 
  • Security measures (Article 32)  
  • Notification of a personal data breach to the supervisory authority and to the data subject74 (Articles 33 and 34)  
  • Data Protection Impact Assessments (Articles 35 and 36)75 
  • The use of a processor (Article 28)  
  • Transfers of data to third countries (Chapter V)  
  • Organisation of contact with data subjects and supervisory authorities  

The obligations do not need to be evenly distributed, but all joint controllers have an obligation to ensure compliance with the GDPR. Article 26(1) staters that joint controllers should determine their responsibilities “by means of an arrangement between them.” There is no obligation on joint controllers to engage in a contract allocating responsibilities though, “for the sake of legal certainty,” the EDPB recommends such an arrangement be laid out in writing to provide certainty, transparency, and accountability.  

The “essence of the arrangement” must be made available to data subjects. The details of the “essence of the arrangement” are not specified by the GDPR giving joint controllers some flexibility. The EDPB recommends describing the contact point for data subjects as well as the elements of Article 13 and 14 along with which joint controller is responsible for ensuring compliance with these elements. It is up to the joint controller how they will make this arrangement available to the data subject. The suggestions are to include in the privacy policy or upon request to the Data Protection Officer. Irrespective of the terms of the arrangement, data subjects may exercise their rights against each of the joint controllers. 

Author

  • Stephen Ragan is Principal Privacy Consultant at Wrangu helping organisations understand and comply with global privacy regulations and overcoming data protection challenges. He holds a law degree from Indiana University and is a licensed attorney in Washington D.C. Stephen is also a Fellow at the Centre for Internet and Human Rights.

    View all posts

Author

  • Stephen Ragan is Principal Privacy Consultant at Wrangu helping organisations understand and comply with global privacy regulations and overcoming data protection challenges. He holds a law degree from Indiana University and is a licensed attorney in Washington D.C. Stephen is also a Fellow at the Centre for Internet and Human Rights.

    View all posts