EDPB publishes draft guidelines on controllers and processors

This is a topic that has not been reviewed in detail by the EDPB or the Article 29 Working Party since the latter’s 2010 opinion.

As the EDPB acknowledge, the meaning of controller, joint controller and processor are of “paramount importance” in data protection law, and the criteria for their correct use, needs to be sufficiently clear and understood - therefore the Board's guidance was much anticipated.

The Guidelines are detailed – 48 pages of detail. They cover well established principles on the differences between controllers and processors which will be familiar ground to seasoned privacy practitioners, but the paper gives further guidance into the often vague world of joint controllership and its consequences (see Section 2).

The EDPB also, in parallel to the Guidelines, published their separate guidance on social media targeting, in which the Board find widespread joint controllership between social media networks and advertisers, based on reasoning, which will likely have application to AdTech more generally (See Section 2b.).

1. Who is the Data Controller?

The data controller is defined in the GDPR as “the natural or legal person, public authority, agency or other body which alone or jointly with others, determines the purposes and means of the processing of personal data….”

Determination of the Processing: The controller determines the key elements of the processing and to understand who fulfils this role the Board suggest that the following questions should be asked “why is this processing taking place?” and “who decides that the processing should take place for the particular purposes?”

The EDPB reminds us that in ascertaining who is controller, the assessment should be based on a factual rather than formal analysis.

Control can stem from law or from factual influence. An example of the former would be where the legislator has designated a particular entity in law with the ability to exercise control (either expressly or implicitly) for example, national law designating local authorities with the power to administer social welfare payments.

More commonly, control will stem from the factual influence an entity has over the processing.

According to the EDPB “all relevant factual circumstances must be taken into account in order to reach a conclusion as to whether a particular entity exercises a determinative influence with respect to the processing of personal data in question.”

In this assessment, it is often useful have regard to traditional roles and level of professional expertise that implies a certain level of responsibility. For example, “when an entity engages in processing of personal data as part of its interactions with its own employees, customers or members, it will generally be the one who factually can determine the purpose and means around the processing and is therefore acting as a controller within the meaning of GDPR.”

A review of the contractual terms between different parties can also help determine which party is acting as controller. Even if the contract does not specifically label parties as controllers, it may nonetheless be possible to infer which party exercises a decision making role when it comes to processing personal data.

Importantly, the EDPB confirms that if data protection labels are assigned contractually - if there is no reason to doubt the accuracy of these labels - the labels will likely stand. However, echoing long-standing regulatory guidance, the EDPB notes that “the terms of a contract are not decisive in all circumstances” - as the alternative would simply allow parties to “contract out” of their controller role. So if the contract states you’re a processor but you use the data for your own purposes, then you’re a controller regardless of what the agreement states.

Purpose and means: The data controller is the entity that determines the purposes and means of processing i.e. what is the anticipated outcome intended for which the data is being processed? And how is that result obtained or end achieved?

The controller must decided on both purpose (the why) and the means (the how) of the processing.

However, the EDPB recognises, in line with existing guidance, “that some margin of manoeuvre may exist for the processor….to make some decisions in relation to the processing.”

In contrast, the processor can never decide on the purpose of the processing. By doing so, it would become the controller.

As for the means of processing, decisions pertaining to non-essential means, i.e. practical aspect of the processing, such as hardware, software or security measures deployed, can be delegated to the processor. While the data processor can decide on the non-essential means of the processing, the controller must, nonetheless, be informed about the means used so that it can agree to them.

It is important to be able to distinguish those non-essential means of processing which can be performed by the processor from essential means - which cannot. In contrast to non-essential means, essential means are closely aligned with the purpose of the processing - so a data processor cannot decide for the controller ‘what data will be processed? whose data will be processed? the duration of the processing? Or who the data be shared with?’

Relate to personal data: The purposes and means determined by the controller relate to the processing of personal data.

The fact a company does not deliberately target personal data or wrongly decides that it does not process personal data, will not let the entity off-the-hook when it comes to meeting the GDPR's controller obligations.

Importantly, the EDPB clarifies, in line with the CJEU judgment in the Jehovah Witness case [1], that you can also be a controller without having access to the data being processed. A key example of this included in the Guidlines would be a retailer outsourcing a data processing activity such as market research to a vendor, which involves the vendor collecting personal data about participants, but with the retailer only receiving back aggregated statistical information (such as customer trends per region). The retailer is still a controller because it has “determinative influence” on the purpose and means of processing - it is directing the entire project - notwithstanding that it will never touch the personal data collected.

