Controller or processor? A practical role test for GDPR data processing (2026)

A vendor is not a processor just because the contract calls it one. The role follows the decisions made about a specific processing activity: why the data is used, and who controls the important choices about how it is used.

That distinction decides who must provide privacy information, choose the lawful basis, answer rights requests, assess processors, maintain records, and carry the accountability burden. It also explains why the same company can be a processor for one service and a controller for another.

Start with the processing activity, not the company

Article 4(7) of the GDPR defines a controller as the person or organisation that, alone or jointly with others, determines the purposes and means of processing personal data. A processor processes personal data on behalf of the controller. Processing covers ordinary operations such as collection, storage, consultation, use, disclosure, and deletion. 1

The unit of analysis is therefore not "the vendor" or "the partnership." It is the processing activity.

A cloud provider may process customer records on a retailer's instructions. The same provider may be a controller for its own billing records, security investigations, abuse prevention, or product-improvement dataset. A software company may be a processor when it transcribes calls for a customer, then a controller when it uses a separate dataset to train its own model.

The European Data Protection Board calls these functional concepts. The parties' actual activities determine their roles; a formal label in a contract is evidence of the arrangement, but it does not settle the question. 2

That is the first practical rule: draw the data flow and split it into distinct purposes and operations before assigning a role.

The two questions that do most of the work

Ask these questions about each processing activity:

Why is this processing happening? Who decided the purpose or outcome?
Who decides the important means? Who chooses the elements that shape whose data is processed, what data is used, how long it is retained, who receives it, or how the operation works?

The organisation that determines the purpose is usually the controller. It may outsource the work and never see the raw data. EDPB guidance gives the example of a company commissioning market research: the company decides what information it needs and what questions will be asked, while the research provider performs the collection and analysis. The commissioning company remains a controller even if it receives only statistical results. 3

A processor can make technical choices without becoming a controller. It might select a suitable database engine, configure a security tool, or decide which internal workflow will meet the controller's instructions. The dividing line is whether those choices are merely implementation details or whether they determine the purpose and essential features of the processing.

This is why "the vendor chose the software" is not enough to establish controllership. Nor is "the customer does not control every technical setting" enough to establish it. The question is whether the vendor has an independent purpose or has taken control of essential means.

A role test for a new service or project

Use this screen before procurement signs a data-processing agreement or product launches a new data flow.

1. Name the purpose in a verb

Avoid labels such as "platform operations," "business purposes," or "service improvement." They describe a system or a broad aspiration, not the reason for processing.

Write the outcome instead:

transcribe customer-support calls so the client can search them;
deliver fraud alerts to a bank's investigators;
retain invoices to meet accounting requirements;
train the supplier's general-purpose model;
measure product usage to decide which features to develop.

If one proposed service contains several of these purposes, analyse them separately. "Provide the service" may describe the customer-facing purpose while hiding a second purpose that benefits the supplier.

2. Find the purpose owner

Who decided that the processing should take place? Look for the decision that created the activity, not just the person who configured the system.

Useful evidence includes:

the product requirement or business case;
the privacy notice and lawful-basis assessment;
the fields selected for collection;
the population of people included;
retention and deletion rules;
the recipients and access model;
decisions the output will support.

The person or organisation that determines these matters is pointing toward controller status. The ICO's checklist uses similar indicators, including deciding what data to collect, which people to collect it about, the purpose or outcome, retention, disclosure, and the decisions made about individuals. 4

3. Separate essential means from implementation means

The means of processing include more than the brand of software. The important question is whether the choice changes the substance or risk of the operation.

Essential means can include:

which categories of people are included;
which data fields are collected or combined;
how long the data is kept;
who may access or receive it;
whether the data is used to make a decision about someone;
whether the activity involves profiling or sensitive data;
whether data is transferred to another country or another organisation.

Non-essential means can include technical implementation choices made within the agreed boundaries, such as a suitable storage architecture or the detailed configuration of a security control. The EDPB's example of a call centre makes the point: the call centre may choose particular software and detailed security measures while remaining a processor because it acts for the customer's purposes and under its instructions. 3

The distinction is contextual. A retention period may be an implementation detail in one tightly specified service, but a vendor's decision to keep customer data indefinitely for its own analytics is a different purpose and a material change in the processing.

4. Check for the vendor's own purpose

A processor acts on behalf of a controller. If the supplier uses the data for a purpose of its own, analyse that use independently.

For example, a company hires an AI service to summarise support tickets. Summarising the tickets under documented instructions may be processor activity. Using those tickets to train the provider's general model is a separate purpose. The ICO says an AI provider acting on a business's instructions is a processor for that service, but becomes a controller or joint controller for processing outside those instructions, such as building another model. 5

Do not let the phrase "service improvement" end the analysis. Ask what improvement means, whose objective it serves, which data is used, whether the supplier can refuse the customer's instructions, and whether the supplier could use the result across customers. Those answers may reveal a separate controller activity or a joint arrangement.

5. Assign the role per purpose

The result may be mixed:

Processing activity	Likely role of the customer	Likely role of the supplier
Store customer records so the customer can run its service	Controller	Processor
Send customer records to a regulator because the customer has a legal duty	Controller	Processor if it only transmits on instruction; otherwise assess the supplier's separate legal role
Use customer records to train the supplier's own model	Controller for the customer's disclosure and use; the supplier's role must be assessed on its own purpose	Often a separate controller for the training activity
Use supplier-collected data and the customer's data to run a jointly designed campaign	Possibly joint controller	Possibly joint controller
Use aggregated, genuinely anonymous statistics with no reasonable means of re-identification	The underlying personal-data roles end when the output is effectively anonymous; assess the original processing first	Depends on how the statistics were produced and whether the supplier used personal data for its own purpose

