The difference between a controller and a processor under GDPR should be an easy topic, but it can even get Privacy professionals tied up in knots.
Don’t worry if it’s giving you trouble, in less time than it takes to have a cup of tea, we’re going to nail down the difference and, as always, look at great examples from regulators.
And stick around as we’ll give you links to great checklists from the UK ICO and the European Data Protection Supervisor to decide if you’re a controller or processor, and a fantastic document from Keepabl that summarises all of these so you can download it all in one go.
This is the first in our series on Controllers and Processors. You can watch the accompanying video: Controllers v Processors in GDPR, which is part of Privacy Kitchen – FREE video help with GDPR and all things Privacy. If you’re new to Privacy Kitchen, please do check it out here – and click subscribe and notify to hear about awesome Privacy Kitchen videos.
Right, let’s get to it.
Whether you’re a controller or a processor, you’ve got direct obligations under GDPR, so why does it matter?
Here are three good reasons!
#1 Controllers have many more obligations under GDPR than processors, including the obligation on controllers to deal with and respond to Data Subject Rights and Breach.
#2 Secondly, it impacts the way you interact with your customers, suppliers and partners in the sharing of contractual liability.
#3 And a big one: number three … these are all big… it really can mean that someone you think it was your processor maybe, actually, is a controller – and maybe even a joint controller with you.
Well, GDPR defines the controller as the person who decides these two core aspects of processing personal data: the ‘purposes’ and the ‘means’. Let’s look at this in plain English, and let’s look at ‘purpose’ first.
The ‘purpose’ is why you’re doing the processing. That’s it. It’s just the why. Examples are sales outreach, marketing campaigns doing payroll, or doing recruiting for HR, or doing anti money laundering. These are all why you’re processing. It’s the purpose.
And deciding purpose is so important that if you decide the purpose, you’re definitely a controller – if you don’t decide the purpose, you’re not.
The ‘means’, er … means. the how of your processing. Now, we’ll see this is pretty broad and made up of various different elements, and some are more important than others.
The Article 29 Working Party, the body made up of all EU regulators pre-GDPR, confirmed that we’re talking about the ‘essential elements‘ here or the ‘essential means‘ – not all of them. If you decide those essential means you’re a controller.
So what are they? Well, that Article 29 Working Party gave three examples:
All very key decisions. The UK ICO includes these, as well as deciding the purpose, as ‘overarching decisions‘ then adds:
So in summary, if you decide these essential means, you’re a controller and if you don’t, you’re most probably not.
Ok, so what’s a processor?
GDPR’s definition of processor is very simple: it’s someone who processes personal data on behalf of the controller.
And GDPR confirms processors can only process personal data:
They can’t even appoint sub-processors without approval from the controller.
Now, EU Regulators have noted that ‘acting on behalf of‘ means serving someone else’s interest and that reinforces the idea that it’s not the processor who’s decided the why, or the purpose, of the processing, they’re only processing to serve the controller’s interests.
We saw a controller has to decide the essential means of processing, which means that processors can decide the ‘non-essential means‘. Regulators have said that ‘non-essential means’ includes the technical and organisational elements, such as what hardware or software to use.
So let’s look an example – we all love examples!
Looking at the sales outreach example from the beginning:
Now, as a processor, HubSpot can still determine non-essential means, such as the hardware and software to use – it could be how their application’s built or what their data centre looks like, for example.
We’ll go into this in detail in another video, so let’s just note controllers don’t need to be 100 prescriptive on means. To quote the Article 29 Working Party, ‘a processor could operate further to general guidance provided mainly on purposes and not going very deep in regards to the means’.
And we saw that it’s the non-essential means that processors have more leeway on.
Now, we know you love examples as much as we do, so here are some more examples, first from the UK ICO:
OK, two more examples from the Article 29 Working Party:
And a great second example from the Article 29 Working Party:
So why all the difficulties? This all sounds nice and clean cut. Why does it create so much confusion and argument even amongst Privacy professionals?
One reason is some of your suppliers may have to be seen as controllers, not processors because of their legal or professional obligations. Typical examples here are lawyers and accountants. As the UK ICO nicely puts it: ‘if specialist service providers are processing data in line with their own professional obligations, they’ll always be acting as the controller. In this context, they cannot agree to hand over or share controller obligations with the client.’
But the two big reasons are people’s ambition and something called ‘joint controllers’.
Now we’ll look at both how far a processor can go, and push it before they become a controller, and we’ll look at what a joint controller is, in separate blogs and videos. So, back to the basic distinction between controller and processor.
We’ve seen that the controller is the person who determines the purposes and the essential means of the processing: the why and the how.
And we’ve seen that the processor only processes the personal data on behalf of that controller, not for its own purposes, although it can decide on some non-essential means.
And a couple of closing points:
So there you go, your tea’s still warm, and we’ve set out the clear water between controllers and processors.
You’ll find the links in the notes below to everything we’ve discussed as well as a really helpful document Keepabl’s put together, including checklists from the UK ICO and the EDPS on controller and processor.
Do get involved! Use #privacykitchen to tell us the questions and topics you want covered.
Stay well in the meantime, and see you soon in Privacy Kitchen!
Data Subject Requests (DSARs) – Top Tips, Typical Errors & Brexit If you’re dealing with data subject access requests (or DSARs), you need to watch our expert Guest Chefs, Shad…