Data controller vs data processor under GDPR

A practical guide to the difference between data controllers and data processors under UK GDPR, including joint controllers, Article 28 contracts, sub-processors, and how to determine which role you're in.

The distinction between a data controller and a data processor is the foundation of how GDPR allocates responsibility. The two roles carry different obligations, different liabilities, and different relationships with the people whose data is being processed. Getting the classification wrong leaves you with the wrong contracts, the wrong policies, and potential enforcement exposure on both sides of the relationship.

This guide covers what each role means, how to tell them apart in practice, joint controller situations, what Article 28 contracts must include, and the decision logic for working out which role applies to any given processing activity.

The short answer

Under UK GDPR:

• A controller decides why and how personal data is processed. The controller carries primary responsibility for compliance with the regulation.
• A processor acts on the controller's documented instructions and only processes data for the controller's purposes.

If you set up a customer database, you are the controller of that data. If you hire an email marketing platform to send campaigns to the database, the platform is your processor for that activity. The same organisation can be a controller for some activities and a processor for others — the classification depends on the specific processing, not on the organisation as a whole.

GDPR definitions

Article 4 of the UK GDPR sets out the formal definitions.

Controller is defined 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.

Processor is defined as a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller.

Two things to notice in these definitions:

First, the test for controllership is "determines the purposes and means". Both elements matter. "Purposes" means the why — what the data is going to be used for. "Means" means the how — the essential elements of how the processing is carried out, like which data is collected, how long it is kept, and who it is shared with. A party that decides only the technical means (which encryption algorithm to use, which database engine) without setting the purposes is usually a processor.

Second, the test for being a processor is acting "on behalf of" a controller. The processor is doing the controller's work — not its own — and must follow the controller's instructions.

A processor that decides on its own to use the data for a different purpose stops being a processor for that activity. Article 28(10) is explicit: if a processor determines the purposes and means of processing in breach of its contract, it is treated as a controller in respect of that processing — and is exposed to the full set of controller obligations and liabilities.

The role of an organisation is determined activity by activity. The same supplier might be your processor for one piece of work and a controller in its own right for another, often in the same commercial relationship.

Real-world examples

A few worked examples to illustrate the line.

A school using an attendance tracking system

The school decides which pupils' attendance to track, why, and what to do with the resulting reports. The school is the controller. The software company supplying the system is acting on the school's instructions and is the processor for that processing.

A bank commissioning customer satisfaction research

The bank tells a research agency to survey a sample of its retail customers and gives the agency the customer contact list. The agency designs the questions, runs the survey, and presents the findings. Even though the agency is taking some operational decisions, the purposes are set by the bank and the agency is acting on the bank's behalf — so the agency is the processor and the bank is the controller. If the agency decided to keep the data afterwards for its own market research purposes, it would become a controller for that new processing.

A gym hiring a printer for promotional flyers

If the gym sends the printer a list of members to address the flyers to, the printer processes that data only to print and post the flyers. The printer is the processor, the gym is the controller.

An accountant filing tax returns for a client business

The accountant exercises independent professional judgement, has its own legal and regulatory obligations to comply with, and decides the means of meeting them. The accountant is a controller in its own right for the personal data in the accounts — not a processor — because it is not simply following the client's instructions.

A payroll bureau processing employee salaries

Here the analysis depends on the contract. A pure-play payroll processor that calculates and pays salaries entirely on the employer's instructions is a processor. A payroll bureau that exercises independent decisions about, say, statutory deductions or pension contributions may shade towards being a joint controller.

The pattern across these is that the controller question turns on who decides the why and the essential how, not on who carries out the technical work.

Joint controllers

Article 26 of the UK GDPR covers joint controllers. Two or more organisations are joint controllers when they jointly determine the purposes and means of processing — when they make those decisions together rather than one party deciding and the other following instructions.

Joint controllers must establish, in a transparent manner, who is responsible for which compliance obligations. The arrangement should be set out in writing and should determine, in particular, who handles the right to be informed and who responds to other rights requests. The essence of the arrangement must be made available to the people whose data is being processed.

In practice, joint controllership often arises in:

• Co-marketing partnerships where two businesses share leads and contact customers jointly.
• Loyalty schemes operated jointly by a retailer and a payment provider.
• Research partnerships where two organisations contribute data and share the analysis.

Joint controllers are jointly and severally liable in many circumstances — a data subject can claim against either party, and disputes about allocation are sorted out between the controllers afterwards. This makes the written arrangement under Article 26 particularly important.

Article 28 contracts (Data Processing Agreements)

