Controller vs Processor
Last reviewed: · By Victor Humenhuk (CIPP/E certified)
A controller decides why and how personal data is processed; a processor only processes it on the controller's documented instructions. The label follows the facts, not the paperwork: whoever actually determines the purposes and the essential means is the controller, even if a contract says otherwise. Both roles carry direct GDPR obligations and both can be fined, but only the controller must identify a lawful basis, answer data subject rights requests, set retention periods and notify the supervisory authority of a breach. A processor that starts determining the purposes and essential means is considered a controller for that processing under Article 28(10).
What is the difference between a controller and a processor?
Article 4(7) defines the controller as the body that, alone or jointly with others, determines the purposes and means of processing. Article 4(8) defines the processor as the body that processes personal data on behalf of the controller. Everything else follows from that one distinction.
| Question | Controller (Art 4(7)) | Processor (Art 4(8)) |
|---|---|---|
| Decides why the data is processed | Yes - this is the defining feature | No - acts on documented instructions |
| Decides the essential means | Yes | No (may decide non-essential means) |
| Needs an Article 6 lawful basis | Yes | No - relies on the controller's basis |
| Answers data subject rights requests | Yes | Must assist the controller (Art 28(3)(e)) |
| Records of processing | Art 30(1) - full record | Art 30(2) - shorter, controller-focused record |
| Breach reporting | Notifies the supervisory authority under Art 33(1) | Notifies the controller without undue delay (Art 33(2)) |
| Security | Art 32 applies directly | Art 32 applies directly |
| Engaging a sub-contractor | Free to choose processors | Needs prior specific or general written authorisation (Art 28(2)) |
| Transparency to individuals | Articles 13 and 14 apply | Not responsible for the notice |
Both must have a written contract meeting the mandatory terms in Article 28(3), and both are directly bound by the transfer rules in Chapter V.
Who decides the 'purposes and means'?
The EDPB's Guidelines 07/2020 on the concepts of controller and processor split 'means' into two categories, and this split is the single most useful test for exam scenarios and for real vendor triage.
- Essential means - what data is collected, how long it is kept, who it is disclosed to, which categories of data subject are affected. These decisions belong to the controller.
- Non-essential means - practical implementation choices such as which hardware or software to use, the detailed configuration of security measures, or the choice of data centre within agreed limits. These can be left to the processor without changing its role.
A supplier that chooses the tooling is still a processor. A supplier that decides what the data will be used for is not. The contractual label carries very little weight: the EDPB and supervisory authorities assess the actual influence each party has over the processing.
When does a processor become a controller?
Article 28(10) is explicit: if a processor infringes the GDPR by determining the purposes and means of processing, it is considered a controller in respect of that processing. In practice this happens when a supplier reuses customer data for its own product analytics, model training, benchmarking or marketing without being instructed to.
The other route out of a clean two-party split is joint controllership under Article 26, where two parties jointly determine purposes and means. In Wirtschaftsakademie (C-210/16) the operator of a Facebook fan page was a joint controller with the platform for the audience statistics it configured, and in Fashion ID (C-40/17) a website embedding a social plug-in was a joint controller for the collection and transmission of visitor data - but not for what the plug-in provider did with it afterwards. Joint controllership can be unequal, and it does not require equal access to the data.
Chains matter too: a sub-processor must be placed under the same data protection obligations as the original processor, which remains fully liable to the controller for its sub-contractor's failures.
How does liability differ under Article 82 and Article 83?
Under Article 82(2), a controller is liable for damage caused by processing that infringes the GDPR. A processor is liable only where it has not complied with obligations specifically directed at processors, or where it acted outside or contrary to the controller's lawful instructions. Article 82(4) then makes each of them liable for the entire damage towards the data subject where both are involved, with a right of recourse between them under Article 82(5).
| Exposure | Controller | Processor |
|---|---|---|
| Article 82 civil liability | Broad - for any infringing processing | Narrow - processor-specific duties or acting outside instructions |
| Lower fine tier (Art 83(4)): up to €10m or 2% of total worldwide annual turnover, whichever is higher | Applies (e.g. Art 25, 30, 32, 33) | Applies (e.g. Art 28, 30(2), 32, 33(2)) |
| Higher fine tier (Art 83(5)): up to €20m or 4%, whichever is higher | Applies (principles, lawful basis, rights, transfers) | Applies mainly to the Chapter V transfer rules and non-compliance with an authority's order |
| Practical risk driver | Choosing a poor processor; no valid basis | Acting beyond instructions; weak security; unauthorised sub-processing |
Read the roles alongside the full notes on controller versus processor roles and liability.
Related study notes
- Controller vs Processor - Roles and Liability
- The Five Building Blocks of 'Controller'
- The Processor and the Article 28 Contract
- Joint Controllership
- Module 3 · Controller vs processor
Frequently asked questions
Can the same organisation be both a controller and a processor?
Yes, and most are. The role is assessed per processing activity, not per company. A payroll bureau is normally a processor for the client's payroll run and a controller for its own staff records, its own accounting obligations and its own marketing list.
Does the contract decide who is the controller?
No. The EDPB treats controllership as a factual question determined by who exercises real influence over the purposes and essential means. A contract that calls a party a processor while that party decides what the data is used for will not survive scrutiny, although the contract is still strong evidence when it matches reality.
Can a processor be fined directly by a supervisory authority?
Yes. Under the GDPR, processors have direct statutory obligations - security under Article 32, records under Article 30(2), sub-processor authorisation and contract terms under Article 28, breach notification to the controller under Article 33(2), and the Chapter V transfer rules - and can be fined for breaching them.
What happens if a processor uses client data for its own purposes?
It is considered a controller for that processing under Article 28(10). It then needs its own lawful basis, must meet the transparency duties in Articles 13 and 14 for that use, and is exposed to the higher fine tier as well as being in breach of its Article 28 contract.
Test yourself
Try the free CIPP/E practice questions, or read the full CIPP/E study guide - free.