Data Controller vs Data Processor: Roles, Responsibilities, and DSAR Obligations

Controllers and Processors: Why the Distinction Matters

When someone sends your business a data subject access request, the first question is usually "where is the data?" But there is an equally important question that comes before it: "whose responsibility is this?"

Under GDPR and most modern privacy laws, every organization that touches personal data falls into one of two roles: data controller or data processor. Which role you play determines your legal obligations, your liability exposure, and what you must do when a data subject exercises their rights.

Get the classification wrong, and you may fail to respond to DSARs you are legally required to handle, or respond to ones you should not. This guide explains the distinction, shows how it works in practice, and covers the DSAR implications for each role.

The Core Definitions

Data Controller

The data controller is the organization that determines the purposes and means of processing personal data. In plain language: the controller decides why personal data is collected and how it is used.

GDPR Article 4(7) defines a controller as:

the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.

The controller is the decision-maker. They decide what data to collect, what to do with it, how long to keep it, and who to share it with. They bear primary responsibility for compliance and are the main point of accountability for data subjects.

Data Processor

The data processor is the organization that processes personal data on behalf of the controller. The processor acts on the controller's instructions — they do not decide why the data is processed or what to do with it.

GDPR Article 4(8) defines a processor as:

a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.

The processor is the service provider. They handle data according to the controller's directions. A payroll company processing employee salaries, a cloud storage provider hosting files, an email marketing platform sending newsletters — these are processors when they act on your instructions.

Real-World Examples

The definitions are straightforward in theory. In practice, the lines can blur. Here are common scenarios:

Clear-Cut Controller

An online retailer collecting customer orders. The retailer decides what data to collect (name, address, payment details), why (to fulfill orders), and how long to keep it. The retailer is the controller.

An employer maintaining employee records. The employer decides what employee data to collect and process for HR, payroll, and legal compliance purposes. The employer is the controller of employee data.

Clear-Cut Processor

A payroll provider processing salaries on behalf of an employer. The employer (controller) tells the payroll provider what to pay and to whom. The payroll provider processes the data according to those instructions. The payroll provider is a processor.

A cloud hosting provider storing customer data. Amazon Web Services, Microsoft Azure, or Google Cloud stores data on behalf of its customers. The hosting provider does not decide what data is stored or why — it provides infrastructure. The hosting provider is a processor.

An email marketing platform. Mailchimp or similar services send emails on behalf of their customers. The customer (controller) decides who to email and what to say. The platform (processor) sends the messages as instructed.

Where It Gets Complicated

A SaaS company. Most SaaS businesses are both controllers and processors simultaneously — just for different data sets:

• Controller of their own employee data, website visitor data, and customer account data (they decide why and how to process it)
• Processor of their customers' data that flows through the platform (they process it according to their customers' instructions)

A project management tool like Asana or Monday.com is a controller for its employees' HR data and a processor for the task data, comments, and file attachments that its customers create within the platform.

A marketing agency. An agency that manages a client's email campaigns is a processor (acting on the client's instructions). But if the agency independently uses data from the campaign to build its own analytics product, it has become a controller for that purpose — and needs its own legal basis for processing.

A data analytics provider. If the provider simply runs analyses as instructed by its clients, it is a processor. If it independently determines what analyses to perform and creates its own data products, it is a controller.

Joint Controllers

When two or more organizations jointly determine the purposes and means of processing, they are joint controllers under GDPR Article 26.

Joint controllership requires a transparent arrangement between the parties specifying their respective responsibilities, particularly regarding the exercise of data subject rights and the provision of privacy information. The essence of the arrangement must be made available to data subjects.

Examples of Joint Controllership

• An employer and its corporate parent jointly decide to share a centralized HR database, both determining the purposes and means of processing.
• Two companies running a joint marketing campaign where both decide what data to collect and how to use it.
• A social media platform and a business using the platform's analytics tools — the European Court of Justice has found joint controllership in cases involving Facebook fan pages and social plugins, where both the platform and the page operator influence the purposes of data processing.

What Joint Controllers Must Do

Under Article 26, joint controllers must:

1. Determine their respective responsibilities through an arrangement (agreement)
2. Designate which controller is the contact point for data subjects (or make clear that data subjects can exercise their rights against either controller)
3. Make the essence of the arrangement available to data subjects

Regardless of the arrangement between joint controllers, a data subject can exercise their rights against any of the joint controllers.

Sub-Processors

A sub-processor is a processor engaged by another processor. For example, if your payroll provider uses a separate cloud hosting service to store the payroll data, that hosting service is a sub-processor.