2. Joint Controllership

In assessing data protection roles, one of the big challenges for privacy practitioners today, is establishing where independent controllership ends and joint controllership begins.

The EDPB’s guidance on joint control broadly tracks recent case law from the CJEU but it does give some useful examples and further clarity around the consequences of joint controllership.

The starting point for joint control is Article 26 GDPR which provides that “where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.”

In assessing whether joint controllership exists it is necessary to examine “whether the determination of purposes and means that characterise a controller are decided by more than one party.”

According to the EDPB, “the overarching criterion for joint controllership to exist is the joint participation of two or more entities in the determination of the purposes and means of a processing operation.”

As with the assessment of controllership generally, the assessment of joint controllership should be driven by the factual realities of the processing rather than any formal analysis.

a. How to assess joint participation

The EDPB acknowledges that joint participation in determining the purpose and means of processing can take different forms and it gives two main examples: (1) common decisions and (2) converging decisions.

Common Decisions: Joint participation can simply mean that each of the controllers make the decisions around purpose and means together with common intention. “Common decisions” reflect what is likely to be the “most common understanding” of the term “jointly deciding the purpose and means of the processing”.

Converging Decisions: In contrast, joint participation through “converging decisions” reflects recent CJEU case law on joint control. According to the EDPB, “decisions can be considered as converging on purpose and means if they complement each other and are necessary for the processing to take place in such manner that they have a tangible impact on the determination of the purposes and means of processing.”

An important question in assessing converging decisions is whether the processing would not be possible without both parties’ participation in the sense that the processing by each party is inseparable or “inextricably linked”.

Just because numerous entities are involved in the same processing does not mean that they are joint controllers. If the parties do not jointly determine purposes or means then the processing should be considered as a transfer of data between separate controllers. To illustrate the point, the EDPB gives the example of an employer sharing, further to a legal obligation, employee data with the tax authority. In this case, even though both the employer and tax authority process the same salary data, the lack of jointly determined purposes and means, means that the employer and tax authority are two separate controllers. Similarly, a group of companies using the same CRM database will not be joint controllers if each entity enters its own client and prospect data, uses for each companies own purposes only, independently decides access control, processes for retention and deletion etc.

Similarly, the fact that various entities successfully process the same personal data in a chain of operations for independent purpose, with independent means, results in those entities being independent rather than joint controllers.

The EDPB gives a number of examples to illustrate the application of joint control. These emphasise the need to break down different stages of processing activity when determining the designations which should apply to those involved.

b. Joint Control in Social Media Targeting

The EDPB published, in parallel with its guidance on controllers and processors, draft guidelines on targeting social media users. These guidelines on social media targeting include, among other matters, worked examples of a number of common use cases, in which the EDPB find widespread application of joint controllership between advertisers and social media networks. The principles supporting such conclusions will have application outside of social media targeting and are likely to apply to AdTech more generally.

The EDPB’s comments on joint controllership in the social media context broadly reflects the recent case law from the CJEU, in summary:

• A website operator is a controller when it embeds a social plugin on its website that causes the browser to transmit personal data to the social network.
  
  
• The website operator will only be controller in respect of activities for which it determines the purposes and means of processing. Therefore, in Fashion ID the website operator and Facebook were joint controllers for the collection and disclose of the data to Facebook. By contrast, the CJEU found that in that case, Fashion ID did not determine the purposes and means of the subsequent processing carried out by Facebook.
  
  
• In Wirtschaftsakademie, a private company, that provided education-related services, who was the administrator of a fan page on Facebook was regarded as determining the purposes and means of processing with Facebook. Facebook collected and processed data from the fan page through cookies. Some of the data was used by Facebook to improve advertising on its network. Facebook also provided anonymous statistics to the administrator, such as details of the type of visitors to the fan page. Key to the CJEU reasoning was the fact the administrator set parameters around the type of data collected, which influenced the processing. The CJEU concluded that this meant the administrator must be a joint controller with Facebook. As noted above, the fact the administrator had no access to the personal data collected, did not exempt it from being a joint controller.
  
  

Examples of data protection roles, given by the EDPB, for targeting via common social media tools are set out below:

c. Consequences of Joint Controllership

Where joint controllership applies, Article 26(1) GDPR requires that the parties “in a transparent manner determine their respective responsibilities for compliance with the obligations under [the GDPR]….”

