Skip to main content
Privacy Track
Category: Controller & Processor Roles

Controller-Processor Relationship

Also known as: Controller and Processor Relationship, Data Controller-Data Processor Relationship
Simply put

This is the working arrangement between two organisations handling the same personal data: the controller decides why and how the data is processed, while the processor simply acts on the controller's instructions. Because both parties handle the data but hold different responsibilities, their relationship must generally be set out in a written contract. This contract sets the rules for how the processor may use the data on the controller's behalf.

Formal definition

The controller-processor relationship describes the legal and operational arrangement in which a processor processes personal data on behalf of, and under the documented instructions of, a controller. The controller determines the purposes and means of the processing, while the processor acts on the controller's instructions and does not determine the purposes of the processing (though a processor may typically determine certain technical means of processing). Under EU and UK data protection guidance, this relationship must generally be governed by a binding written contract or other legal act that sets out the processing operations, the parties' respective obligations, and the processor's responsibilities. Note that role classification is fact-specific and turns on who actually decides the purposes and essential means of processing, rather than on how the parties label themselves; the required content and scope of the governing contract should be verified against the applicable provisions of the GDPR (or UK GDPR) and relevant supervisory authority guidance, and this definition does not address joint controllership, which is a distinct arrangement.

Why it matters

The controller-processor relationship sits at the heart of most modern data processing arrangements, because organisations rarely handle personal data entirely in-house. When a controller engages a processor to carry out processing on its behalf, both parties handle the same data but carry distinct responsibilities, and getting the allocation of those responsibilities right is essential to demonstrating accountability. Misclassifying a party's role, or failing to put the required arrangements in place, can leave gaps in responsibility that expose individuals to risk and expose organisations to regulatory scrutiny.

A recurring practical challenge is that role classification is fact-specific: it turns on who actually decides the purposes and essential means of the processing, not on how the parties describe themselves in a contract. An organisation labelled a processor may in fact be acting as a controller if it determines the purposes of the processing, and vice versa. Because both controllers and processors 'process' personal data in the broad sense (processing covering essentially any action taken in relation to personal data), the label alone does not settle the question, and each party's actual obligations flow from its true role rather than its chosen title.

Under EU and UK data protection guidance, a controller that engages a processor is generally obliged to put in place a binding written contract (commonly a data processing contract or agreement) governing the processing. This contract is the instrument through which the controller sets the rules for how the processor may use the data on its behalf. Failing to have such an arrangement in place, or having one that does not adequately set out the processing operations and the parties' obligations, is a common area of compliance weakness. The precise required content and scope should be verified against the applicable provisions of the GDPR or UK GDPR and relevant supervisory authority guidance.

Who it's relevant to

Data Protection Officers and compliance leads
DPOs and compliance teams are typically responsible for mapping which of the organisation's processing activities involve external processors, confirming the correct role classification for each, and ensuring that a binding written contract is in place before processing begins. Because classification is fact-specific and turns on who decides purposes and means, they should assess actual decision-making rather than relying on contractual labels, and verify the required contract content against applicable guidance.
Legal and contracting teams
Lawyers drafting or reviewing service agreements need to ensure that the governing contract sets out the processing operations, the means, and the parties' respective obligations, including the processor's responsibilities. They should also confirm that the assigned role reflects who actually determines the purposes and essential means, since a mislabelled party may in fact hold controller obligations.
Vendors and service providers acting as processors
Organisations that process personal data on behalf of another party need to understand that they are generally expected to act only on the controller's documented instructions and not to determine the purposes of the processing. Where a service provider in fact determines the purposes of processing, it may be acting as a controller and would carry the corresponding obligations, so it should assess its true role for each activity.
Controllers engaging third parties
Any controller that engages a processor to handle personal data on its behalf is generally obliged to enter into a data processing contract and to set the rules for how the processor may use the data. Controllers retain responsibility for determining the purposes and means of processing and should ensure that their instructions to processors are documented.

Inside Controller-Processor Relationship

Controller
The natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and means of the processing of personal data (Article 4(7) GDPR). The controller carries primary accountability for compliance with the data protection principles.
Processor
A natural or legal person, public authority, agency, or other body that processes personal data on behalf of the controller (Article 4(8) GDPR). A processor generally acts on the documented instructions of the controller and does not determine the purposes of processing.
Data Processing Agreement (DPA)
A binding contract or other legal act required under Article 28 GDPR that governs the relationship where a processor acts on behalf of a controller. It must set out the subject matter, duration, nature and purpose of processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller.
Documented instructions
The requirement, generally under Article 28, that a processor processes personal data only on the controller's documented instructions, including in relation to transfers to a third country, unless required to do otherwise by EU or member state law.
Article 28 mandatory clauses
Specific obligations that Article 28 typically requires the contract to address, such as confidentiality commitments, security measures under Article 32, conditions for engaging sub-processors, assistance to the controller with data subject rights and with obligations under Articles 32 to 36, deletion or return of data at the end of processing, and making available information to demonstrate compliance and allow audits.
Sub-processor arrangements
Where a processor engages another processor, Article 28 generally requires prior specific or general written authorisation from the controller and the flow-down of equivalent data protection obligations to the sub-processor, with the initial processor typically remaining liable to the controller for the sub-processor's performance.
Joint controllers (distinction)
Where two or more controllers jointly determine the purposes and means of processing, they are joint controllers under Article 26 and must use an arrangement, rather than an Article 28 processor contract. This is distinct from a controller-processor relationship and depends on a factual assessment of who determines purposes and means.
Allocation of accountability
Under the accountability principle, the controller is generally responsible for ensuring and demonstrating compliance, while the processor has its own direct statutory obligations under the GDPR in addition to its contractual duties. Responsibilities should be allocated in a manner that reflects each party's actual role.

