GDPR’s compliance obligations do not fall equally on every party that touches personal data. They are allocated according to the role each party plays in the processing relationship. A controller bears primary accountability. A processor carries direct but more limited obligations. A joint controller shares accountability proportionally. Getting role classification right is one of the most structurally important decisions in building a GDPR compliance programme — because every obligation, every contractual requirement, and every enforcement pathway flows from it.
This article explains the legal definitions of each role, the obligations each carries, the contractual requirements that govern processor relationships, and the increasingly complex question of role classification in digital supply chains where the boundaries between controller and processor are not always clear.
The Controller: Primary Accountability
A controller is defined in Article 4(7) 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. The controller is the entity that decides why data is processed and how. It is the primary bearer of GDPR accountability.
The controller’s obligations under GDPR are comprehensive. It must identify and document a lawful basis for every processing activity. It must implement the six data protection principles in Article 5. It must respond to data subject rights requests within statutory timelines. It must implement appropriate technical and organisational security measures under Article 32. It must maintain a Record of Processing Activities (RoPA) under Article 30. It must conduct DPIAs for high-risk processing under Article 35. It must notify the supervisory authority of personal data breaches within 72 hours under Article 33. It must implement privacy by design and by default under Article 25. And under Article 5(2), it must be able to demonstrate compliance with all of these obligations.
| KEY IDEA | The controller is accountable — not just responsible. Accountability under Article 5(2) means the controller must not only comply with GDPR’s requirements but be able to demonstrate that compliance to a supervisory authority. Every compliance decision should be made with documentation in mind: not because documentation is the goal, but because it is the evidence of genuine compliance. |
The Processor: Acting on Instructions
A processor is defined in Article 4(8) as a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller. A processor does not determine the purpose of processing — that is fixed by the controller. A processor may make technical implementation decisions within the parameters set by the controller, but the essential decisions about why data is processed and what data subjects it relates to remain with the controller.
GDPR introduced direct obligations on processors that did not exist under the 1995 Directive. Under Article 28, processors must: process personal data only on documented instructions from the controller; ensure that persons authorised to process the data are subject to confidentiality; implement appropriate technical and organisational security measures; respect the conditions for engaging sub-processors; assist the controller in fulfilling data subject rights; assist the controller in meeting security, breach notification, DPIA, and DPO obligations; delete or return personal data at the end of the relationship; and provide the controller with all information necessary to demonstrate compliance.
Processors are directly liable to supervisory authorities and can be fined independently of the controller for violations of their processor-specific obligations — particularly security failures, unauthorised sub-processing, and failure to notify the controller of breaches. A processor that experiences a personal data breach affecting controller data must notify the controller without undue delay to enable the controller to meet the 72-hour notification obligation.
The Data Processing Agreement (Article 28)
Article 28(3) requires that processing by a processor be governed by a binding contract — the Data Processing Agreement (DPA) — that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. The DPA must be in writing, which includes electronic form.
Article 28(3) also specifies the mandatory clauses every DPA must include: the processor must only act on the controller’s documented instructions; must ensure confidentiality of authorised personnel; must implement appropriate security measures; must engage sub-processors only with prior specific or general written authorisation from the controller (and flow down the same obligations to sub-processors); must assist the controller with data subject rights; must assist the controller with security and breach obligations; must delete or return data at the end of the relationship; and must make available all information necessary to demonstrate compliance and allow for and contribute to audits.
| IMPORTANT | A DPA is mandatory before any processor touches personal data on behalf of a controller. Operating without a DPA is a GDPR violation for both the controller and the processor. Supervisory authorities have fined both parties for processing relationships without adequate contractual documentation. Standard Contractual Clauses for controller-processor relationships, published by the European Commission, provide an approved DPA template that satisfies the Article 28(3) requirements. |
General written authorisation for sub-processing — where the controller agrees in advance that the processor may engage sub-processors, subject to notification and the right to object — is common in SaaS relationships. The processor must inform the controller of any intended changes regarding the addition or replacement of sub-processors, giving the controller the opportunity to object. Where the controller objects, the processor must either not engage the sub-processor or notify the controller that it cannot provide the service without the sub-processor, allowing the controller to terminate.
Sub-Processors: Flowing Down the Chain
A sub-processor is an entity engaged by a processor to carry out processing activities on behalf of the controller. The processor is responsible to the controller for the sub-processor’s compliance: under Article 28(4), where a sub-processor fails to fulfil its data protection obligations, the original processor remains fully liable to the controller.
In practice, most SaaS providers operate as processors that engage a chain of sub-processors: cloud infrastructure providers, logging and monitoring services, customer support platforms, and similar infrastructure. Controllers should require processors to maintain and share a current list of sub-processors, and should review sub-processor lists as part of their ongoing vendor management programme. A material change in sub-processor arrangements — particularly a change in the geographic location of processing — may affect the organisation’s international transfer analysis.
Joint Controllers: Shared Purpose, Shared Accountability
Joint controllers are defined in Article 26 as two or more controllers that jointly determine the purposes and means of processing. The test is whether two parties are genuinely co-determining why and how personal data is processed — not whether they are in a commercial relationship, not whether they exchange data, but whether they share the decision-making over purpose and means.
The CJEU’s judgment in Fashion ID (2019) significantly expanded the concept of joint controllership in digital contexts. It held that a website operator embedding a Facebook ‘Like’ button was a joint controller with Facebook for the collection and transmission of personal data that occurred when the button was loaded — even though the website operator had no access to the data and no control over what Facebook subsequently did with it. The sharing of responsibility arose at the moment of joint determination of the collection, even without shared access to the data collected.
| KEY IDEA | Embedding third-party tracking scripts, social media pixels, advertising tags, and analytics tools on a website may create joint controller relationships with the tool providers. Organisations should assess their use of third-party digital technologies against the joint controller test — not assume that using a third-party tool automatically makes them a processor or a data subject of the third party. |
Article 26(1) requires joint controllers to determine their respective responsibilities under GDPR by means of an arrangement between them. The arrangement must specify who is responsible for providing the Article 13/14 transparency information to data subjects, who handles data subject rights requests, who maintains the RoPA for the joint processing, and who is responsible for security measures. The essence of the arrangement must be made available to data subjects.
Joint controllers are each individually liable to supervisory authorities and to data subjects for compliance with GDPR. A data subject can exercise their rights against any or all joint controllers. The internal arrangement between joint controllers does not affect the data subject’s ability to enforce their rights against any one of them.
Role Classification in Complex Digital Supply Chains
The controller/processor/joint controller distinction is straightforward in simple relationships: a company (controller) engages a payroll bureau (processor) to run payroll. It becomes significantly more complex in modern digital ecosystems where data flows through multiple parties, each making different types of decisions about the data.
A SaaS CRM provider that processes customer data on behalf of its business clients is typically a processor. But if it also uses that data for its own purposes — to train its AI models, to improve its product, to identify cross-selling opportunities across its customer base — it becomes a controller for those additional purposes. A cloud hosting provider that simply stores encrypted data on behalf of a client is typically a processor. But if it also analyses the data for its own network optimisation or security purposes, it may be a controller for that analysis.
Platform businesses face particular classification complexity. A marketplace that processes the data of both sellers and buyers, making operational decisions about how that data is used for matching, pricing, and dispute resolution, may be a controller in its own right rather than a processor acting for either party. A data broker that acquires personal data from multiple sources and processes it to create enriched datasets for sale operates as a controller.
| IMPORTANT | Role classification must be determined by examining actual conduct — what decisions the party actually makes about the processing — not by how the relationship is described in contracts. A contract that describes a party as a ‘processor’ does not make it a processor if its conduct meets the controller or joint controller definition. The EDPB’s Guidelines 07/2020 on the concepts of controller and processor provide the authoritative analysis framework. |
Practical Consequences of Misclassification
Misclassifying a processing relationship has material compliance consequences in both directions. An organisation that treats itself as a processor when it is actually a controller fails to establish lawful bases, does not maintain a RoPA, does not respond to data subject rights, and does not notify the supervisory authority of breaches — all significant GDPR violations. An organisation that treats itself as a controller when it is a processor may fail to execute a DPA, may act outside the controller’s instructions, and may process data for unauthorised purposes.
The contractual consequences of misclassification are also significant. A DPA that correctly identifies the parties’ roles provides the controller with audit rights, instruction authority, breach notification obligations, and deletion rights. If the relationship is misclassified and no DPA is in place, the controller has no contractual mechanism to enforce the processor’s obligations and may face liability for the processor’s non-compliance.
Conducting a Role Classification Assessment
For each processing relationship, organisations should conduct a role classification assessment that addresses three questions. First, who determines the purpose of the processing — why is this data being processed, and who made that decision? If the organisation decided the purpose, it is at minimum a controller for that processing. If the purpose was determined by another party and this organisation processes only on that party’s instructions, it is a processor.
Second, who determines the essential means of processing — what data is collected, from whom, for how long it is retained, who it is shared with? If this organisation makes those decisions, it is a controller regardless of what the contract says. If another party dictates all of these elements and this organisation only makes technical implementation decisions within those constraints, it is a processor.
Third, is there joint determination — are two parties together deciding the purpose and essential means? If so, joint controllership applies and the Article 26 arrangement must be executed. Role classification should be documented for each material processing relationship and reviewed whenever the nature of the relationship changes.
| BITLION INSIGHT | The processor/controller distinction is not static. A relationship that begins as a processor relationship — where the SaaS provider processes data purely on client instructions — can evolve into a joint controller or independent controller relationship as the provider begins using client data for its own purposes. Organisations should build role classification review into their contract renewal cycles and data governance assessments, not treat it as a one-time determination at contract inception. |