Skip to main content
Governance Authority
Category: Privacy and Cybersecurity

Data Processor

Also known as: Processor
Simply put

A data processor is an organisation or person that handles personal data on behalf of, and under the instructions of, another party known as the data controller. Unlike the controller, the processor does not decide why or how the data is used; it acts on the controller's directions. In practice, this is often an external service provider engaged by the controller to carry out specific processing tasks.

Formal definition

Under the EU General Data Protection Regulation (GDPR), a data processor is a natural or legal person, public authority, agency, or other body that processes personal data on behalf of a data controller and acts only under the controller's documented instructions. The defining feature distinguishing a processor from a controller is the absence of decision-making authority over the purposes and essential means of processing; the processor executes processing activities as directed rather than determining them. In practice, the role is typically filled by an external organisation engaged by the controller, and generally excludes employees acting within the controller's own organisation. The precise obligations, contractual requirements, and boundaries of the processor role depend on the applicable legal regime and jurisdiction; this entry is educational and does not constitute legal advice.

Why it matters

The controller-processor distinction determines where accountability sits when personal data is handled. Under the GDPR, the controller decides the purposes and essential means of processing and bears primary responsibility for compliance, while the processor acts only on the controller's documented instructions. Misclassifying a service provider as a processor when it in fact exercises decision-making authority over purposes and means can leave an organisation exposed to obligations it has not addressed, because a party that determines the why and how of processing is generally treated as a controller regardless of the label applied in a contract.

For governance, risk, and compliance functions, the processor relationship is a focal point of third-party risk management. When a controller engages an external organisation to process personal data on its behalf, the controller does not shed its own responsibilities; it must satisfy itself that the processor offers appropriate safeguards and that the arrangement is governed by suitable contractual terms. Poorly governed processor relationships can create gaps in oversight, particularly where processing is subcontracted onward or performed across jurisdictions with differing legal regimes.

The practical significance of the role also varies by legal regime and jurisdiction. The obligations, contractual requirements, and boundaries described here reflect the GDPR framework, and the specific duties that attach to a processor depend on the applicable law and the facts of the arrangement. Organisations should treat classification as a fact-specific analysis rather than a formality, and seek qualified legal advice where the allocation of roles is uncertain.

Who it's relevant to

General Counsel and Privacy Counsel
Legal teams are responsible for correctly classifying parties as controllers or processors and for ensuring that processing arrangements are governed by appropriate contractual terms. Because classification is fact-specific and depends on who determines the purposes and essential means of processing, counsel should assess each relationship on its facts and under the applicable jurisdiction's law.
Chief Compliance and Privacy Officers
These functions oversee how personal data is handled across the organisation and by its service providers. Understanding whether the organisation acts as a controller or a processor in a given arrangement shapes which obligations apply and how oversight of processing activities should be structured.
Third-Party and Vendor Risk Managers
Processors are frequently external organisations engaged to perform processing on a controller's behalf, making them a central concern for third-party risk management. Those managing vendor relationships should confirm that processing is carried out only under the controller's instructions and that appropriate safeguards are in place.
Internal Auditors and Assurance Functions
Assurance providers may be asked to evaluate whether processing arrangements operate as intended, including whether processors act within the controller's documented instructions. This entry is educational and does not substitute for legal, audit, or compliance advice on any specific arrangement.

Inside Data Processor

Processing on behalf of another
A data processor generally refers to a party that processes personal data on behalf of, and under the instructions of, a data controller. The distinguishing feature is that the processor acts for another's purposes rather than determining the purposes and means of processing itself; that determination typically defines the controller role.
Controller instructions
Under many data protection regimes, a processor is generally expected to act only on the documented instructions of the controller. The scope, subject matter, duration, and nature of processing are typically set by the controller, and departures from those instructions may recharacterize the processor's role or create separate liability, depending on the applicable law.
Processing agreement or contract
In many jurisdictions, the controller-processor relationship is expected to be governed by a binding written arrangement that addresses matters such as confidentiality, security measures, sub-processing, and assistance to the controller. The specific mandatory contents vary by jurisdiction and framework and are not universal.
Security and confidentiality obligations
Processors are generally subject to obligations to implement appropriate technical and organizational measures and to maintain confidentiality. What is 'appropriate' typically depends on the nature of the data, the risk, and the applicable legal standard, and is a matter of judgment rather than a fixed checklist.
Sub-processing arrangements
Where a processor engages another party to carry out part of the processing, that party is often described as a sub-processor. Many regimes condition sub-processing on controller authorization and on passing down comparable obligations, but the precise requirements depend on the governing law and contract.
Accountability and role classification
Whether an entity is a controller, joint controller, or processor is generally determined by the facts of who decides the purposes and means, not merely by contractual labels. Misclassification can shift legal responsibilities, so the analysis is fact-specific and jurisdiction-dependent.

