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

Processing on Behalf of a Controller

Also known as: Processing on behalf of the controller, Controller-processor processing
Simply put

Processing on behalf of a controller is when one organisation (the processor) handles personal data for another organisation (the controller), acting only on that controller's instructions rather than for its own purposes. For example, a company may use an external service provider to process personal data that the company has decided to collect and use. In most cases this relationship must be governed by a written contract between the two parties.

Formal definition

Processing on behalf of a controller describes the activity of a processor, defined as a natural or legal person, public authority, agency or other body that processes personal data on behalf of the controller and acts solely under the controller's documented instructions. This relationship is central to the controller-processor distinction: the processor does not determine the purposes and means of the processing but carries them out as directed. Where a controller engages a processor, a written data processing contract is generally required to govern the terms and conditions of the processing; under the UK GDPR and EU GDPR this obligation is commonly associated with Article 28 (readers should verify the precise article against the current official text). An organisation may act as both controller and processor for different processing activities, and where it does, it should ensure its systems and procedures distinguish between the personal data processed in each capacity. Note that the precise allocation of controller versus processor status is a factual and functional assessment that can be subject to regulatory guidance and may vary between the EU and UK regimes and across member state implementations.

Why it matters

The concept of processing on behalf of a controller underpins how accountability is allocated across the many organisations that touch personal data in a typical supply chain. When one organisation decides why and how personal data should be used and another simply carries out that processing under instruction, the law treats them differently: the controller bears primary responsibility for determining the purposes and means, while the processor must generally confine itself to acting on documented instructions. Getting this distinction wrong can leave both parties uncertain about their obligations and can expose an organisation to compliance risk if it assumes it is a mere processor when its conduct in fact makes it a controller.

The requirement for a written contract is a practical anchor for this relationship. According to guidance from EU and UK data protection authorities, controllers who engage processors are generally obliged to enter into a data processing contract governing the terms and conditions of the processing. This contract is the instrument through which the controller documents its instructions and through which the processor accepts its constraints. Without it, the relationship may not be adequately governed, and responsibilities for matters such as security and the scope of permitted processing may be left ambiguous.

Because the allocation of controller versus processor status is a factual and functional assessment rather than a matter of self-labelling, organisations should assess their real role in each processing activity. The same organisation may be a controller for some activities and a processor for others, and regulators have noted that where this is the case the organisation should ensure its systems and procedures distinguish between the personal data processed in each capacity. Note that regulatory guidance on this assessment continues to develop and the position may vary between the EU and UK regimes and across member state implementations; readers should verify the current guidance and article references against the official text.

Who it's relevant to

Data Protection Officers and Compliance Leads
DPOs and compliance leads need to map which processing activities their organisation carries out as a controller and which it carries out as a processor, since the obligations differ. Where the organisation acts in both capacities, they should ensure systems and procedures distinguish the personal data processed in each role, and confirm that appropriate written contracts are in place with processors.
Privacy and Commercial Lawyers
Lawyers drafting and reviewing supplier arrangements are responsible for the written data processing contract that generally must govern controller-processor relationships, commonly associated with Article 28 of the UK and EU GDPR. They also advise on the factual and functional assessment of whether a party is a controller or processor, which cannot be settled by the label the parties choose.
Engineers and Systems Architects
Those building and operating data systems help implement the technical separation needed when an organisation processes personal data in different capacities, and help ensure that processing carried out on behalf of a controller stays within the controller's documented instructions rather than being repurposed.
Service Providers and Vendors
Organisations offering data-handling services to others should determine whether they are acting as a processor, meaning they act solely under the controller's instructions, or whether their conduct makes them a controller. This assessment affects their obligations and the contract terms they should expect to accept.

Inside Processing on Behalf of a Controller

Processor Role
A processor is a natural or legal person, public authority, agency, or other body that processes personal data on behalf of the controller. The processor acts on the controller's documented instructions and does not determine the purposes and means of processing, which distinguishes it from a controller.
Documented Instructions
The processor generally processes personal data only on the controller's documented instructions, including in relation to transfers to a third country, unless required to do so by Union or Member State law. Where such a legal requirement applies, the processor should typically inform the controller before processing, subject to any legal prohibition on doing so.
Data Processing Agreement (Article 28)
Processing by a processor is generally governed by a contract or other legal act under Union or Member State law that binds the processor to the controller. This instrument sets out the subject matter, duration, nature and purpose of the processing, the type of personal data, categories of data subjects, and the obligations and rights of the controller. It should not be confused with a Data Protection Impact Assessment (Article 35).
Sufficient Guarantees
A controller is expected to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets the requirements of the Regulation and ensures the protection of data subject rights. Adherence to an approved code of conduct or certification mechanism may be used as an element to demonstrate such guarantees.
Sub-processor Engagement
A processor generally should not engage another processor without the prior specific or general written authorisation of the controller. Where a sub-processor is engaged, equivalent data protection obligations are typically imposed on it by contract, and the initial processor generally remains liable to the controller for the sub-processor's compliance.
Assistance to the Controller
The processor typically assists the controller in fulfilling obligations such as responding to data subject requests, ensuring security of processing, notifying personal data breaches, and, where relevant, supporting data protection impact assessments and prior consultation, taking into account the nature of processing and the information available to the processor.
Confidentiality and Return or Deletion
Persons authorised to process the data are generally bound by a duty of confidentiality. At the end of the provision of processing services, the processor typically deletes or returns the personal data at the controller's choice, subject to any legal requirement to retain the data.