The table is a prompt for analysis, not an automatic answer. The factual design, applicable law, and identifiability of the output still matter.

When two organisations are joint controllers

Joint controllership is narrower than "we worked together." Under Article 26, two or more controllers are joint controllers when they jointly determine the purposes and means of the same processing. They must transparently allocate responsibilities, especially for information duties and data-subject rights, and make the essence of that arrangement available to people. A person can exercise GDPR rights against each joint controller regardless of the internal allocation. 1

The collaboration must concern the same processing purpose or a set of operations with a shared purpose. Merely exchanging the same data does not create joint controllership. The EDPB gives the example of a company sending employee salary data to tax authorities: both parties process the data, but each does so for its own purpose and under its own decision-making authority. They are separate controllers for their respective activities. 3

A shared database also proves little by itself. Several companies can use common infrastructure while deciding independently which records they contribute, who can see them, how long they retain them, and why they use them. In that arrangement, each company may be a separate controller and the infrastructure provider may be a processor.

The stronger joint-controller signal is mutual dependence: neither party's processing for the shared purpose would happen in the same way without the other's decisions. A co-branded event where two companies decide together whom to invite, how to send invitations, how to collect feedback, and what follow-up marketing to run is the kind of shared design the EDPB treats as joint controllership. 3

What the processor contract must accomplish

Once the factual analysis shows a controller-processor relationship, the contract is not a label-making exercise. It is the operating boundary.

Article 28 requires a binding written contract or other legal act. It must state the subject matter and duration, nature and purpose, types of personal data, categories of people, and the controller's rights and obligations. It must also require the processor to process data only on documented instructions, protect confidentiality, apply appropriate security, control sub-processors, assist with rights requests and compliance duties, return or delete data at the end, and provide information for audits. 1

The EDPB warns against a contract that merely repeats the GDPR. The agreement should explain how the parties will meet those duties for the actual activity: what data is involved, what security objectives apply, how instructions are issued, how rights requests are routed, how incidents are handled, and how changes are approved. 3

A practical contract review should ask:

Does the purpose match the product's actual use, including any telemetry, training, or benchmarking?
Are the data fields and categories of people specific enough to reveal the risk?
Are retention, deletion, access, transfers, and sub-processors controlled?
Can the customer give and preserve documented instructions?
Does the supplier have a clear route to flag an unlawful instruction?
Can the customer obtain the evidence it needs for rights requests, breaches, DPIAs, and audits?
Is a new supplier purpose prohibited, or has it been incorrectly buried in a broad service-improvement clause?

The contract cannot make an independent purpose disappear. Article 28(10) says that when a processor determines the purposes and means of processing in breach of the regulation, it is considered a controller for that processing. 1

Common mistakes

Treating the contract as the answer

A contract saying "processor" is useful evidence of the intended arrangement. It is not a substitute for examining what each party actually decides. Regulators look at the processing, not the comfort of the label.

Treating every technical choice as controllership

A supplier does not become a controller merely because it chooses a database, hires staff, or selects a security configuration within agreed boundaries. A processor needs operational freedom to implement instructions. The issue is whether the choice changes the purpose or essential means.

Treating every supplier as a processor

A supplier may have its own fraud-prevention, billing, legal-retention, or model-training purposes. These may be separate controller activities even if the supplier also processes data on the customer's behalf. Split the purposes instead of assigning one role to the whole commercial relationship.

Assuming joint controllership whenever data is shared

Two organisations can share data and remain separate controllers. Joint controllership requires joint determination of the purpose and means of the same processing, not just a transfer, common infrastructure, or commercial cooperation.

Looking only at who can see the raw data

Control does not require direct access. The EDPB says an organisation can be a controller when it determines the purpose and essential means of outsourced processing, even if it receives only statistical results. 3

Giving a processor a purpose and calling it an instruction

"Use the data to improve your service" may be a business objective for the supplier, not an instruction to perform a defined task for the customer. If the supplier decides what improvement means and reuses the data across customers, the arrangement needs a fresh role and lawfulness analysis.

The record worth keeping

For each processing activity, keep a short role memo with:

Purpose: the concrete outcome and the decisions it supports.
Operations: collection, storage, analysis, disclosure, profiling, deletion, and any linked operations.
Decision owners: who decided why the activity exists and who chose the essential means.
Data boundary: fields, combinations, people affected, sensitivity, and expected outputs.
Role conclusion: controller, separate controllers, joint controllers, or processor, with the factual reasons.
Contract path: the Article 28 agreement, data-sharing agreement, joint-controller arrangement, or other legal instrument required.
Change triggers: new purpose, new data source, new retention period, new recipient, new model use, or a material change in impact.

Review the memo when the product, vendor, data, or output changes. A role decision is not permanent merely because the supplier relationship is.

The useful question is not "Which label did procurement select?" It is "Who decided why this processing exists, and who controls the choices that shape its effect on people?" Answer that question per purpose, preserve the evidence, and the contract can reinforce the role instead of hiding a mismatch.

References

1
Regulation (EU) 2016/679, Article 4
data.europa.eu
2
EDPB, Guidelines 07/2020 on the concepts of controller and processor in the GDPR
edpb.europa.eu
3
EDPB, Guidelines 07/2020, paragraphs 20 and 45
edpb.europa.eu
4
ICO, A guide to controllers and processors
ico.org.uk
5
ICO, Previously asked questions: controllers and processors
ico.org.uk