Controller vs Processor Guide: GDPR Roles and Joint Control

Every data processing agreement, security schedule and breach notification clause rests on one earlier decision, whether each party is a controller, a joint controller or a processor, and that decision is often made by whoever drafts the contract first rather than by looking at what each party actually does. Under the GDPR and UK GDPR the role follows the facts, not the label, so a wrong label leaves the wrong party answering data subject requests, notifying regulators and carrying liability. This guide explains how to determine the role from the facts, how joint controllership works under Article 26, what changes in contracts and security obligations for each role, and the mistakes that show up in audits and disputes. It is written for privacy, security, procurement and legal teams who negotiate supplier and partner agreements. It summarises the GDPR position as of November 2026 and is not legal advice.

Key takeaways

The role follows the facts. A controller determines the purposes and means of processing; calling a party a processor in the contract does not make it one if it decides why the data is used.
Processors still decide technical details. Choosing systems, storage and security measures within the controller's instructions does not make a supplier a controller.
Joint control needs an Article 26 arrangement, not an Article 28 contract. Joint controllers must set out who does what, make its essence available to data subjects, and accept that individuals can exercise rights against each of them.
Stepping outside instructions changes the role. Under Article 28(10) a processor that determines purposes and means becomes a controller for that processing, with controller liability.
Liability is shared towards individuals. Under Article 82(4) each controller or processor involved in the same processing can be held liable for the entire damage, then recover shares from the others.

The three roles in one table

	Controller	Joint controllers	Processor
Definition	Alone or with others determines the purposes and means of processing (Art. 4(7))	Two or more controllers that jointly determine purposes and means (Art. 26(1))	Processes personal data on behalf of the controller (Art. 4(8))
Decides	Why data is processed, whose data, what data, lawful basis, retention, disclosures	The same, together, for the jointly determined operations	Technical and organisational details within the controller's instructions
Core legal instrument	Its own accountability records and notices	Arrangement under Art. 26, essence available to data subjects	Contract or other legal act under Art. 28(3)
Data subject rights	Answers them	Rights can be exercised against each controller (Art. 26(3))	Assists the controller
Breach notification	To the supervisory authority and, where required, individuals	Allocated in the arrangement; each remains accountable	To the controller "without undue delay" (Art. 33(2))
Records	Art. 30(1) record of processing activities	Each keeps its own Art. 30(1) record	Art. 30(2) record of categories of processing per controller
Liability to individuals	For damage from infringing processing (Art. 82(2))	Each for the entire damage, with recovery between them (Art. 82(4), (5))	Only where it breached processor obligations or acted outside or against lawful instructions (Art. 82(2))

How to determine the role

Start with the processing activity, not the organisation. One company can be a controller for its own HR data, a processor for the customer data it hosts, and a joint controller with a marketing partner, all at once. Assess each processing activity separately and record the outcome in the record of processing activities (see the Data Mapping and ROPA Guide).

Controller indicators

The UK Information Commissioner's Office (ICO) suggests asking which organisation decides:

to collect personal data in the first place, and the lawful basis for doing so;
what types of personal data to collect, and about which individuals;
the purpose or purposes the data will be used for;
whether to disclose the data, and to whom;
what to tell individuals about the processing, and how to respond to rights requests;
how long to retain the data, and whether to make non-routine changes to it.

Whoever makes these decisions is a controller for that processing. If two parties make them together, they are likely joint controllers.

What a processor may still decide

A processor is not a passive tool. The ICO lists decisions a processor may take within its contract without becoming a controller, including which IT systems or methods to use, how to store the data, the details of the security measures, how to transfer and retrieve data, how to adhere to a retention schedule, and how to delete or dispose of data. The ICO describes these as "day-to-day operational decisions". The EDPB's Guidelines 07/2020 on the concepts of controller and processor (final version adopted 7 July 2021) draw a similar line between the essential means, which belong to the controller, and non-essential, practical means that may be left to a processor.

Signals that a "processor" is really a controller

Own purposes: the supplier uses the data for its own product improvement, analytics, model training, benchmarking or marketing, beyond what the customer instructed.
Own professional obligations: the party has independent duties over the data, such as an accountant's or lawyer's regulatory duties, so it does not simply follow a client's instructions.
Own relationship with individuals: it decides what to tell data subjects or how to handle their requests.
Take-it-or-leave-it terms that set purposes: standard terms are not decisive on their own, but terms that reserve the supplier's right to use data for its own ends point to controllership for that use.

Article 28(10) sets the consequence: if a processor infringes the Regulation by determining the purposes and means of processing, it "shall be considered to be a controller in respect of that processing". The ICO adds that such a processor carries the same liability as a controller for that processing.

Joint controllers and Article 26

Article 26(1) says: "Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers." Joint control arises from shared decisions, not from simply exchanging data. Two organisations that each process the same data for their own separate purposes are separate controllers, not joint controllers, as the ICO notes.