Common questions

Answers to the questions practitioners most commonly ask about Processing on Behalf of a Controller.

Does acting as a processor mean we have no compliance obligations of our own?
No. While the controller determines the purposes and means of processing, a processor carries its own direct obligations under the GDPR. These generally include processing only on documented instructions from the controller, ensuring confidentiality of authorised personnel, implementing appropriate security measures, assisting the controller with certain of its obligations, and maintaining records of processing activities carried out on the controller's behalf. A processor can be directly liable and subject to enforcement in its own right where it fails to meet these obligations, so the position that a processor bears no independent responsibility is inaccurate.
If we handle personal data for a client, are we automatically a processor rather than a controller?
Not automatically. The classification depends on who actually determines the purposes and means of the processing, which is a factual assessment rather than a matter of contractual labelling. An organisation described as a processor may in fact act as a controller for some activities, and the same entity can hold different roles for different processing operations. Where a party begins to process for its own purposes, or determines essential means, it may take on controller responsibilities. The label in an agreement does not by itself settle the question; the substance of the relationship governs.
What should the contract between a controller and processor cover?
A processor must generally act under a contract or other legal act that is binding on the processor. Under the GDPR (Article 28), this instrument typically sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the obligations and rights of the controller. It commonly addresses processing only on documented instructions, confidentiality, security measures, conditions for engaging sub-processors, assistance with data subject rights and with the controller's security, breach, and impact assessment duties, deletion or return of data at the end of the engagement, and support for audits. Readers should verify the specific required terms against the current official text.
Can a processor engage a sub-processor?
In most cases a processor may engage another processor only with the controller's prior authorisation, which may be specific or general. Where general written authorisation applies, the processor is typically expected to inform the controller of intended changes concerning the addition or replacement of sub-processors, giving the controller an opportunity to object. The initial processor generally remains responsible to the controller for the sub-processor's performance of its data protection obligations, and equivalent obligations are usually required to be imposed on the sub-processor. The precise mechanics should be confirmed against the applicable contractual terms and the current text.
What happens if a processor processes data beyond the controller's instructions?
Processing outside the scope of the controller's documented instructions can change the analysis. Where a processor determines the purposes and means of processing, it may be treated as a controller in respect of that processing and take on the corresponding responsibilities and potential liability. Whether a given deviation crosses that threshold is a fact-specific assessment. Processors are also generally expected to inform the controller where, in their view, an instruction infringes data protection law, subject to applicable requirements.
How should the end of a processing engagement be handled?
The controller-processor instrument typically specifies that, at the end of the provision of services, the processor either deletes or returns the personal data to the controller, and deletes existing copies, unless retention is required by applicable law. The appropriate choice generally depends on the controller's instructions and the surrounding circumstances. Any legally required retention, and the treatment of backups or archived copies, should be addressed in the arrangement and assessed against the applicable requirements.

Common misconceptions

A processor can decide independently how and why to process the personal data it holds.
A processor generally acts only on the controller's documented instructions. If a processor determines the purposes and means of processing, it typically ceases to act as a processor and may be treated as a controller in respect of that processing, with the corresponding obligations. Determination of roles depends on the factual circumstances rather than labels used in a contract.
Once a controller engages a processor, the controller is no longer responsible for that processing.
The controller generally retains accountability and is expected to use only processors offering sufficient guarantees. Both controllers and processors have distinct obligations under the Regulation, and the existence of a processing agreement does not, by itself, transfer the controller's responsibilities. Allocation of liability is context dependent and subject to assessment.
A processor is free to bring in sub-processors as needed to deliver the service.
Engaging a further processor generally requires prior authorisation from the controller, either specific or general with a right to object to changes. Where a sub-processor is used, comparable data protection obligations should typically be imposed, and the initial processor generally remains liable to the controller for the sub-processor's performance.

Best practices

Confirm the factual role of each party before contracting, as controller and processor status depends on who determines the purposes and means, not on the label used in the agreement.
Put in place a written data processing agreement addressing the elements expected under Article 28, including subject matter, duration, nature and purpose, data types, categories of data subjects, and the respective obligations and rights.
Assess and document the processor's sufficient guarantees before engagement, potentially using adherence to an approved code of conduct or certification as supporting evidence, and revisit this assessment periodically.
Establish a clear process for authorising, documenting, and objecting to sub-processors, ensuring equivalent obligations flow down and that liability arrangements are understood.
Ensure the agreement records that the processor acts only on documented instructions, including for any transfer to a third country, and defines how end-of-service deletion or return of data will be handled, subject to any legal retention requirement.
Because transfer mechanisms, adequacy decisions, and supplementary measures evolve, verify current requirements against the official text and applicable guidance rather than relying on a fixed snapshot.