One of the first steps in any effective GDPR compliance program is to establish the extent to which the subject organisation is a data controller with respect to personal data, and the extent to which it is a data processor. This distinction is fundamental. The legal obligations that apply in relation to controllers are quite different from those that apply in relation to processors. Given this importance of this distinction, you might expect the legislators to have made certain that it is easy to tell one role from the other. But if that is what you expect, you would be wrong.
In this post I look at two different problems with the distinction. The first problem relates to the text of the definition of “controller”; and the second relates to the control by an individual of his or her own personal data.
Before turning to the problems, we should consider the key definitions.
Controller and processor
The definition of processor in the GDPR is dependent upon the definition of controller; you need a controller before you can have a processor:
“controller” means 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; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
“processor” means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;
“Processing” is central to the scheme of the GDPR. It is carried out whenever an organisation does anything with personal data. Processing is carried out by both controllers and processors (it’s a common misunderstanding that processing is only carried out by processors).
Purposes and means
If you read the definition of “controller” in isolation, you will likely form a different view of its meaning to the official view.
The GPDR says that a person is a data controller if that person determines “the purposes and means of the processing of personal data”. However, the definition is usually applied such that if you determine the purposes of processing you are a controller, even if you have little say over the means. See for instance the examples listed in the Article 29 Working Party’s Opinion 1/2010.
It follows that processors may in fact determine means. More than one of my clients has assumed that they are a controller with respect to data because they determine the means of processing – for example which technologies and which sub-processors to use.
The official interpretation is perhaps necessary, given the definitions. If any determination of means made a person a controller, then there would be few or no processors: everyone in the processing chain would be a controller. The Article 29 Working Party explains:
Determination of the “means” therefore includes both technical and organizational questions where the decision can be well delegated to processors (as e.g. “which hardware or software shall be used?”) and essential elements which are traditionally and inherently reserved to the determination of the controller, such as “which data shall be processed?”, “for how long shall they be processed?”, “who shall have access to them?”, and so on. Against this background, while determining the purpose of the processing would in any case trigger the qualification as controller, determining the means would imply control only when the determination concerns the essential elements of the means. In this perspective, it is well possible that the technical and organizational means are determined exclusively by the data processor.
The opinion predates the GDPR, but the definition – and my point – remains. On the one hand, the GDPR says that you are a controller if you determine the purposes and the means of processing. On the other hand, the Working Party asserts that it is possible for a processor to exclusively determine the means of processing.
As far as I can discover, distinguishing controller-type determinations from processor-type determinations by appealing to “essential elements of the means” has no basis in the legislation, old or new. In any case, it is not easy to see how you should distinguish essential from non-essential elements of the means.
Own data controller
A further difficulty relates to individuals, “data subjects” in the jargon. Whilst individuals can be controllers with respect to the personal data of others, many of the provisions of the legislation make little sense if they can be controllers of their own personal data.
For instance, leaving to one side the “personal and household activity” exclusion, it would be odd if data subjects had a legal obligation under the GDPR to impose Article 28 processing clauses on organisations that provide processing services to them. It is therefore usually thought that an individual cannot be a controller with respect to his or her own data.
However, as a matter of logic, an individual may (for example, by contract) be in a position to “determine the purposes and means” of the processing of their own personal data. Can an organisation acting on behalf of the individual and following the instructions of the individual be a controller, even though it does not determine purposes and means? Can the organisation be a processor, even though there is no controller to make the decision to appoint them as processor?
In practice, I would expect such an organisation to be treated as a controller. That’s the least worst interpretation, but it does lead to some practical inconsistencies. If an organisation provides the same services to individuals and businesses, processing the same types of data in the same ways, it may find that it is treated as a controller with respect to the data supplied by individuals and a processor with respect to the data supplied by businesses.
Theoretical issues and real problems
These problems are not merely theoretical. They cause real problems when we try to apply the controller / processor distinction in practice.
I should also stress that these are not the only problems with the distinction. For example, the concept of “purposes” is slippery and subjective. One purpose tends to mask another, and the process of deciding that one purpose matters where another does not tends to be rather artificial. For example, many processors process personal data for the purpose of earning money, but that doesn’t seem to count. In practice, however, I don’t find the determination of purposes to be so problematic as the issues outlined above.
It would be helpful to see some updated guidance from the regulatory authorities on the distinction. The Article 29 Working Party is very clear in Opinion 1/2010 that the concept of controller is functional, in that it is intended to allocate responsibility for compliance. Given that those responsibilities are changing with the GDPR – with processors carrying many more obligations under the new law – there is room to argue that the existing guidance is out of date.
Add a new comment