Category: Compliance and Monitoring

Processor Obligations

Also known as: Data Processor Responsibilities, Processor Duties

Simply put

Processor obligations are the responsibilities placed on an organization that handles personal data on behalf of, and under the instructions of, another organization (the controller). These duties typically include acting only on the controller's documented instructions, keeping the data secure and confidential, and getting permission before bringing in additional service providers to help with the processing. The specific obligations depend on the applicable law, and treatment differs across jurisdictions.

Formal definition

Under the EU GDPR (and mirrored in the UK GDPR), a processor is a party that processes personal data on behalf of a controller, and Article 28 imposes direct statutory obligations on that party rather than leaving them solely to contract. Core obligations generally include: processing only on the controller's documented instructions; ensuring persons authorised to process the data are bound by confidentiality; implementing appropriate technical and organisational security measures; not engaging a sub-processor without the controller's prior specific or general written authorisation; assisting the controller with its own obligations; and being subject to audits or assessments of its processing policies. These are distinct from controller obligations, and the processor does not determine the purposes and means of processing. Outside the EU/UK regime, comparable duties arise differently: under U.S. state privacy laws, contractual and assessment requirements for processors (or 'service providers'/'contractors' in some frameworks) vary by statute, and this entry does not attempt to reconcile those regimes. This definition does not cover cross-border transfer mechanics, retention rules, breach-notification timing specifics, or enforcement penalties, and accountability for these obligations generally requires demonstrable evidence rather than stated intent.

Why it matters

Processor obligations matter because, under the EU GDPR and the UK GDPR, they represent a shift from a purely contractual model to one in which certain duties fall directly on the processor by statute. A processor that fails to act only on the controller's documented instructions, or that engages a sub-processor without the required authorisation, exposes itself to direct regulatory attention rather than merely a breach of contract with the controller. This changes how service providers must design their compliance posture, because they can no longer assume that their obligations begin and end with the terms their client negotiated.

The distinction also clarifies accountability across a data supply chain. The controller determines the purposes and means of processing and retains overall responsibility, but the processor bears its own defined duties, including keeping data confidential and implementing appropriate technical and organisational security measures. When something goes wrong, the allocation of responsibility depends in part on whether the failure related to instructions and purpose (typically a controller concern) or to the security and confidentiality of the handling itself (where processor duties are directly engaged). Clarity here reduces the risk of gaps where neither party believes it is accountable.

Accountability for these obligations generally requires demonstrable evidence rather than stated intent. A processor that claims to follow instructions or maintain security must be able to show it, which is why several U.S. state privacy laws additionally require processors to permit assessments of their data processing policies. This entry does not cover cross-border transfer mechanics, retention rules, breach-notification timing specifics, or enforcement penalties, each of which is governed separately and varies by jurisdiction.

Who it's relevant to

Service providers and vendors processing on behalf of clients

Organizations that handle personal data under another party's instructions need to understand that, under the EU and UK GDPR, certain obligations fall on them directly and not only through their client contract. This includes maintaining confidentiality, implementing appropriate technical and organisational security measures, and obtaining the controller's prior written authorisation before engaging a sub-processor.

Data protection officers and privacy leads at controller organisations

Those responsible for engaging processors must confirm that documented instructions, contract terms, and sub-processor authorisation arrangements are in place, and that the processor can evidence compliance. Because accountability generally requires demonstrable evidence rather than stated intent, DPOs should verify that assessment or audit rights are exercisable in practice.

Vendor risk and procurement teams

Teams evaluating suppliers should assess whether a prospective processor can meet its statutory and contractual duties, including confidentiality, security measures, and controls on onward sub-processing. Where U.S. state privacy laws apply, they should also confirm the processor will permit assessments of its data processing policies, noting that requirements differ by statute.

Legal and compliance professionals drafting data processing agreements

Counsel structuring controller-processor arrangements need to reflect the directly imposed obligations under the applicable regime rather than assuming contract alone defines the processor's duties. They should also avoid treating the EU/UK model and U.S. state law requirements as interchangeable, since the roles and assessment obligations are framed differently across jurisdictions.

Inside Processor Obligations

Processing on Documented Instructions

Under the EU GDPR, a processor generally processes personal data only on the documented instructions of the controller, including for cross-border transfers, unless required to act otherwise by applicable law. The controller determines the purposes and means of processing; the processor executes within that mandate. Treatment differs in other regimes such as the UK GDPR, which mirrors this closely, and the CCPA/CPRA service provider model, which frames comparable obligations differently.

Data Processing Agreement (DPA)

A binding contract or other legal act generally governing the controller-processor relationship, setting out the subject matter, duration, nature and purpose of processing, categories of data and data subjects, and the obligations and rights of the controller. This is a governance and legal instrument; its existence does not by itself demonstrate operational compliance.

Sub-processor Engagement

A processor generally may not engage another processor (a sub-processor) without prior authorisation from the controller, whether specific or general, and typically must flow down equivalent data protection obligations by contract. The originating processor generally remains accountable to the controller for the sub-processor's performance.

Security of Processing

Processors are typically required to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. This is where processor obligations overlap with information security (confidentiality, integrity, availability), but the obligation is scoped to security measures and does not extend to the governance decisions about purpose and lawful basis, which remain with the controller.

Assistance to the Controller

Processors generally must assist the controller in meeting certain of the controller's own obligations, such as responding to data subject rights requests, supporting a data protection impact assessment where one is required, and cooperating on security and breach matters. The processor assists; the controller remains accountable for the underlying obligation.

Breach Notification to the Controller