Under GDPR Article 28(2) and (4):

• A processor must not engage a sub-processor without the controller's prior written authorization (either specific or general)
• If general authorization is given, the processor must inform the controller of any intended changes (additions or replacements) so the controller can object
• The processor must impose the same data protection obligations on the sub-processor through a contract
• If the sub-processor fails to fulfill its obligations, the original processor remains liable to the controller

This creates a chain of accountability. As the controller, you need to know who your processors are using, and your data processing agreements should address sub-processing.

DSAR Obligations: Who Does What?

This is where the controller/processor distinction has the most practical impact for day-to-day operations.

Controllers Receive and Respond to DSARs

The controller is the organization that data subjects contact to exercise their rights. When someone sends a DSAR, the controller must:

1. Receive and log the request
2. Verify the data subject's identity
3. Search all systems — including data held by processors on their behalf
4. Compile the response, including supplementary information required by Article 15
5. Respond within the deadline (30 days under GDPR, 45 days under CCPA)
6. Handle any follow-up requests (correction, deletion, objection)

The controller cannot deflect a DSAR by saying "your data is with our processor — contact them instead." The controller is responsible for the complete response.

Processors Must Assist Controllers

Under GDPR Article 28(3)(e), the processor must:

assist the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights.

In practice, this means:

• Searching for data when the controller asks — the processor must be able to locate and extract a specific individual's data from its systems
• Providing data exports in a usable format
• Deleting data when the controller instructs them to (for erasure requests)
• Correcting data when instructed (for rectification requests)
• Responding promptly — the controller's deadline depends on how quickly processors provide data

Processors Should NOT Respond Directly to Data Subjects (Usually)

If a data subject contacts a processor directly, the processor should generally redirect them to the controller. The processor does not have the full picture of the data subject's relationship and may not be authorized to make disclosure decisions.

There are practical exceptions:

• If the data processing agreement specifically authorizes the processor to handle certain requests
• If the processor is also a controller for some of the data (the SaaS dual-role scenario)
• If redirecting would cause unreasonable delay and the controller has given standing authorization

But the default position is clear: controllers handle DSARs, processors assist.

A Practical DSAR Workflow for Controllers and Processors

When a controller receives a DSAR:

1. Log the request and start the deadline clock
2. Identify which processors hold the data subject's data (your data inventory should tell you this)
3. Contact each relevant processor with a data extraction request
4. Receive data from processors
5. Compile all data (from your own systems and from processors)
6. Review and redact third-party personal data
7. Respond to the data subject

When a processor receives a request directly from a data subject:

1. Do not ignore it — acknowledge receipt
2. Inform the controller immediately
3. Follow the controller's instructions on how to proceed
4. If the DPA authorizes you to redirect, direct the data subject to the controller

Data Processing Agreements (DPAs)

GDPR Article 28 requires a binding contract between controller and processor — the data processing agreement. This is not optional. Processing personal data without a DPA is a compliance failure for both parties.

Article 28(3) specifies the minimum content: subject matter and duration, nature and purpose of processing, types of personal data and categories of data subjects, processor's obligation to act only on documented instructions, confidentiality obligations, appropriate security measures (Article 32), sub-processor conditions (prior authorization, same obligations flowing down), assistance with data subject rights and breach notification, deletion or return of data at the end of the relationship, and audit rights.

DPA and DSAR Readiness

Your DPA should specifically address DSAR response:

• Response timeframes: How quickly the processor must respond to data extraction requests (shorter than your external DSAR deadline)
• Data format and search capabilities: What format the processor provides data in, and its ability to isolate a specific individual's data
• Deletion procedures: How the processor deletes data on instruction and confirms deletion
• Cost: Whether the processor charges for data extraction or deletion

Negotiate these terms before you need them.

Liability: Who Is on the Hook?

Controllers bear primary responsibility. Under GDPR Article 82(2), controllers are liable for any damage caused by processing that infringes the regulation, and can be fined up to 20 million euros or 4% of annual global turnover (Article 83(5)). If a controller fails to respond to a DSAR — even if the failure was caused by a processor not providing data on time — the controller is liable to the data subject.

Processors are not without liability. They are liable for damage caused by processing where they failed to comply with their specific obligations or acted outside the controller's instructions (Article 82(2)), can be fined directly by supervisory authorities (Article 83), and are liable for the acts of their sub-processors (Article 28(4)).

CCPA Equivalents: Business, Service Provider, and Contractor

The CCPA uses different terminology for similar concepts:

Key differences from GDPR:

• Threshold requirements for businesses: Unlike GDPR (which applies to any controller), CCPA only applies to for-profit businesses that meet certain thresholds — annual gross revenue exceeding $25 million, buying/selling/sharing personal information of 100,000 or more consumers or households, or deriving 50% or more of revenue from selling or sharing personal information.
• Contractor role: CPRA introduced the "contractor" category alongside "service provider." Both are processor-like, but contractors have different contractual requirements.
• DSAR obligations: Under CCPA, the business (not the service provider) receives and responds to consumer requests. Service providers must assist and are generally prohibited from using the personal information for their own purposes.

PIPEDA: Organization Accountability

PIPEDA does not use the controller/processor distinction in the same way. Instead, Principle 1 (Accountability) places responsibility on the organization that collects personal information:

An organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing.

This means:

• The collecting organization remains accountable even when data is sent to a third-party processor
• Contractual or other means must be used to ensure the third party provides a comparable level of protection
• The collecting organization must handle access requests (Principle 9) regardless of where the data is physically held

The effect is similar to GDPR's controller/processor framework, but the obligation is expressed as organizational accountability rather than role-based allocation.

Common Confusion: The Dual-Role SaaS Company

The single most common source of confusion is SaaS companies that are simultaneously controllers and processors. This deserves explicit treatment because nearly every modern business uses SaaS tools, and many SaaS businesses misunderstand their own role.

A SaaS company is a processor when it processes data belonging to its customers -- task data in a project management tool, subscriber lists in an email marketing platform, support tickets in a help desk. The customers (controllers) decide what data enters the system and why.

The same SaaS company is a controller for its own employees' data, customer account data (names, emails, billing), website visitor data, and any data used for its own purposes like product analytics.

Why this matters for DSARs: If the request concerns data the SaaS company controls (e.g., account data), it responds as a controller. If the request concerns data it processes on behalf of a customer, it should direct the data subject to the relevant customer (the controller) and notify that customer. Getting this right requires understanding which hat you are wearing for each data set.

Practical Checklist: Are You a Controller or Processor?

For each set of personal data you process, work through these questions:

You Are Likely a Controller If:

1. You decided to collect this data. You chose what data to gather and from whom.
2. You decided why to process it. You determined the purpose (marketing, fulfilling orders, HR management, etc.).
3. You decided how to process it. You chose the methods, tools, and procedures.
4. You have a direct relationship with the data subjects. Customers, employees, website visitors — they know you have their data.
5. You determine how long to keep the data. You set retention periods.
6. You decide who to share the data with. You choose which processors and third parties receive the data.

You Are Likely a Processor If:

1. You process data on behalf of another organization. They are your client or customer.
2. You follow their instructions. They tell you what to do with the data.
3. You did not decide the purpose of processing. The controller determined why the data is being processed.
4. You have no direct relationship with the data subjects. The individuals whose data you process are the controller's customers or employees, not yours.
5. You would not have the data at all without the controller's engagement. The data came to you through your service relationship.
6. Your contract specifies that you act on the controller's instructions. Your DPA defines your role.

You Might Be Both If:

• You process data on behalf of clients (processor) while also collecting your own customer and employee data (controller)
• You started as a processor but began using the data for your own purposes (you have become a controller for that purpose — and may need a new legal basis)

What to Do Next

1. Classify your role for each type of personal data you process. Do not assume you are always a controller or always a processor — map it data set by data set.
2. Put DPAs in place with every processor you use and every controller you process data for. Check that existing DPAs address DSAR assistance specifically.
3. Build DSAR procedures that account for your role. If you are a controller, your process needs to include contacting processors. If you are a processor, your process needs to include redirecting requests and assisting controllers promptly.
4. Document everything. Keep records of your role determination, your DPAs, and your DSAR handling process. This is your evidence of compliance.

References

• General Data Protection Regulation (GDPR): Article 4(7) — definition of controller; Article 4(8) — definition of processor; Article 26 — joint controllers; Article 28 — processor obligations and DPAs; Article 82 — liability. GDPR Article 4 | GDPR Article 28
• California Consumer Privacy Act (CCPA/CPRA): Cal. Civ. Code § 1798.140(d) — business; § 1798.140(ag) — service provider; § 1798.140(j) — contractor. CCPA full text
• PIPEDA: Principle 1 — Accountability. PIPEDA full text
• ICO guidance: Controllers and processors. ICO controllers and processors guidance
• EDPB Guidelines 07/2020: On the concepts of controller and processor. EDPB guidelines