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.

What are Controllers and Processors in GDPR?

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.

Controllers

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.

Purpose

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.

Means & Essential Means

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:

• what data will be processed?
• how long will you process the personal data for? and
• who you’ll share the personal data with including which third parties?

All very key decisions.  The UK ICO includes these, as well as deciding the purpose, as ‘overarching decisions‘ then adds:

• deciding to collect personal data in the first place,
• the lawful basis for doing so,
• what types of personal data to collect,
• which individuals to collect data about,
• whether to disclose the data and, if so, to whom – which we saw in the Article 29 list,
• what to tell individuals about the processing,
• how to respond to requests made in line with individual rights under GDPR, and
• how long to retain the data, or
• whether to make non-routine amendments to data.

So in summary, if you decide these essential means, you’re a controller and if you don’t, you’re most probably not.

Processors

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:

• as required by the contract with that controller, or
• that controller’s instructions.

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.

Non-essential means

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:

• Your sales team, say, is targeting pharmacies in London.  You’ve lawfully built a list of pharmacies and the people at the pharmacies who buy your type of product.  You decided what you think is best suited to those businesses, how to contact them, the opt out mechanism, the message, et cetera, and what CRM to use, how long you’re going to keep the data et cetera.  You’re the controller.
• Now, let’s say you put that data into a CRM like HubSpot.  They didn’t decide the purposes.  They didn’t decide the essential means.  You could decide to move from HubSpot to Salesforce and tell HubSpot to delete everything – they’re your processor.

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.

How much discretion does a processor have?

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.

Examples!

Now, we know you love examples as much as we do, so here are some more examples, first from the UK ICO:

• A gym engages a local printing company to produce invitations to a special event they’re hosting.  The gym gives that printing company names and addresses of members from its database.  The printer uses that to address the invitations and envelopes.  The gym sends out the invitations.
• The gym is the controller of the personal data processed in connection with the invitations – they determined the purposes – the why, or why it was being processed, to send individually addressed invitations to the event – and the means of processing: merging that data together using their address details.
• The printing company is a processor processing the personal data only on the gym’s instructions.

OK, two more examples from the Article 29 Working Party:

• Company ABC entered into contracts with different organisations to carry out mail marketing campaigns and to run its payroll.  It gives clear instructions what marketing material to send out, to whom, who to pay, what amounts, what dates et cetera.
• Even though those organisations have some discretion, including what software to use, their tasks are pretty clearly and tightly defined.  Now, they may offer advice, but they’re clearly bound to act as company ABC instructs.
• And only one entity, Company ABC, is entitled to use the data which is processed.  All the other entities have to rely on the legal basis of Company ABC if their ability to process that data is questioned.
• So it’s clear here that Company ABC is the controller and the separate organisations are processors regarding the specific processing of data carried out on behalf of Company ABC.

And a great second example from the Article 29 Working Party:

• A controller outsources some operations to a call centre, and tells the call centre, instructs the call centre to present itself as the controller when calling the controller’s clients.
• Looking at the expectations of the clients and the way the controller presents themselves, leads to the conclusion that the outsourced company is a data processor on behalf of the controller.

What’s the problem?

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’.

• First, some suppliers don’t want to be just processors, or their business model isn’t around purely being processors.  They want to be controllers so they can do more with that personal data going forwards.
• Secondly, regardless of what you and your supplier may want, GDPR may say that you’re joint controllers.  This is a huge impact from GDPR – I think it’s been vastly underestimated.

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.

Summary

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:

• individual employees of legal entities aren’t the controller or processor, it’s their employer, the Limited Company, PLC or LLP, for example, and
• under recent case law, even if you never receive the personal data yourself, you’ll still be a controller if you decide the purposes and essential means of processing. This is quite an interesting point we’ll look at in more detail separately.

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!

Links

Keepabl’s Guide & Regulator Checklists on Controllers & Processors

UK ICO’s ‘At a Glance’ Guide to Controllers & Processors

UK ICO’s Detailed Guide to Controllers & Processors

UK ICO’s Data Protection Fee

European Commissioner FAQ on Controllers & Processors

Art 29 Working Party’s 2010 Guidance on Controllers & Processors under the EU’s 1995 Data Protection Directive

EDPS Guidelines on the Concepts of Controller, Processor and Joint Controllership under Regulation (EU) 2018/1725, November 2019