Court of Justice of the EU case law has shaped the concept. In Wirtschaftsakademie (C-210/16, 2018), the administrator of a Facebook fan page was held to be a joint controller with Facebook for visitor data. In Jehovan todistajat (C-25/17, 2018), a religious community was a joint controller for data its members collected door to door. In Fashion ID (C-40/17, 2019), a website operator embedding a social plug-in was a joint controller for the collection and transmission of visitor data, but not for what the social network did with it afterwards. Two practical points follow: joint controllers do not need equal responsibility or equal access to the data, and joint control can be limited to specific stages of a processing chain.

What the arrangement must cover

Allocation of duties: Article 26(1) requires the joint controllers to set out their respective responsibilities transparently, in particular for data subject rights and the information duties under Articles 13 and 14, unless Union or Member State law sets them.
Contact point: the arrangement may designate a contact point for data subjects.
Reflect reality: under Article 26(2) it must duly reflect each party's role and relationship with data subjects, and its essence must be made available to them. The ICO recommends including the main points in privacy information.
No limit on individuals: under Article 26(3), whatever the arrangement says, individuals may exercise their rights against each controller.

The ICO notes that a contract is not strictly required, but a written arrangement is the only practical way to show the allocation. In practice, add: who notifies breaches and within what internal deadline, which security measures each party runs, how lawful basis and any DPIA are shared (see the DPIA Guide), and how costs of compensation are recovered between parties.

Contract consequences of each role

Relationship	Instrument	Security terms	Common clauses to check
Controller to processor	Article 28(3) contract or other legal act (data processing agreement)	Processor must take all measures required by Art. 32; security schedule describes them	Documented instructions, confidentiality, sub-processor authorisation, assistance, deletion or return, audits
Processor to sub-processor	Same data protection obligations flowed down (Art. 28(4))	Same measures as the head contract	The initial processor "shall remain fully liable to the controller" for the sub-processor
Joint controllers	Article 26 arrangement	Allocated per party; each remains accountable for Art. 32	Rights handling, notices, breach notification lead, contact point, recovery of compensation
Independent controllers sharing data	Data sharing agreement (no specific GDPR article mandates its form)	Each applies its own Art. 32 measures; agree transfer security	Purpose limits, onward disclosure, retention, breach cooperation

For transfers outside the EEA, the role also selects the transfer mechanism: the European Commission's standard contractual clauses for international transfers (Implementing Decision (EU) 2021/914) come in modules for controller to controller, controller to processor, processor to processor and processor to controller transfers. Picking the wrong module because the role was mislabelled is a common defect. See the International Data Transfers Map.

The clause-by-clause content of a processor contract, including sub-processor approval and audit rights, is covered in the GDPR Article 28 Processor Guide; this page stops at the role decision and its consequences.

Liability and enforcement by role

Compensation: under Article 82(2) a controller involved in processing is liable for damage caused by processing that infringes the Regulation; a processor is liable only where it has not complied with obligations directed specifically to processors or has acted outside or contrary to the controller's lawful instructions.
Joint and several liability: Article 82(4) provides that where more than one controller or processor is involved in the same processing and responsible for the damage, each "shall be held liable for the entire damage". Article 82(5) lets the party that paid recover the other parties' shares.
Fines: breaches of controller and processor obligations under Articles 8, 11, 25 to 39, 42 and 43 can attract fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher (Art. 83(4)(a)). Breaches of the principles, data subject rights and transfer rules can reach EUR 20 million or 4% (Art. 83(5)).
Processors in their own name: processors carry direct duties, including keeping an Article 30(2) record, implementing Article 32 security, notifying the controller of breaches without undue delay, and complying with the transfer rules. The ICO notes that individuals can claim directly against a processor.

For how regulators have treated security failures by each role, see GDPR Enforcement Decisions on Security Failures Guide.

Worked scenarios

Scenario	Likely role	Reasoning
Cloud infrastructure provider hosting a customer's database	Processor	Processes on the customer's behalf; chooses data centre and security details within its service terms
Payroll bureau running payroll to the employer's instructions	Processor	Employer decides whose data, what and why; bureau decides how to run its systems
SaaS vendor using customer data to train its own general models	Processor for the service; controller for its own training use	The training purpose is the vendor's own, so it needs its own lawful basis and transparency
Two brands running a co-branded prize draw	Joint controllers	Both decide purposes and means of entrant data (ICO example)
Website embedding a third-party social plug-in that sends visitor data	Joint controllers for collection and transmission only	Fashion ID: joint control limited to the stages jointly determined
External auditor or law firm receiving client data	Usually a controller	Own professional obligations over the data
Managed security service provider analysing a client's logs	Usually a processor	Processes logs for the client's security purpose; becomes a controller for any reuse of the logs for its own threat intelligence product

Where identity and security fit