These rules are to ensure that the protection of personal data is not diluted merely because there are multiple actors or where conflict of competence could result in some obligations not being complied with.

This division of responsibility in Article 26 must “in particular” cover the exercise of the rights of data subjects and the obligation to provide notice of the processing pursuant to Articles 13 and 14 GDPR.

Unsurprisingly, the EDPB construes the reference to “in particular” in Article 26 as indicating the references to transparency and the exercise of individual rights in Article 26(1) GDPR are non-exhaustive, but extends to the other controller obligations in GDPR. Thus, “joint controllers” need to ensure that the whole joint processing fully complies with the GDPR.

While Article 26 only requires that the division of responsibility between joint controllers be carried out “by means of an arrangement”, the EDPB, for reasons of legal certainty and accountability, recommend that such arrangement be made in the form of a binding document, such as a contract or other legally binding act under EU or Member State law.

The EDPB also sensibly suggests that the joint controller agreement could include limitations on the use of the shared data for further processing. This point is increasingly important in data sharing agreements more generally and echoes lessons learned from the ICO’s enforcement against Facebook for Cambridge Analytica, in that failure to prohibit further processing in your contract, could mean you are liable for permitting it.

Interestingly, the EDPB also recommends, from an accountability perspective, that joint controllers keep the internal analysis that was carried out when assigning the different obligations under GDPR, suggesting that regulators may interrogate the allocation of responsibilities ex post.

Another recommendation in the Guidelines is that the arrangement specifies details of the processing - similar to that in an Article 28 data processing agreement (“DPA”) - notably specifying the subject matter and purposes of the processing, the type of personal data, and the categories of data subject.

Article 26 GDPR requires that the “essence” of the division of responsibility be made available to the data subject. The EDPB recommends that the essence cover at least all the elements of the information referred to in Articles 13 and 14 that should already be accessible to the data subject, and for each of these elements, the arrangement should specify which joint controller is responsible for ensuring compliance with these elements.

The EDPB does not construe the requirement to make this information on the “essence” of the arrangement available to data subjects as mandating that the information be set out in the privacy notice. The EDPB finds that Article 26 does not state that the document should be available “upon request” nor made “publicly available” by way of appropriate means - it is therefore up to the joint controllers to decide the most effective way to make the essence of the arrangement available to the data subjects (although the EDPB show less flexibility on this point in their paper on social media targeting). The EDPB stresses that although it is up to the controller to decide the best method of providing this information, it must be totally clear to data subjects how they exercise data subject rights; and regardless of the division of responsibility agreed between the joint controllers, the data subject may, under Article 26(3) GDPR, exercise his or her rights against each of the controllers. Although the EDPB guidance does not say this expressly, the net result seems to be that joint controllers should review their privacy notices to ensure that they strike the right balance to correctly provide the above information.

3. The Processor

a. Who is the data processor?

A processor is defined in GDPR as a natural or legal person, public authority, agency or another body, which processes personal data on behalf of the controller.

The two basic conditions of being a processor are, according to the EDPB, (1) being a separate entity to the controller and (2) processing personal data on the controller’s behalf.

Employees, and temporary staff, acting under the direct authority of the controller, processing the data in an authorised way, are not processors since they process personal data as part of the controller’s entity.

Acting “on behalf of the controller” means that the processor is serving the controller’s interest and in legal terms, similar to the concept of delegation. If the entity is using the personal data for its own purposes it will be a controller, and may be sanctioned for going beyond the controller’s instructions. The decision to add an additional purpose to the one for which the personal data were transferred converts the processor “into a data controller for this set of processing operations and their processing for this purpose would constitute an infringement of GDPR”

Nothing prevents the processor from offering a preliminary defined service, but the controller must have the final say in approving the way the processing is carried out and/or be able to request changes.

The EDPB notes that just because a counterparty is a vendor providing services to the customer controller does not automatically mean that the service provider will be a processor. Instead the nature of the service must be assessed on a case by case basis to ascertain whether the processor is in fact processing the personal data on behalf of the controller.

Service providers need to identify which data they may need to process in order to provide their service. The EDPB gives the example of a taxi service providing an online platform to companies to carry out airport runs for the company’s employees. As part of the service, the taxi company needs to obtain, via its booking platform, the names of the employees to be collected from the airport. The taxi company itself establishes what information it needs to capture about passengers and how long it keeps this data. Therefore, even though the taxi company is receiving details of the company’s employees in order to provide the service, the taxi company is a data controller for this processing, as it is deciding what data is collected and the retention period.

