Controller or processor: who answers for what, and why the label is not enough

A company that runs a website always ends up receiving this document. It comes with the analytics tool, the newsletter platform, the payment provider, the advertising network. It is called a processor agreement, a data processing agreement (DPA) or, in German, a Vereinbarung zur Auftragsverarbeitung. It designates the site’s operator as controller and the supplier as processor, then lists a dozen obligations over some ten pages. The commonest reflex is to accept it unread, on the assumption that these roles are administrative formalities and that the supplier, bigger, more specialised, more visible, will carry the compliance.

That assumption is exactly the reverse of what the text says.

Two roles, and a single test to tell them apart

Regulation (EU) 2016/679 defines the controller as the person who, alone or jointly with others, determines the purposes and means of the processing.¹ The processor, for its part, is defined by its dependence: it processes personal data on behalf of the controller.² The test therefore comes down to one word, determination. It is not the size of the company, nor its technical skill, nor even the physical possession of the data. It is the power to decide why the processing takes place and how.

The European Data Protection Board spelled out what the second half of the test, the means, covers in its Guidelines 07/2020. It distinguishes essential means, which concern the type of data processed, the retention period, the categories of recipients and the individuals concerned, from non-essential means, which are matters of technical implementation. The former belong to the controller. The latter may be left to the processor’s discretion without the processor changing role.

This distinction is the key to the whole subject. A hosting provider chooses its machines, its file system, its backup scheduler: these are non-essential means, and it remains a processor. A supplier that decides how long an identifier is kept, to which third parties it is passed and for what secondary purpose it is reused is deciding essential means, and that decision is a controller’s.

The rule most contracts pass over in silence

Article 28(10) of the Regulation states a consequence that is seldom cited in the contracts that invoke it. If a processor infringes the Regulation by determining the purposes and means of processing itself, it is considered to be a controller in respect of that processing.³

The scope of that sentence deserves to be stated exactly. It does not provide for a contractual penalty; it recharacterises the role. The role is not what the parties wrote, it is what the parties do. A contract may call a company that pursues its own purposes a processor, but that will not make it one before the supervisory authority. Conversely, the operator of a site sheds nothing by signing a document that names it controller: it already is one, or it is not, according to what it actually decides.

What the Court of Justice has held

Two judgments have fixed the reading, and both concern situations that any site operator will recognise.

In Wirtschaftsakademie Schleswig-Holstein, the Court held that the administrator of a page hosted on a social network, who configures the audience settings of that page and obtains visitor statistics, takes part in determining the purposes and means of the processing of visitors’ data, and must be classed as a controller jointly with the operator of the network.⁴ The administrator processed no data itself, held no raw data, and had no technical means of obtaining any. That did not suffice to exempt it.

In Fashion ID, an online retailer had embedded a third party’s social plug-in, which collected visitors’ data and transmitted it to that third party, including for visitors who had no account and had clicked nothing. The Court held that the site operator could be considered a joint controller with the provider of the plug-in, but only for the operations whose purposes and means it actually determines, namely the collection of the data and its transmission by disclosure, and not for the subsequent operations carried out by the third party alone.⁵

The second lesson of Fashion ID is as important as the first: joint controllership is not global, it is divided operation by operation. One can be a joint controller of the collection and a stranger to what the partner does afterwards.

The third role, the one contracts avoid

Where two entities jointly determine the purposes and means, they are joint controllers. Article 26 then requires them to define, by way of a transparent arrangement, their respective responsibilities, in particular for the exercise of data subjects’ rights and for the information to be given to them. The essence of the arrangement must be made available to the data subjects, who may exercise their rights against each of the controllers, whatever the arrangement has allocated.⁶

That last point explains why suppliers so rarely offer joint controllership. It forbids sending the data subject to the other party. A data processing agreement, by contrast, lets the processor pass any request it receives to the controller and leave it there.

There is, finally, a fourth configuration, often the right one and almost never named: that of two independent controllers. Two companies that exchange data but each pursue their own purpose, without deciding it together, are neither processors of one another nor joint controllers. Each answers for its own processing, and the transfer itself must have its legal basis.

What the role changes, in practice

The question is not a doctrinal one. Six obligations change hands according to the role held.

Informing data subjects falls to the controller, under Articles 13 and 14. The processor informs no one.

Answering requests for access, rectification and erasure falls to the controller, within one month.⁷ The processor merely assists the controller, and passes on the requests it receives directly.

Notifying a personal data breach to the supervisory authority, within 72 hours of becoming aware of it, falls to the controller.⁸ The processor notifies the controller, without undue delay, and no one but the controller.⁹ A leak at the supplier therefore starts a clock in its client’s diary.

The record of processing activities exists for both roles, but its content differs: the controller’s describes the purposes, the processor’s describes the categories of processing carried out on behalf of each client.¹⁰

The data protection impact assessment falls to the controller.¹¹

Civil liability, finally, is governed by Article 82: the processor is liable for the damage only where it has not complied with obligations of the Regulation specifically directed to processors, or where it has acted outside or contrary to the controller’s lawful instructions.¹² In other words, outside those two cases, it is the controller who answers.

The same division in Swiss law

A company established in Switzerland finds the same architecture, in a different vocabulary. The Federal Act on Data Protection (FADP) defines the controller and the processor, and its Article 9 governs processing by processors: processing may be entrusted to a third party by contract or by law, on three conditions, namely that the third party carries out only the processing the controller would itself be entitled to carry out, that no statutory or contractual duty of confidentiality prohibits it, and that the controller ensures the third party guarantees data security.¹³ The processor may itself entrust the processing to a third party only with the controller’s prior authorisation.¹⁴

The difference lies less in substance than in procedural consequences, and above all in the fact that the two regimes often overlap rather than replace one another. That is the subject of the third instalment of this series.

What to check before signing

Three questions suffice to place a contract put in front of you.

The first: who decided the retention period, the categories of recipients and any reuse of the data? If the answer is the supplier, the processor classification is fragile, whatever the document is called.

The second: does the supplier, through the same processing, pursue a purpose of its own? An ad broker that retargets, a network that pools data across several clients, a tool that improves its model with the data processed: all pursue a purpose of their own.

The third: what happens when a data subject writes in? If the contract provides that the supplier forwards the request to you, you must be able to answer it, including for data you do not host.

A well-drafted data processing agreement does not make these three questions go away. It merely makes them easier to ask. The eight items such a contract must contain are the subject of a separate article, Reading a GDPR processor contract.

Notes

1. Regulation (EU) 2016/679, Art. 4, point 7. ↩

2. Regulation (EU) 2016/679, Art. 4, point 8. ↩

3. Regulation (EU) 2016/679, Art. 28(10). ↩

4. CJEU, 5 June 2018, Wirtschaftsakademie Schleswig-Holstein, C-210/16. ↩

5. CJEU, 29 July 2019, Fashion ID, C-40/17. ↩

6. Regulation (EU) 2016/679, Art. 26(1) to (3). ↩

7. Regulation (EU) 2016/679, Art. 12(3). ↩

8. Regulation (EU) 2016/679, Art. 33(1). ↩

9. Regulation (EU) 2016/679, Art. 33(2). ↩

10. Regulation (EU) 2016/679, Art. 30(1) and (2). ↩

11. Regulation (EU) 2016/679, Art. 35(1). ↩

12. Regulation (EU) 2016/679, Art. 82(2). ↩

13. Federal Act on Data Protection (SR 235.1), Art. 9(1) and (2). ↩

14. Federal Act on Data Protection (SR 235.1), Art. 9(3). ↩