Whenever a controller engages a processor, Article 28 of the UK GDPR requires the relationship to be governed by a written contract — a Data Processing Agreement, often called a DPA. The contract must include specific provisions.

Article 28(3) lists the mandatory contents:

• The subject matter and duration of the processing.
• The nature and purpose of the processing.
• The type of personal data and the categories of data subjects involved.
• The obligations and rights of the controller.

And eight specific obligations the processor must agree to:

1. Process the personal data only on documented instructions from the controller, including for international transfers.
2. Ensure that anyone authorised to process the data is bound by an obligation of confidentiality.
3. Take all measures required by Article 32 — security of processing.
4. Respect the conditions for engaging another processor (sub-processors), including obtaining prior authorisation.
5. Assist the controller by appropriate technical and organisational measures in responding to data subject rights requests.
6. Assist the controller in meeting its obligations under Articles 32 to 36 — security, breach notification, DPIAs, and prior consultation with the ICO.
7. At the controller's choice, delete or return all personal data at the end of the contract.
8. Make available to the controller all information necessary to demonstrate compliance with Article 28, and allow for audits.

Without a written contract that covers these specific items, both controller and processor are in breach. The ICO has issued reprimands and fines specifically for missing or inadequate DPAs.

A few practical points often missed:

• The contract has to be in writing, but Article 28(9) confirms that "writing" includes electronic form.
• The controller's instructions in the contract should be capable of supporting day-to-day processing without further authorisation for each transaction.
• The processor must give the controller the information necessary to demonstrate compliance — including security documentation. Asking for it should never be controversial.

For more on the security side of the contract, see our seven principles guide and our data breach guide.

Sub-processors

If a processor wants to engage another processor — a sub-processor — to carry out specific processing on the controller's behalf, Article 28(2) requires the processor to have prior specific or general written authorisation from the controller. With general authorisation, the processor must inform the controller of any intended changes and give the controller a chance to object.

The processor must impose on the sub-processor the same data protection obligations that apply between the controller and the processor — "back-to-back" terms, in commercial shorthand. If the sub-processor fails, the processor remains fully liable to the controller for the sub-processor's performance.

In practice, the sub-processor chain in a typical SaaS deal looks something like: customer (controller) → SaaS provider (processor) → cloud host (sub-processor) → infrastructure provider (sub-sub-processor). Each link in the chain needs Article 28-compliant terms.

Decision tree: which role are you?

A practical sequence for any specific processing activity:

1. Are you processing personal data? If no, GDPR is not in scope and the question doesn't arise.
2. Are you the only organisation involved in this activity? If yes, you are a controller for it.
3. If multiple organisations are involved, who decides the purposes — the why? The organisation deciding the purposes is the controller (or joint controller if the decision is shared).
4. Who decides the essential means — the categories of data, the retention period, who it's shared with? These decisions also drive controllership.
5. What about the organisation actually doing the technical processing? If it is acting solely on the documented instructions of another party, it is the processor. If it exercises independent decisions about purposes, it is a controller (or potentially a joint controller).
6. Test the answer. A processor that decides to keep data after the contract ends, or to use it for a new purpose, has stopped being a processor for that activity and become a controller — exposing it to the full controller liability under Article 28(10).

Apply this activity by activity. A SaaS supplier might be your processor for its main service and a controller in its own right for billing, account management, or service-improvement analytics — sometimes in the same contract. Document the role for each activity in your ROPA.

For where this fits in the wider compliance picture, see our ROPA guide and hub guide to UK GDPR.

Frequently asked questions

Can the same organisation be both controller and processor?

Yes, frequently. Most organisations are controllers for some activities (their own staff data, their own customer records) and processors for others (work they do on behalf of clients). The role is determined activity by activity.

Do I need a written contract with my processor?

Yes. Article 28 requires a written contract covering specific provisions, including the eight processor obligations. Without it, both parties are in breach.

Is my IT provider a controller or processor?

It depends on what they do. If they host your systems on your instructions and do not use the data for their own purposes, they are processing on your behalf and are your processor. If they decide independently to use the data — for analytics, profiling, or improvements to their own products — they become a controller for that processing.

What is a sub-processor?

A sub-processor is another organisation that the processor engages to carry out part of the processing on the controller's behalf. The controller must authorise the use of sub-processors, and the processor remains fully liable for their performance.

Are employees processors?

No. Employees acting within the scope of their duties are part of the controller (or processor) that employs them, not separate processors in their own right.

What happens if a processor exceeds the controller's instructions?

Under Article 28(10), the processor is treated as a controller in respect of that processing — and faces the full set of controller obligations and the higher tier of fines.