If a service provider is providing a service to a customer where access to personal data “will be purely incidental and …very limited in practice” then it may, according to the EDPB, be acceptable for the customer to conclude that the service provider is not a controller or processor provided the customer can take appropriate security measures to prevent the service provider from processing personal data in an unauthorised way. This is a point to be interpreted cautiously. If the service provider has systematic access to personal data or the ability to access the data, even if incidental to the main service, as is often the case with for example, IT support services, then the service provider will be a processor.

b. Consequences of being a data processor:

Where an entity acts as a data processor, an Article 28 DPA GDPR data processing agreement DPA needs to be put in place. Article 28 is, by now, well-known but key points to note from the EDPB's commentary include:

Due Diligence: Controllers have an obligation to only use processors providing sufficient guarantees that the processing will meet the requirements of GDPR, it is, therefore, key that controllers due diligence their processors to confirm this. The level of due diligence required will be dictated by the risk on a case-by-case basis. The due diligence will generally require the processor making available to the controller documents that illustrate the level of guarantees the processor offers, such as privacy policy, terms of service, record of processing activity, external audits, security standards, international certifications etc. The review should cover-off the processor’s knowledge, reliability and resources - market reputation may also be relevant.

Importantly, the EDPB notes that the obligation to use only processors providing sufficient guarantees is a continuous obligation, and not an obligation only on on-boarding. Instead, the EDPB advises that the controller should, at appropriate intervals, verify the processor's guarantees including through audits and inspections where appropriate. Controllers need to evidence that these checks are satisfactorily carried out and it is easy to see how this type of due diligence could be central to a regulator’s investigation in the aftermath of a processor side breach.

DPA must be binding: the DPA must be in writing and must be binding on the processor. It can be a contract or “other legal act” (however if the legal act does not include the minimum Article 28(3) provisions then it needs to be supplemented by a contract or other legal act).

In line with guidance from data protection authorities the EDPB confirms that the obligation to ensure that the DPA is in place applies to both the controller and the processor. Processors take note: the absence of a DPA would not constitute a breach of the GDPR by the controller alone. The processor would also be non-compliant and the EDPB specifically warns that failure to have a GDPR compliant DPA or failure to update legacy pre-GDPR terms constitutes an infringement of Article 28(3) GDPR.

DPA should be bespoke to processing: The DPA should take into account “the specific tasks and responsibilities of the processor in the context of the processing to be carried out and the risk to the rights and freedoms of the data subject”. The DPA should also help the processor understand the risks to data subjects from the processing which will often be clearer to the controller than the processor.

When setting out detail of the processing in the DPA (i.e. subject matter, duration of processing, types of personal data etc.) - specifics are key. For example, when listing the categories of personal data, merely referencing “personal data pursuant to Article 4(1) GDPR” or “special categories of personal data pursuant to Article 9” would not suffice; instead the types of data should be listed such as “information regarding health records” or “information relating to trade union membership” should be referenced.

Other examples of the requirement for specificity given elsewhere in the Guidelines, includes not merely “restating [the processor’s duties]” to assist the controller with the controller’s obligations under Articles 32-36 GDPR, but rather outlining how the processor is asked to help the controller meet these obligations. This could be achieved by appending to the DPA template forms and procedures, for providing this assistance.

Parties should be driven by risk - while all processor DPAs must comply with Article 28 GDPR - there is, according to the EDPB – “no need to impose particularly stringent protection and procedures on a processor entrusted with a processing activity from which only minor risk arises.” This guidance could also perhaps be taken to justify the inclusion of more stringent provisions in DPAs agreed in respect of higher risk personal data processing.

Details of the processing: Instructions must be documented: It is important for service providers who are data processors to provide their controller customers with a detailed description of how the customers’ data will be processed and get their sign-off (including to international transfers). Otherwise, the service provider may have no paper trail to evidence that it was merely acting on the controller’s instruction and not itself determining the purposes and means of processing. While processors will generally have DPAs in place, record keeping of the controller’s instructions can often be patchy in practice, but could be important to avoid the processor being later re-categorised as a controller were matters to become contentious - which for example, they could, in the aftermath of a breach.