Common questions

Answers to the questions practitioners most commonly ask about Controller-Processor Relationship.

Is a processor liable in the same way as a controller under the GDPR?
No, though this is a common misconception. The controller and processor are distinct roles with different responsibilities. The controller determines the purposes and means of processing and generally bears primary accountability, including for demonstrating compliance with the data protection principles. A processor acts on the controller's documented instructions and has its own set of direct obligations under the GDPR, but these are narrower in scope. A processor can, however, become a controller in its own right if it steps outside the controller's instructions and starts determining purposes and means. The precise allocation of liability is context-dependent and should be assessed against the specific facts and the current text of the Regulation.
Does having a contract in place automatically make a party a processor?
No. A party's classification as a controller or processor is determined by the factual reality of who decides the purposes and means of the processing, not merely by how a contract labels the parties. A contract may describe a party as a processor, but if that party in practice determines why and how personal data is processed, it may be a controller or a joint controller regardless of the label. Regulatory guidance has emphasised this functional, fact-based approach. Parties should therefore assess the actual roles and verify the position against current guidance, as regulator interpretations can differ on borderline arrangements.
What should a written arrangement between a controller and processor typically cover?
Where a controller engages a processor, the GDPR generally requires a binding written arrangement (a data processing agreement) governing the processing. Such an arrangement typically sets out the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subjects, and the obligations and rights of the controller. It also commonly addresses matters such as processing only on documented instructions, confidentiality commitments, security measures, conditions for engaging sub-processors, assistance with data subject rights and with the controller's own obligations, and arrangements for return or deletion of data at the end of the service. The specific required content should be checked against the relevant article of the current Regulation text, and note that a Data Processing Agreement is distinct from a Data Protection Impact Assessment.
How should a processor handle engaging a sub-processor?
A processor generally should not engage another processor (a sub-processor) without prior authorisation from the controller, which may be specific or general. Where general authorisation applies, the processor typically must inform the controller of intended changes so the controller has an opportunity to object. When a sub-processor is engaged, the same or equivalent data protection obligations from the controller-processor arrangement should generally flow down to the sub-processor. The processor commonly remains responsible to the controller for the sub-processor's performance of its obligations. Practitioners should verify the applicable requirements against the current Regulation text, as the detailed mechanics can vary in practice.
What steps help clarify roles where an arrangement may involve joint controllership rather than a controller-processor relationship?
Where two or more parties jointly determine the purposes and means of processing, they may be joint controllers rather than a controller and processor. To clarify roles, parties should analyse who actually decides the why and how of the processing, document that analysis, and reflect the conclusion in an appropriate arrangement setting out respective responsibilities, including for transparency and responding to data subject rights. Because the boundary between joint controllership and a controller-processor relationship can be difficult to draw and has been shaped by case law and regulatory guidance, parties should assess borderline cases carefully and note that regulator interpretations may diverge.
What practical measures can a controller use to demonstrate that a processor provides sufficient guarantees?
A controller generally should use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets the Regulation's requirements and protects data subjects' rights. In practice, controllers commonly evaluate this through due diligence on the processor's security posture, review of relevant certifications or codes of conduct where available, contractual commitments, and ongoing oversight such as audits or reporting. What is sufficient is subject to assessment based on the nature, scope, context, and risks of the processing, so the appropriate measures will vary case by case and should be reviewed periodically.

Common misconceptions

The distinction between controller and processor is decided by whatever label the parties put in their contract.
The classification is determined by a factual assessment of who actually decides the purposes and means of processing, not merely by contractual labelling. A party described as a processor that in practice determines purposes may be treated as a controller, and regulators and case law look to the substance of the arrangement.
A processor bears no direct liability under the GDPR because it only follows the controller's instructions.
While the controller generally holds primary accountability, a processor has its own direct obligations under the GDPR and can be subject to enforcement and liability, particularly where it acts outside documented instructions or fails to meet its statutory duties.
Any exchange of personal data between two organisations automatically creates a controller-processor relationship requiring an Article 28 DPA.
The relationship depends on the facts. Depending on who determines purposes and means, parties may instead be separate independent controllers or joint controllers under Article 26, in which case an Article 28 processor contract is not the appropriate instrument. The correct classification should be assessed case by case.

Best practices

Assess the actual roles of each party by analysing who determines the purposes and means of the processing, rather than relying on the contractual label, and document the reasoning behind the classification.
Ensure any controller-processor arrangement is supported by a written Article 28 contract that addresses the mandatory elements, including subject matter, duration, nature and purpose, categories of data and data subjects, and the processor's obligations.
Define clear, documented instructions for the processor and establish a process for handling situations where the processor considers an instruction to be unlawful.
Set out sub-processor authorisation procedures, flow down equivalent data protection obligations, and maintain an up-to-date record of engaged sub-processors.
Specify security measures, breach notification support, and assistance with data subject rights and with obligations under Articles 32 to 36, and address deletion or return of data at the end of the engagement.
Review whether the arrangement may instead be a joint controllership under Article 26 or a controller-to-controller relationship, and reassess classifications periodically as processing activities and regulatory guidance evolve, verifying positions against the current official text.