GDPR Data Controller vs Processor: Roles, Responsibilities, Risk

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.

This guide explains the legal definitions, the decision criteria from the EDPB and CJEU, and the practical implications for contracts and liability. For the joint controller scenario, see our Article 28 vs Article 26 RGPD. For data processor specifics, what is a data processor.

Key takeaways

• Controller: determines purposes and means of processing — bears primary accountability.
• Processor: processes on behalf of controller, on documented instructions — bears direct obligations under Article 28.
• The qualification is determined by factual reality, not contract labels (CJEU Wirtschaftsakademie, Fashion ID).
• Three tests: who decides the purpose? Who decides essential means? Who derives a separate benefit from the processing?
• A joint controller scenario (Article 26) exists when two parties jointly determine purposes and means — see our joint controller guide.

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

• Maintain ROPA (Article 30(1))
• Conduct DPIA where required (Article 35) — see Article 35 RGPD
• Implement appropriate technical and organizational measures (Article 32)
• Notify breaches to authority within 72h (Article 33)
• Communicate breaches to data subjects when high risk (Article 34)
• Honor data subject rights (Articles 12-23)
• Determine lawful basis (Article 6) — see legitimate interest
• Sign DPAs with all processors (Article 28)

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

For details, see our Article 28 vs Article 26 RGPD guide.

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

Legiscope audits vendor contracts to determine controller/processor classification automatically: parses DPAs, identifies clauses indicating autonomous purpose or essential-means determination, flags joint controller scenarios. For a SaaS with 30+ vendors, the audit takes minutes.

For related context: Article 28 RGPD complete guide, DPA template, vendor audit checklist, data privacy compliance guide.

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.