Processor can only act other than on documented instructions of the Controller where required by EU or Member State law: The EDPB notes that this restriction in Article 28(3) to only act on the controllers instructions unless required by EU or Member State law reveals the importance of carefully negotiating and drafting DPAs and the fact that legal advice may need to be sought by either party as to the existence of any such legal requirement. Although the point is not explicitly covered in the EDPB guidance, this is a provision that is likely to become increasingly important given the CJEU’s judgment in Schrems II, as controllers will now be less willing to allow service providers to broaden these carve-outs from “EU or Member State law” to “applicable law”, given this change - which is fairly common today - could contractually permit access by law enforcement authorities in third countries.

Security: The controller should provide processors with a description of processing activities and security objectives and the controller must provide the measures proposed by the processor.

In line with the wider comments around specificity above, the contract needs to reference the specific security measures to be adopted, prohibit changes to security without the controller's permission and provide for regular security reviews to take account of the fact that the risk profile may change during the life of the DPA. The DPA should also include an obligation on the processor to help the controller with security; this assistance obligation is a separate obligation to the more general requirement in the contract on the processor to implement appropriate technical and organisational security measures.

Sub-processors: One of the most challenging aspects in Article 28 for processors relates to the restrictions around sub-processing. A processor cannot appoint a sub-processor without the controller’s consent: this can be specific approval (i.e. the processor asking the controller for consent on a case by case basis) or general approval (i.e. where a processor provides the controller with a list of sub-processors being used and notifies controllers of changes to the list allowing the controller to object).

In relation to the general consent mechanism, the EDPB notes that the processor must actively inform the controller of any change to the sub-processor list. It is not sufficient for the processor to merely provide the controller with generalised access to a list of sub-processors which might be updated from time to time.

The processor must also inform the controller in good time of intended changes to the sub-processor list so as to provide the controller with the opportunity to object.

If the controller agrees to the sub-processing, the other significant challenge for the processor is the requirement to flow down to the sub-processor the same obligations as those imposed on the first processor by the controller. The EDPB does show some pragmatism on the point, noting this requirement to flow down the “same” obligations “should be construed in a functional rather than formal way”: the obligations do not need to be flowed down verbatim; instead, the processor must ensure that the obligations in substance are the same. However, as processors will know, even this, can be extremely challenging in practice.

Instructions infringing data protection law: Under Article 28(3), a processor must immediately inform the controller if, in its opinion, an instruction from the controller infringes the GDPR or other Union or Member State law. The drafting of this provision is somewhat unclear in Article 28 GDPR (despite opportunities to clarify it not being taken) which led some commentators to initially doubt whether the provision needed to be included in DPAs. However guidance from regulators, now including the EDPB, is clear that this provision must be in the DPA. The EDPB also recommends that the parties negotiate and agree what should happen if a processor makes this notification, such as including a processor termination right if the controller continues with the unlawful instruction.

Imbalance in contractual bargaining strength: Negotiating DPAs can be difficult if not near impossible for customers where the processor is a large service provider with standard terms, but reflecting similar sentiment to ICO, the EDPB has little sympathy in such cases, noting that: “the imbalance in the contractual power of a small data controller with respect to big service providers should not be considered as a justification for the controller accepting clauses and terms of contracts which are not in compliance with data protection law.”

Termination: Under Article 28(3) GDPR the processor must, at the choice of the controller, delete or return personal data to the controller. The EDPB recognises that the controller can decide upfront whether personal data is deleted or returned, however they note that the contract should give the controller the possibility to change this instruction before the end of the service. Controllers should be alive to this point, as some service providers specify data will be deleted by default with no option for the return of data - which if the data is needed by the controller, can, commercially, prove an obstacle to termination or switching providers.

Conclusions:

Despite its high word count, the EDPB’s guidance is not packed with surprises for those who have followed recent CJEU cases such as Fashion ID and Wirtschaftsakademie. It seems that the most notable aspect of the guidance is its re-enforcement of the impact of that case law - i.e. it is much easier for parties to a contract to be considered a controller as opposed to a processor as compared to what has traditionally been the case. This and the increased potential for a party to fulfil a different designation at different stages of its processing activities may mean more detailed contractual clauses are required. This is likely to mean that many existing contractual arrangements will need to be re-evaluated, and we are already seeing refreshed standard terms emerge from large tech companies. That trend will, we think, continue as organisations of all sizes consider whether their key processing arrangements should similarly be revised.

The Guidelines are open to a short period of public consultation until 19 October.

[1] Tietosuojavaltuutettu v Jehovan todistajat 2018 (Case Case C-25/17)