Roles also decide who must secure the machine identities that reach personal data. A processor typically runs service accounts, API keys and OAuth integrations into the controller's systems, and those credentials are part of the Article 32 measures the processor must apply and the controller must verify. Name them in the security schedule: which non-human identities the processor uses, how they are scoped, rotated and revoked at contract end. For joint controllers, state which party owns each integration credential. See the GDPR Compliance Guide for Security Teams and the Third-Party Access Guide.

How to implement a role assessment

List processing activities per relationship: for every supplier and partner, write down each activity involving personal data, not just the contract.
Apply the decision questions: for each activity, record who decides the purposes and the essential means, with evidence (service description, terms, statements of work).
Check for own-purpose use: read the supplier's terms and privacy notice for analytics, training, benchmarking or marketing rights over customer data.
Classify and record: controller, joint controller, processor or independent controller, per activity, in the ROPA and the supplier register.
Select the instrument: Article 28 contract, Article 26 arrangement or data sharing agreement, plus the matching transfer module.
Allocate operational duties: breach notification paths, rights handling, security measures, sub-processor approval and exit.
Re-test on change: new features, new data uses or new sub-processors can change the role; tie reassessment to the change notification clauses.

Pilot on the ten suppliers with the most personal data before rolling out to the whole register. Where an assessment changes an existing role, keep the old contract in force until the replacement is signed rather than terminating it first.

Decision guidance

Processor or independent controller: if the supplier only needs the data to deliver your service, push for processor terms and remove own-use rights. If it genuinely needs its own purposes (fraud screening networks, credit reference), accept controller status and a data sharing agreement.
Joint or separate controllers: joint control fits shared campaigns, shared platforms and co-designed processing. Where each party simply hands data to the other for its own purposes, separate controllers with a sharing agreement is cleaner.
Small organisations: use standard processor terms from major suppliers, but still read the own-use clauses; a short role register is enough.
Large organisations: centralise role decisions in privacy, with a template per role, and make the role a mandatory field in procurement and the TPRM register.
UK operations: UK GDPR follows the same role definitions; the ICO notes its processor guidance is under review following the Data (Use and Access) Act, so check for updates. See the UK GDPR and Data Protection Act 2018 Guide.

Detection and measurement

Role coverage: percentage of suppliers handling personal data with a documented role per processing activity.
Instrument match: percentage of relationships where the signed instrument (Art. 28, Art. 26 or sharing agreement) matches the recorded role.
Own-use clauses: number of processor contracts that still grant the supplier own-purpose rights.
Arrangement transparency: percentage of joint controller arrangements whose essence appears in privacy information.
Reassessment on change: share of supplier change notifications that triggered a role check.

Common failure patterns

Label by template: every supplier gets the same data processing agreement, including auditors and partners that are controllers in their own right.
Hidden own-use rights: a processor contract is signed while the supplier's general terms allow it to use customer data for product improvement or model training.
Joint control without an arrangement: co-branded campaigns and shared platforms run with no Article 26 allocation, so rights requests and breach notifications fall between the parties.
Arrangement hidden from individuals: the essence of the joint controller arrangement never reaches the privacy notice.
Wrong transfer module: controller to processor clauses signed for what is in fact a controller to controller transfer.
Assuming the processor carries all security: the controller remains accountable for choosing a processor that gives sufficient guarantees and must verify them.

Framework mapping

Framework	Reference	Relevance
GDPR / UK GDPR	Arts. 4(7), 4(8), 24, 26, 28, 29, 30, 33(2), 82, 83	Role definitions, accountability, joint control, processor contracts and liability
EDPB	Guidelines 07/2020	Concepts of controller and processor
ISO/IEC 27001:2022	Annex A 5.19, 5.20, 5.34	Supplier relationships, security in supplier agreements, privacy and protection of PII
ISO/IEC 27701	Controller and processor specific guidance	Privacy information management for PII controllers and processors
NIST CSF 2.0	GV.SC-05, GV.RR-02	Supplier requirements in contracts; roles and responsibilities established

Practitioner checklist

Assess roles per processing activity, not per organisation.
Record who decides purposes and essential means, with evidence.
Search supplier terms for own-purpose rights before signing processor terms.
Use an Article 26 arrangement for every joint controllership and publish its essence.
Match the transfer clause module to the actual role.
Name the processor's non-human identities and their controls in the security schedule.
Allocate breach notification and rights handling explicitly in every instrument.
Re-check the role when a supplier changes features, data use or sub-processors.

Standards and references

Related NHI Mgmt Group resources: GDPR Article 28 Processor Guide · GDPR Compliance Guide for Security Teams · Data Mapping and ROPA Guide · Third-Party Risk Management Guide. This guide summarises the GDPR and UK GDPR rules on controller, joint controller and processor roles and is not legal advice.

Controller vs Processor Guide: How to Decide GDPR Roles and What Each Role Means in Contracts