Definition. Under GDPR Article 4: a controller is the entity that determines the purposes and means of processing personal data; a processor is the entity that processes data on behalf of the controller following its instructions. The controller decides “why” and “how” — the processor executes. The controller bears primary accountability under Article 5(2). The processor has direct obligations under Article 28 and is co-liable for breaches of its specific duties.
The controller-processor distinction is the most consequential classification under the GDPR. Controllers sign privacy notices, conduct DPIAs, manage data subject requests, and bear primary fines. Processors sign DPAs, follow controller instructions, and face fines for breaching processor-specific duties. Misclassifying a relationship — labeling a controller as a processor or vice versa — invalidates the legal architecture of the processing.
Key takeaways
1. Legal definitions (Article 4)
Controller (Article 4(7)): “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 (Article 4(8)): “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”.
The two definitions are mutually exclusive for a given processing activity: a party is either acting as controller (determining purposes and means) or as processor (acting on instructions). The same legal entity can be controller for some processing and processor for other processing — but never both for the same operation.
2. The decision criteria
EDPB Guidelines 07/2020 set out the criteria. Three questions:
2.1 Who determines the purpose?
The “purpose” is the why of the processing. If party B uses the data for its own purpose (analytics, marketing, profiling), B is a controller — not a processor. If B only uses the data to perform the contract for A, with no autonomous use, B is a processor.
Examples:
- Cloud provider hosting customer files → processor (no autonomous purpose)
- Analytics vendor that aggregates data across customers for benchmarks → joint controller (B has its own purpose)
- Email delivery vendor → processor (executes A’s purpose)
2.2 Who determines the essential means?
The “essential means” are the substantial decisions about how processing happens: categories of data collected, retention periods, recipients, security measures. Non-essential means (technical implementation, choice of algorithm) can be left to the processor without changing its qualification.
2.3 Who derives separate benefit?
A party that derives a benefit from the processing independent of the contract fees typically acts as a controller. Examples: receiving aggregated insights, building a customer profile usable elsewhere, monetizing the data via third parties.
3. The 8 most common scenarios
| # | Scenario | Qualification | Why |
|---|---|---|---|
| 1 | Customer uses cloud storage (AWS S3, Azure Blob) | AWS = processor | No autonomous purpose, executes contract |
| 2 | Customer uses CRM SaaS (Salesforce, HubSpot) | Vendor = processor | Standard scenario |
| 3 | Company uses Google Analytics (with data sharing on) | Joint controller | Google uses data for its own benchmarks |
| 4 | E-commerce uses Meta Pixel | Joint controller (Meta) | Meta uses conversion data for ad optimization |
| 5 | Company uses payment processor (Stripe) | Stripe = controller for fraud detection, processor for payment | Different processing activities |
| 6 | Company uses external accountant for bookkeeping | Accountant = controller for own legal duties, processor for client services | Mixed |
| 7 | Company uses external lawyer | Lawyer = independent controller | Has own legal mandate, secret professionnel |
| 8 | Company uses HR SaaS that aggregates anonymized salary benchmarks | Joint controller for benchmarks, processor for HR data | Mixed roles |
4. Contractual implications
Controller obligations
These flow from the general responsibility clause of GDPR Article 24:
Processor obligations
- Process only on documented instructions (Article 28(3)(a))
- Confidentiality of staff (Article 28(3)(b))
- Implement security measures (Article 28(3)©)
- Engage sub-processors only with controller authorization (Article 28(3)(d))
- Assist controller with data subject requests (Article 28(3)(e))
- Assist controller with breach notification, DPIA, prior consultation (Article 28(3)(f))
- Return or delete data at end of contract (Article 28(3)(g))
- Provide audit information (Article 28(3)(h))
- Maintain ROPA (Article 30(2))
- Notify controller of breaches (Article 33(2))
Joint controller obligations (Article 26)
- Sign joint controllership agreement determining respective responsibilities
- Make essence of the agreement available to data subjects
- Data subjects can exercise rights against either controller
5. Liability allocation
| Failure | Controller liable | Processor liable |
|---|---|---|
| Lack of lawful basis | ✅ | — |
| Inadequate privacy notice | ✅ | — |
| Failure to honor DSR | ✅ | Partial (must assist) |
| Inadequate security measures | ✅ | ✅ |
| Breach notification missed | ✅ | Partial (must notify controller) |
| Sub-processor without authorization | — | ✅ |
| Processing beyond instructions | — | ✅ (becomes controller for that processing) |
| Failure to maintain ROPA | ✅ | ✅ (each for their own) |
A processor that processes data beyond its instructions is deemed to be a controller for that processing (Article 28(10)) — losing the limited-liability protection of processor status. This is why processor SaaS vendors are extremely careful about “secondary use” of customer data.
6. Common misclassifications
“Our analytics partner is just a processor”
If the analytics vendor uses customer data to improve its own algorithms, builds aggregated benchmarks for other customers, or monetizes insights, it has its own purpose. Joint controller at best, independent controller at worst.
“Our payment gateway is a processor”
For the payment execution itself: yes, processor. But for fraud detection (where the gateway uses transaction data across all clients to train its model): joint controller.
“Our cloud provider’s sub-processors are not our problem”
Article 28(2) and 28(4) make the controller’s authorization required for sub-processors and make the original processor liable for sub-processor failures. Controllers must approve the sub-processor list and review the chain.
“We’re a processor for our customer, but we use the data to improve our service”
If “improvement” means using customer data to train models or build features for other customers, you’ve crossed into controller territory. Either segregate the improvement use under a separate consent or restructure the architecture.
7. The joint controller case (Article 26)
When two parties jointly determine purposes and means, neither is a pure processor. Article 26 requires a joint controllership agreement allocating respective responsibilities and making the essence of the agreement available to data subjects.
Common joint controller scenarios:
- Website operator + social media platform (Facebook Pixel, LinkedIn Insight Tag)
- Two companies running a joint marketing campaign
- A merchant + a marketplace (Amazon, Shopify) for certain processing
- A school + a sports federation for student athlete data
8. Practical decision tree
Question 1: Does the recipient process the data on its own behalf
(own purpose, own benefit beyond contract fees)?
YES → Recipient is a controller (independent or joint)
NO → Continue to question 2
Question 2: Does the recipient determine essential means
(data categories, retention, recipients, security level)?
YES → Recipient is a controller (independent or joint)
NO → Continue to question 3
Question 3: Are the controller's instructions documented in a contract
satisfying Article 28?
YES → Recipient is a processor
NO → Compliance gap — either sign Article 28 contract or treat
recipient as independent controller
9. Tooling
Official sources: the EDPB Guidelines 07/2020 on the concepts of controller and processor, the ICO guidance on controllers and processors, and Articles 4, 24 and 28 of Regulation (EU) 2016/679 on EUR-Lex.
Conclusion
The controller-processor distinction is not about company size, contract value, or relationship duration — it’s about whether the recipient has its own purpose and determines essential means. Misclassification costs: the wrong contract structure, the wrong liability allocation, and exposure to DPA reclassification with retroactive sanctions. Apply the three-question test rigorously, especially for analytics, marketing platforms, and payment partners.
FAQ
What’s the simplest test for controller vs processor?
Three questions: (1) does party B process the data for its own purpose? (2) does B determine essential means (categories, retention, recipients, security level)? (3) does B derive a benefit independent of contract fees? If yes to any, B is a controller, not a processor.
Can a single entity be both controller and processor?
For different processing activities, yes — common with companies that handle their own employee data (controller) and provide services to customers (processor). For the same processing activity, no — the qualifications are mutually exclusive.
What happens if a processor exceeds the controller’s instructions?
Article 28(10) GDPR provides that the processor becomes a controller for that excess processing — losing the limited-liability protection of processor status and incurring full controller obligations and fines.
Are cloud providers always processors?
For pure cloud storage and compute: yes. But cloud providers offering analytics services, AI/ML APIs that use customer data for model training, or aggregated benchmarks across customers may be joint controllers for those specific services.
Do I need a DPA with a joint controller?
You need a joint controllership agreement under Article 26, which allocates respective responsibilities. This is different from a DPA (which is for processors). The two are not interchangeable. Some relationships require both — DPA for processor services, joint controllership agreement for joint operations.