A processor typically must notify the controller without undue delay after becoming aware of a personal data breach. Notably, the notification duty to a supervisory authority and to affected individuals generally rests with the controller, not the processor. This entry does not cover the specific timelines or thresholds, which vary by regime and context.

Records of Processing Activities (RoPA)

Processors may have their own obligation to maintain records of processing carried out on behalf of controllers. This is a documentary accountability obligation and should not be equated with any particular data inventory tool or software product; the records demonstrate accountability but are distinct from the systems used to compile them.

Return or Deletion and Audit Support

At the end of the provision of services, a processor generally returns or deletes the personal data as the controller chooses, subject to any legal retention requirements. Processors typically also make available information necessary to demonstrate compliance and allow for and contribute to audits. This entry does not detail retention periods, which are context and jurisdiction dependent.

Common questions

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

Does a processor share the same accountability as the controller for deciding how personal data is used?

Generally no. Under the EU GDPR and UK GDPR, the controller determines the purposes and means of processing and bears primary accountability for those decisions, while the processor acts on the controller's documented instructions. The processor has its own direct statutory obligations, but these relate to how it carries out processing on the controller's behalf, not to determining why data is processed. If a processor begins determining purposes and means on its own initiative, it may be treated as a controller for that activity and take on the corresponding obligations. Treatment differs across regimes, so the specific allocation should be confirmed against the applicable instrument.

Is a processor relieved of obligations because a contract is in place and it is only following instructions?

No. A written processing contract is a required element, but it does not exhaust the processor's responsibilities. Processors have direct obligations that exist independently of the contract, and the accountability principle generally requires demonstrable evidence of compliance rather than stated intent alone. Following the controller's instructions does not shield a processor where those instructions would breach applicable law; in most cases the processor is expected to flag such instructions. Being a processor limits the scope of what a party is accountable for, but it does not remove accountability for its own conduct.

What contractual terms typically need to be in place between a controller and a processor?

Under the EU GDPR and UK GDPR, the processing arrangement generally must be governed by a binding contract or other legal act that sets out the subject matter, duration, nature and purpose of processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. It typically also addresses processing only on documented instructions, confidentiality commitments, security measures, conditions for engaging sub-processors, assistance to the controller, handling of data at the end of the engagement, and audit provisions. The exact required contents depend on the applicable instrument, and this answer does not cover cross-border transfer mechanics, which are addressed separately.

How should a processor handle engaging sub-processors?

In most cases the processor may only engage another processor with the controller's authorisation, which may be specific or general, and where general authorisation is used the processor is typically expected to inform the controller of intended changes so the controller can object. The processor generally must impose the same or equivalent data protection obligations on the sub-processor and often remains responsible to the controller for the sub-processor's performance. The precise mechanics depend on the applicable instrument and the terms of the processing contract.

What role does a processor play in supporting data subject rights requests?

The controller is generally responsible for responding to data subject rights requests. The processor's role is typically to assist the controller, taking into account the nature of the processing and the information available to it, so the controller can fulfil its obligations. Processors should have operational processes to receive, escalate, and act on such assistance requests within the timeframes agreed with the controller. This entry does not cover the substantive scope of individual rights or applicable response deadlines, which vary by regime.

What evidence should a processor maintain to demonstrate it is meeting its obligations?

Because accountability generally requires demonstrable evidence rather than stated intent, a processor should be able to show records of the processing it carries out on behalf of controllers, documentation of security measures, records of sub-processor arrangements and authorisations, evidence of assistance provided to controllers, and logs relevant to breach handling. Under the EU GDPR and UK GDPR, processors have their own records obligation distinct from the controller's, and maintaining such records is not the same as deploying a data inventory tool. The specific records required depend on the applicable instrument and the nature of the processing.

Common misconceptions

A processor and controller bear the same obligations, so the labels are interchangeable.

The controller determines the purposes and means of processing and generally bears primary accountability, including the duty to notify a supervisory authority and affected individuals of a breach. The processor acts on the controller's documented instructions and carries a narrower, distinct set of obligations. The roles must be kept separate, and a party can be a controller for some processing and a processor for other processing.

Signing a data processing agreement means a processor is compliant.

A DPA is a necessary legal instrument but not sufficient. Accountability under data protection and governance frameworks generally requires demonstrable evidence that the stated measures are actually implemented and operating, not merely contractual commitments on paper. Compliance depends on context, jurisdiction, and actual implementation.

If a processor encrypts or tokenizes the data, it is no longer personal data and processor obligations fall away.

Encryption and tokenization are security and pseudonymization measures; they generally do not render data non-personal because the process is typically reversible with additional information. Pseudonymized data generally remains personal data, so processor obligations continue to apply. Only irreversible anonymization would typically fall outside most regulation, and that is a high and context-dependent bar.

Best practices

Establish a written data processing agreement before processing begins, specifying subject matter, duration, nature and purpose, categories of data and data subjects, and the respective obligations, so the controller-processor boundary is documented rather than assumed.

Maintain your own records of processing activities as a processor, and keep them independent of any single vendor tool so they remain a durable, demonstrable record of accountability.

Operate strictly on the controller's documented instructions, and put a process in place to flag and query any instruction that appears to conflict with applicable law before acting on it.

Implement and retain evidence of appropriate technical and organisational security measures, recognising that demonstrable proof of operation, not merely stated intent, is what supports accountability.

Obtain the required controller authorisation before engaging any sub-processor and flow down equivalent data protection obligations by contract, keeping a current register of sub-processors.

Define breach handling so the controller is notified without undue delay, and clarify in advance that notification to supervisory authorities and individuals generally remains the controller's responsibility, along with agreed procedures for returning or deleting data at the end of services.