Common questions

Answers to the questions practitioners most commonly ask about Data Processor.

Is a data processor the same as a data controller?
No. Under many data protection regimes, such as the EU and UK GDPR, the controller is the party that determines the purposes and means of processing personal data, while the processor acts on the controller's documented instructions. The distinction matters because the two roles carry different obligations and different exposure to liability. A single organization can be a controller for some processing activities and a processor for others, and the correct classification generally depends on the facts of who actually decides the why and how of the processing rather than on how a contract labels the parties.
Does using a processor transfer the controller's compliance responsibility to that processor?
Generally not. Engaging a processor does not discharge the controller's own accountability for the processing. In many jurisdictions the controller retains primary responsibility for having a lawful basis, honoring data subject rights, and ensuring appropriate safeguards, while the processor has its own set of direct obligations. Both parties can face liability, but for distinct failings. The precise allocation depends on the applicable law and the terms agreed between the parties, and this entry is educational rather than legal advice.
What terms should typically appear in a controller-processor agreement?
Under regimes such as the GDPR, a written contract or other legal act generally governs the relationship and commonly addresses the subject matter and duration of processing, the nature and purpose, the types of personal data and categories of data subjects, and the obligations and rights of the controller. It typically also requires the processor to act only on documented instructions, ensure confidentiality, implement appropriate security measures, assist the controller with data subject requests and breach handling, and delete or return data at the end of the engagement. Specific mandatory terms vary by jurisdiction, so the applicable law and professional advice should guide the drafting.
How should an organization decide whether it is acting as a controller or a processor for a given activity?
The classification generally turns on who determines the purposes and means of the processing, not on contractual labels or commercial preference. A practical approach is to map each processing activity, identify who decides why the data is processed and the essential means of doing so, and document the reasoning. Where an entity exercises meaningful discretion over purposes, it is more likely a controller; where it processes strictly on another party's instructions, it is more likely a processor. Because the answer depends on the specific facts and the applicable jurisdiction, uncertain or mixed cases typically warrant legal review.
What controls help a processor demonstrate that it is meeting its obligations?
Processors commonly maintain records of processing activities carried out on behalf of controllers, implement and test technical and organizational security measures, and establish procedures for assisting controllers with data subject requests and breach notification. Governance practices such as documented instructions, access restrictions, staff confidentiality commitments, and evidence of control operating effectiveness support accountability. The appropriate set of controls depends on the sensitivity of the data, the nature of the processing, and the requirements of the applicable regime.
How should a processor handle engaging sub-processors?
Under many regimes, a processor generally cannot appoint a sub-processor without the controller's prior authorization, which may be specific or general subject to notice and an opportunity to object. Where sub-processors are used, the processor typically flows down materially equivalent data protection obligations by contract and remains responsible to the controller for the sub-processor's performance. Organizations should track their sub-processor chain, document authorizations, and confirm the arrangement aligns with the applicable law and the underlying controller agreement.

Common misconceptions

A vendor is a data processor simply because a contract labels it one.
Role classification generally turns on the factual reality of who determines the purposes and means of processing, not on the label used in an agreement. An entity contractually named a processor may in practice act as a controller or joint controller, which changes its legal obligations under many data protection regimes.
Data protection accountability is a compliance matter that sits solely with the compliance function.
Responsibility for the processing typically rests with the accountable business or management as the operating owner of the relationship, with compliance providing monitoring and advice and assurance functions providing independent evaluation. Conflating these lines obscures where accountability actually sits, and specific allocations depend on the organization and jurisdiction.
Using a processor transfers the controller's legal responsibility to that processor.
Engaging a processor does not generally extinguish the controller's own obligations. In many regimes the controller retains accountability for the lawfulness of processing while the processor bears its own distinct duties. The exact allocation of liability depends on the applicable law and the terms of the arrangement, and this entry is educational rather than legal advice.

Best practices

Classify each data relationship based on the factual question of who determines the purposes and means of processing, rather than relying on the label in the contract, and document the reasoning behind the classification.
Put in place a written processing arrangement that addresses instructions, confidentiality, security measures, sub-processing, and assistance obligations, tailored to the requirements of the applicable jurisdiction rather than a single template.
Define and control sub-processing by requiring appropriate authorization and passing down comparable obligations, and maintain visibility into the chain of parties that touch the data.
Assign clear accountability to the business or management owner of the relationship, with compliance monitoring and independent assurance functions evaluating effectiveness, so the three lines remain distinct.
Assess the appropriateness of technical and organizational security measures against the specific risk, data sensitivity, and applicable legal standard, and revisit that assessment as circumstances change.
Obtain qualified legal advice for jurisdiction-specific requirements and cross-border considerations, treating this entry as educational and not a substitute for legal, audit, or compliance advice.