Every obligation in the General Data Protection Regulation (GDPR) attaches to a role. Whether your organization acts as a controller, a processor, or a sub-processor for a given flow of personal data decides which articles bind you, which contracts you need, who answers to data subjects, and who notifies the supervisory authority when something goes wrong. Role classification is therefore the first question in any GDPR analysis — everything downstream depends on getting it right.
The roles are functional. The European Data Protection Board (EDPB) is explicit in its Guidelines 07/2020 on the concepts of controller and processor that classification follows the factual circumstances of the processing, not the labels the parties chose. Calling a vendor a "processor" in a contract does not make it one if, in practice, it decides why and how the data is used.
This article defines the three roles with software-as-a-service (SaaS) examples, covers joint controllership briefly, and explains why misclassification is one of the more expensive mistakes a privacy program can make.
The controller: deciding purposes and means
Article 4(7) of the GDPR defines the controller as the natural or legal person which, alone or jointly with others, determines the purposes and means of the processing of personal data. Purposes are the why: what the processing is meant to achieve. Means are the how — and on the EDPB's analysis, the controller must decide the essential means, such as which data is processed, about whom, for how long, and who may access it, while technical details can be left to a processor.
In SaaS terms: a company that adopts a customer-relationship tool and decides which prospect data goes in, what it is used for, and when it is deleted is the controller of that data. Controllership does not require possession — the data may live entirely on the vendor's servers. Deciding is what counts.
The controller carries the broadest obligations: establishing a lawful basis, providing transparency information, handling data subject rights, notifying personal data breaches to the supervisory authority, running data protection impact assessments where required, and demonstrating all of it under the accountability principle of Article 24.
The processor: acting on documented instructions
Article 4(8) defines the processor as the person or body which processes personal data on behalf of the controller. The processor is a separate organization that handles the data to deliver a service, within the boundaries the controller sets. Article 28(3)(a) requires it to process only on the controller's documented instructions, and Article 29 reinforces that anyone acting under the processor may process only as instructed.
The SaaS vendor hosting your customer records is the standard example: it stores, transmits, and retrieves the data solely to provide the contracted service. Processors have their own direct obligations — a written contract under Article 28, records of processing under Article 30(2), security measures under Article 32, and notifying the controller without undue delay after becoming aware of a personal data breach.
The boundary matters most at its edge. A vendor that starts using customer personal data for its own purposes — building its own marketing lists from customer content, for example — stops being a processor for that use and becomes a controller of it, with every controller obligation attached, including the need for its own lawful basis. The EDPB treats this as a direct consequence of the functional approach: acting outside the controller's instructions for your own ends means you have determined new purposes and means.
The sub-processor: a processor engaged by a processor
The GDPR does not use the word "sub-processor"; Articles 28(2) and 28(4) speak of a processor engaging "another processor." Industry shorthand calls that other processor a sub-processor: an organization the processor brings in to perform part of the processing it owes the controller. The SaaS vendor's cloud hosting provider, email delivery service, and support-ticketing platform are the usual examples.
Three rules govern the position. First, the processor needs the controller's prior written authorization — specific or general — before engaging a sub-processor. Second, the processor must impose the same data protection obligations it owes the controller onto the sub-processor by contract. Third, if the sub-processor fails, the initial processor remains fully liable to the controller. The sub-processor normally has no direct contract with the controller; its duties are mirrored down the chain. For a fuller treatment, see our guide to what a subprocessor is.
Joint controllers in brief
Article 26 covers the case where two or more controllers jointly determine the purposes and means of processing. Joint controllers must set out, in a transparent arrangement, who handles which obligations — transparency duties and data subject rights in particular — and make the essence of that arrangement available to data subjects, who can exercise their rights against either controller regardless of what the arrangement says.
Joint controllership arises from converging decisions, not shared infrastructure. Two organizations that co-design a joint event registration flow and both use the attendee data for their own follow-up are likely joint controllers of that flow. By contrast, your SaaS vendor processing your data on your instructions is your processor, not your joint controller, even though you both touch the same records. The distinction is about who decides, not who processes.
Why role classification matters
Different obligations under Articles 24 and 28
The controller's world is Article 24: implementing appropriate measures to comply and to demonstrate compliance across lawfulness, transparency, rights, breaches, and impact assessments, with records kept under Article 30(1). The processor's world is Article 28: a mandatory contract, documented instructions, sub-processing conditions, assistance duties, and its own records under Article 30(2). Breach duties diverge the same way — controllers notify the supervisory authority and, when the risk is high, the affected individuals; processors notify their controller. Liability under Article 82 follows the split: a controller can be liable for damage caused by infringing processing generally, while a processor is liable where it breached processor-specific obligations or acted outside lawful instructions.
What misclassification costs
Get the role wrong and the errors compound quietly. The wrong contract gets signed — a controller treated as a processor is handed instructions it will not follow, while a processor treated as an independent controller escapes the Article 28(3) commitments the controller was obliged to impose. Breach response misroutes, because the party that should have notified the supervisory authority assumed the other one would. Records of Processing Activities (RoPA) are built on the wrong template. Privacy notices tell data subjects a story that does not match reality. And because the classification is functional, none of this is cured by the label: a regulator or court re-classifies based on facts, and the paperwork becomes evidence of the mistake rather than protection against it.
When one company holds both roles
Role classification is per processing activity, not per company — and most SaaS vendors hold both roles at once. A vendor is a processor for the customer content it hosts on instructions, and simultaneously a controller for its own employee data, its billing and account records, its security logs, and its marketing operations. The same duality appears inside corporate groups, where a parent running shared IT services can be a processor for its subsidiaries.
This is more than trivia for anyone reading vendor paper. A well-drafted Data Processing Agreement (DPA) states which processing it covers, and the scope clause repays close reading: carve-outs where the vendor processes "for its own purposes" mark exactly where the vendor steps out of the processor role and into controllership — and where your instructions stop reaching.
The sub-processing chain
Stack the roles and you get the chain that defines modern SaaS: controller to processor under an Article 28(3) contract, processor to sub-processor under mirrored Article 28(4) contracts, each engagement authorized under Article 28(2), with the duty to inform the controller of intended changes and give it the opportunity to object. Each party is a processor within its own context, and the protections at the top must survive intact to the bottom.
For controllers, the chain has a practical consequence: you cannot contract with everyone in it, so your oversight runs through due diligence on your direct processor, your authorization decisions, and the visible surface of the chain — the vendor's published subprocessor list and its change notifications. What belongs in the contract at the top is covered in our guide to GDPR Article 28 DPA requirements.
Where DPAFlow fits in
For legal and privacy teams, the recurring burden is not defining the roles — it is keeping sight of a chain that changes under general authorization. DPAFlow monitors vendor subprocessor lists, DPA pages, and trust-center pages on a scheduled, recurring basis, detects changes, and records them with dated evidence, so the review and the decision trail start from facts rather than memory.
If your legal team owns vendor data protection terms, the DPAFlow legal use case shows how monitoring and documented review fit into that workflow.