What is the simplest way to tell controller from processor?

Ask who decides why the data is processed and how. If your company chose to collect the data and decides what happens to it, you are the controller for that data. If you are handling someone else’s data purely on their instructions, to deliver a service to them, you are the processor. The controller sets the purpose; the processor follows it. A processor who starts using the data for its own purposes has, for that use, become a controller and taken on a controller’s obligations.

Is a subprocessor a different kind of entity from a processor?

No - "subprocessor" is not a separate species, it is a position in a chain. A subprocessor is just a processor that another processor has engaged to help carry out the work. AWS hosting a SaaS product is a subprocessor from the SaaS customer’s point of view, but AWS is itself a processor in its direct relationship, and it has its own subprocessors below it. The label depends entirely on who is instructing whom in a given relationship.

Can one company be a controller and a processor at the same time?

Yes, routinely. A SaaS company is a processor for the customer data its B2B clients entrust to it - it handles that data on their instructions. But it is a controller for its own data: its employees’ HR records, its prospects in its CRM, its own website analytics. The roles are assigned per data flow, not per company, so you assess each stream of personal data on its own terms.

Does the contract decide my role?

Not by itself. A contract can document a role, but if the facts contradict the label, the facts win. The EDPB and supervisory authorities look at who actually determines the purposes and means of processing. Calling yourself a processor in a DPA does not make you one if you are in reality deciding how the data gets used. This is why the role assessment should be done on substance first, then reflected in the contract - not assumed from it.

Why does the role distinction matter so much?

Because every obligation flows from it. Controllers carry the primary accountability - lawful basis, transparency, data-subject rights, breach notification to the authority. Processors carry the Article 28 duties - process only on instructions, secure the data, use subprocessors only with authorisation, assist the controller. Get the role wrong and you either take on duties that are not yours or, more dangerously, miss the ones that are. The subprocessor rules in particular only make sense once you know where you sit in the chain.

Guide / Roles

Updated 25 May 2026

Controller, processor, subprocessor: who is who

GDPR assigns every party in a data flow one of three roles, and the role determines the obligations. A controller decides why and how personal data is processed; a processor acts on the controller’s instructions; a subprocessor is a processor that another processor engages. Getting the role right matters because every Article 28 duty flows from it.

Key facts

01A controller determines the purposes and means of processing - the why and the how.
02A processor processes personal data on the controller’s behalf, under instructions, without using it for its own ends.
03A subprocessor is simply a processor engaged by another processor - the role is relative to who instructs whom.
04The same company can be a controller, a processor, and (through its vendors) rely on subprocessors all at once, depending on the data flow.
05Role is determined by what you actually do with the data, not by what a contract labels you - regulators look at the substance.

§ I

The three roles

GDPR does not treat everyone who handles personal data the same way. It assigns each party in a data flow a role, and the role decides which obligations apply. There are three:

-Controller - the party that determines the purposes and means of processing. In plain terms, the controller decided to collect the data and decides what is done with it. It carries the primary accountability under GDPR.
-Processor- a party that processes personal data on the controller's behalf, under the controller's instructions, without authority to use it for its own purposes. A SaaS vendor handling its customers' data is the classic example.
-Subprocessor - a processor that another processor engages to help carry out the work. It is not a different kind of entity; it is a position in the chain.

§ II

How to tell which one you are

The deciding question is always the same: who determines the purposes and means of processing? Whoever decides why the data is processed and how is the controller for that data. Whoever is simply carrying out those decisions, to deliver a service, is the processor.

Two consequences follow. First, a processor that starts using the data for its own ends - say, to train a model it sells, or to build its own marketing list - has, for that use, become a controller, and inherits a controller's obligations. Second, the “sub” in subprocessor is purely relational: AWS is a subprocessor from the point of view of a SaaS company's customer, a processor in its own direct relationship, and a controller for its own corporate data - all at once. The label depends on which relationship you are looking at.

§ III

One company, several roles

Because roles attach to data flows rather than companies, a single SaaS business holds several at once. Walk through a typical one:

-As a processor: for the customer data its B2B clients entrust to it. The clients are the controllers; the SaaS company acts on their instructions.
-As a controller:for its own employees' HR records, its sales prospects in its CRM, and its own marketing analytics. Here it decides the purposes and means.
-Relying on subprocessors: the cloud host, email service, and payment processor it engages to deliver the product all sit below it as subprocessors of the customer data.

This is why mapping your data flows matters more than memorising definitions. The same vendor can be a controller in one relationship and a subprocessor in another, and your obligations shift accordingly.

§ IV

Why the distinction drives everything

The role is not a formality - it determines the entire obligation set. Controllers carry the primary duties: establishing a lawful basis, being transparent with data subjects, honouring access and erasure rights, and notifying the supervisory authority of breaches. Processors carry the Article 28 duties: process only on documented instructions, secure the data, engage subprocessors only with authorisation, and assist the controller with its obligations.

A contract can document these roles, but it cannot override the facts. The EDPB and supervisory authorities assess the substance - who really decides the purposes and means - so calling yourself a processor does not make you one if you are behaving like a controller. Get the role right first; the subprocessor rules, the DPA terms, and the notification obligations all follow from it.

FAQ

Frequently asked questions

What is the simplest way to tell controller from processor?: Ask who decides why the data is processed and how. If your company chose to collect the data and decides what happens to it, you are the controller for that data. If you are handling someone else’s data purely on their instructions, to deliver a service to them, you are the processor. The controller sets the purpose; the processor follows it. A processor who starts using the data for its own purposes has, for that use, become a controller and taken on a controller’s obligations.
Is a subprocessor a different kind of entity from a processor?: No - "subprocessor" is not a separate species, it is a position in a chain. A subprocessor is just a processor that another processor has engaged to help carry out the work. AWS hosting a SaaS product is a subprocessor from the SaaS customer’s point of view, but AWS is itself a processor in its direct relationship, and it has its own subprocessors below it. The label depends entirely on who is instructing whom in a given relationship.
Can one company be a controller and a processor at the same time?: Yes, routinely. A SaaS company is a processor for the customer data its B2B clients entrust to it - it handles that data on their instructions. But it is a controller for its own data: its employees’ HR records, its prospects in its CRM, its own website analytics. The roles are assigned per data flow, not per company, so you assess each stream of personal data on its own terms.
Does the contract decide my role?: Not by itself. A contract can document a role, but if the facts contradict the label, the facts win. The EDPB and supervisory authorities look at who actually determines the purposes and means of processing. Calling yourself a processor in a DPA does not make you one if you are in reality deciding how the data gets used. This is why the role assessment should be done on substance first, then reflected in the contract - not assumed from it.
Why does the role distinction matter so much?: Because every obligation flows from it. Controllers carry the primary accountability - lawful basis, transparency, data-subject rights, breach notification to the authority. Processors carry the Article 28 duties - process only on instructions, secure the data, use subprocessors only with authorisation, assist the controller. Get the role wrong and you either take on duties that are not yours or, more dangerously, miss the ones that are. The subprocessor rules in particular only make sense once you know where you sit in the chain.

This guide is general information only and does not constitute legal advice. For advice on your specific situation, consult a qualified legal professional.

Your turn

Keep your subprocessor register current - automatically.

Registora hosts your register on your own domain, monitors every upstream provider for changes daily, and drafts the customer notification when one updates.

Start your register →Audit your site