Data Controller vs Data Processor: Key Differences

Updated: March 2026

Understanding the difference between a data controller and a data processor is one of the most fundamental requirements of GDPR compliance. Getting this distinction wrong can leave your organisation exposed to significant legal liability, invalid contracts, and regulatory enforcement action. This guide explains exactly what each role means, how to determine which applies to your organisation, and what legal obligations follow from each designation.

What Is a Data Controller Under GDPR?

A data controller is the natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and means of processing personal data. In plain terms: if your organisation decides why personal data is collected and how it will be used, you are acting as a data controller.

Under Article 4(7) of the UK GDPR and EU GDPR, the controller role is defined by decision-making power over the processing activity. This is a functional definition, and it applies regardless of what your contracts say. If you control the purpose and means of processing, you are a controller, whether or not you have formally acknowledged that role.

Example: A GP surgery that collects patient health records to deliver medical care is a data controller. It decides what data to collect, why, and how to store and use it.

As of 2026, there are over 1 million organisations registered as data controllers with the UK Information Commissioner’s Office (ICO), reflecting the designation’s wide scope.

What Is a Data Processor Under GDPR?

A data processor is a natural or legal person, public authority, agency, or other body that processes personal data on behalf of the controller. The defining characteristic is that the processor acts under the controller’s instructions – it does not determine the purposes or means of processing itself.

Under Article 4(8) of the GDPR, processors are characterised by their subordinate role. They carry out processing tasks as directed by the controller. If a processor starts making independent decisions about why data is being processed, it risks being reclassified as a controller for that activity, with all associated legal obligations.

Example: A payroll software company that processes employee salary data on behalf of businesses is a data processor. It processes data according to each client’s instructions and does not use that data for its own purposes.

The EDPB’s Guidelines 07/2020 on the concepts of controller and processor clarify that “the status of controller or processor must be determined based on the factual circumstances of each case, not on the formal characterisation by the parties in a contract.”

What Is the Difference Between a Data Controller and a Data Processor?

The key difference is decision-making authority over personal data processing. Controllers decide the purpose and means of processing. Processors act only on controllers’ instructions and cannot use the data for their own purposes.

This distinction has significant practical consequences for GDPR compliance obligations:

Aspect	Data Controller	Data Processor
Decision-making	Determines purpose and means	Acts on instructions only
Legal basis	Must establish a lawful basis	Not required to establish a lawful basis
Data subject rights	Must respond to all requests	Must assist the controller
Privacy notices	Must publish a privacy notice	No general requirement
Contracts	Must appoint processors by a written contract	Must have a DPA with the controller
Liability	Primary liability to data subjects	Liability for one’s own non-compliance
ICO registration	Required in most cases	Required only if acting as a controller elsewhere
Data Protection Officer	May be required	May be required

Can an Organisation Be Both a Controller and a Processor?

Yes. The same organisation can be a data controller for some processing activities and a data processor for others. This is common in technology companies and professional services firms.

Example: A cloud hosting company is a processor when it stores client data at the client’s direction. But it is a controller for its own employee HR data and its own customer billing records.

The EDPB confirmed in Guidelines 07/2020 that the controller/processor distinction is activity-specific rather than entity-specific. You must assess each processing activity separately rather than assuming a single designation applies across your entire organisation.

As of 2026, the ICO’s accountability framework guidance explicitly asks organisations to document the basis on which they act (controller, processor, or joint controller) for each processing purpose in their Record of Processing Activities.

What Are Joint Controllers Under GDPR?

Joint controllers exist where two or more organisations jointly determine the purposes and means of processing personal data. Article 26 of the GDPR requires joint controllers to enter into a transparent arrangement that sets out their respective responsibilities.

The Court of Justice of the European Union (CJEU) has taken a broad view of joint controllership. In the Fashion ID case (C-40/17, 2019), the CJEU found that a website operator embedding a Facebook Like button was a joint controller with Facebook for the collection and transmission of visitor data, even though it had no access to that data itself. Similarly, in the Wirtschaftsakademie case (C-210/16, 2018), the CJEU held that a Facebook page administrator was a joint controller for fan page statistics.

Key requirements for joint controllers under Article 26:

• A written arrangement must exist between the joint controllers
• The arrangement must determine respective responsibilities for GDPR compliance
• The essence of the arrangement must be made available to data subjects
• Data subjects can exercise their rights against either joint controller

As of 2024, the EDPB has stated that joint controllership is more common than organisations typically recognise, particularly in digital marketing, analytics platforms, and shared HR systems.

What Does a Data Processing Agreement Need to Include?

When a controller uses a processor, Article 28(3) of the GDPR requires a written Data Processing Agreement (DPA) that specifies:

• The subject matter, duration, nature, and purpose of the processing
• The type of personal data and categories of data subjects
• The obligations and rights of the controller

The DPA must also require the processor to:

• Process personal data only on documented instructions from the controller
• Ensure persons authorised to process data are bound by confidentiality
• Implement appropriate technical and organisational security measures (Article 32)
• Obtain the controller’s prior written consent before engaging sub-processors
• Assist the controller in fulfilling data subject rights requests
• Assist the controller with security, breach notification, DPIAs, and prior consultation
• Delete or return all personal data at the end of the services
•Provide all information necessary to demonstrate compliance with Article 28

Incomplete or absent DPAs are one of the most common GDPR violations found during ICO audits. The GDPR Enforcement Tracker records multiple significant fines issued for Article 28 failures, including regulatory action against processors that subcontracted work without the controller’s consent.

What Are the GDPR Obligations of a Data Controller?

Data controllers carry the primary burden of GDPR compliance. Core controller obligations include:

Establish a lawful basis for processing. Under Article 6, every processing activity must rest on one of six lawful bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. For special category data, an additional condition under Article 9 must also be met.

Publish a privacy notice. Articles 13 and 14 require controllers to provide clear, accessible information to data subjects about how their data is being processed. This must include the identity of the controller, the purposes and legal basis for processing, retention periods, and data subject rights.

Respond to data subject rights requests. Controllers must handle requests to access, rectify, erase, restrict, or port personal data within one calendar month (Article 12). As of 2024, the ICO reports that data subject access requests (DSARs) constitute the largest category of data protection complaints it receives.

Appoint processors by written contract only. Article 28(1) prohibits controllers from using processors that do not provide “sufficient guarantees” of GDPR compliance. Due diligence on processors is a legal requirement, not just good practice.

Maintain a Record of Processing Activities (ROPA). Article 30 requires controllers (and processors) with 250 or more employees to maintain a written record of all processing activities. Smaller organisations must also maintain records if processing is regular, involves special category data, or poses a risk to data subjects.

Conduct Data Protection Impact Assessments (DPIAs). Article 35 requires a DPIA before any processing that is “likely to result in a high risk” to individuals. This includes large-scale processing of special category data, systematic monitoring of publicly accessible areas, and processing using new technologies.

Report personal data breaches. Article 33 requires controllers to report eligible breaches to the supervisory authority within 72 hours of becoming aware of them. Article 34 requires notification to affected individuals where the breach is likely to result in a high risk.

What Are the GDPR Obligations of a Data Processor?

While controllers carry primary responsibility, processors have direct obligations under the GDPR that extend beyond contractual requirements. Key processor obligations include:

Maintain a Record of Processing Activities. Under Article 30(2), processors must maintain records of all processing activities carried out on behalf of controllers, including the name and contact details of each controller they work for, categories of processing, and details of any transfers to third countries.

Implement appropriate security measures. Article 32 applies directly to processors. Processors must implement technical and organisational measures appropriate to the risk, independently of any instruction from the controller.

Notify the controller of personal data breaches. Processors have no direct obligation to notify supervisory authorities, but must notify the controller “without undue delay” after becoming aware of a breach, enabling the controller to meet its 72-hour reporting window.

Appoint a Data Protection Officer (DPO) where required. Article 37 applies to processors as well as controllers. A DPO is required where the processor’s core activities consist of large-scale, regular, and systematic monitoring, or the large-scale processing of special category data.

Comply with international transfer rules. Processors may not transfer personal data to third countries without the controller’s authorisation and, in most cases, appropriate transfer safeguards such as Standard Contractual Clauses (SCCs) or an adequacy decision.

Processors are subject to direct regulatory enforcement for these obligations. Under Article 83(4), processors may be fined up to €10 million or 2% of their annual global turnover for violating processor-specific obligations.

How Do You Determine Whether Your Organisation Is a Controller or Processor?

The EDPB’s Guidelines 07/2020 outline a practical assessment framework. Ask these questions for each processing activity:

Step 1: Is personal data being processed? If no personal data is involved, GDPR does not apply to that activity.

Step 2: Does your organisation determine the purpose of the processing? If you decide why personal data is collected or used, you are likely a controller for that activity.

Step 3: Does your organisation determine the means of processing? If you decide which data to collect, how long to retain it, who can access it, or what tools to use, you are likely a controller.

Step 4: Does your organisation process data strictly in accordance with another organisation’s instructions? If yes, and you have no discretion over the purpose, you are likely a processor.

Step 5: Does your organisation use the data for its own purposes? Any use of personal data beyond your client’s instructions may make you a controller for that additional use.

The ICO’s guidance notes that practical indicators of controller status include: deciding what personal data to collect, deciding the legal basis for collection, determining retention periods, and deciding how to respond to data subject rights requests.

What Happens If a Processor Acts Outside Its Instructions?

If a processor processes personal data beyond the controller’s documented instructions or for its own purposes, the GDPR treats it as a controller for that unauthorised processing. Under Article 28(10), “a processor that infringes this Regulation by determining the purposes and means of processing shall be considered to be a controller in respect of that processing.”

This reclassification has significant consequences. The processor becomes directly liable for establishing a lawful basis, issuing a privacy notice, and meeting all other controller obligations for the unauthorised processing. Fines under Article 83(4) and (5) both potentially apply.

Several notable GDPR enforcement actions have involved processors acting outside their instructions. The ICO has issued reprimands and fines in cases where processors used client data for their own analytics, profiling, or commercial purposes without authorisation.

What Is the Difference Between a Sub-processor and a Third-Party Controller?

A sub-processor is an organisation engaged by a processor to help carry out processing on behalf of the controller. A third-party controller is a separate organisation that receives personal data and processes it for its own purposes.

The distinction matters significantly:

Sub-processor: Requires the controller’s prior written authorisation. The original processor remains fully liable to the controller for the sub-processor’s performance. A DPA must be in place between the processor and sub-processor with equivalent obligations.

Third-party controller: The original controller must have a lawful basis for sharing data with the third party. The third party takes on independent controller responsibilities. A DPA is not appropriate; instead, a data-sharing agreement or a controller-to-controller transfer mechanism is needed.

Misclassifying a third-party controller as a sub-processor is a compliance error that can invalidate the legal basis for sharing personal data and expose both organisations to enforcement action.

Frequently Asked Questions

Q: Is my organisation a controller or a processor?

The answer depends on whether you determine the purpose and means of processing. If you decide why personal data is collected and how it is used, you are a controller. If you only process data according to another organisation’s instructions, you are a processor for that activity. Many organisations are both, depending on the processing activity being assessed.

Q: Does a processor need to register with the ICO?

In the UK, ICO registration (paying the data protection fee) is required if you are a data controller. Pure processors that act only on behalf of controllers do not need to register separately. However, most processors are also controllers for some of their own processing (such as HR data), which does trigger registration.

Q: What happens if we don’t have a Data Processing Agreement in place?

Operating without a DPA is a direct violation of Article 28 of the GDPR. Both the controller and the processor can face regulatory action. The ICO can issue enforcement notices, reprimands, and fines. In a 2023 enforcement action, the ICO found a major public body had used processors without adequate contractual protections, resulting in a formal reprimand and remediation requirements.

Q: Can a processor refuse instructions from a controller?

A processor must process data only in accordance with the controller’s instructions. However, where the processor believes an instruction would violate GDPR or other applicable law, it must immediately inform the controller. A processor is not required to comply with instructions that would result in unlawful processing.

Q: Are cloud service providers always processors?

Not necessarily. Infrastructure-as-a-Service (IaaS) providers are typically processors when storing client data. But Software-as-a-Service (SaaS) providers may be controllers for their own platform analytics and improvement activities, while being processors for customer data they host. The functional test applies to each processing activity.

Q: What is a sub-processor, and do we need to notify clients?

A sub-processor is an organisation engaged by a processor to help carry out processing on behalf of the controller. Most DPAs include provisions either granting general written authorisation for sub-processors (with a right to object to new sub-processors) or requiring specific approval for each sub-processor. Controllers must be notified of any changes to sub-processor arrangements.

Q: Do joint controllers each need a separate privacy notice?

Joint controllers must ensure that data subjects receive all required information under Articles 13 and 14. In practice, this is usually handled by designating one controller as the primary point of contact for data subjects, but both controllers remain responsible for ensuring the required information is provided. The CJEU confirmed this in the Fashion ID and Wirtschaftsakademie cases.

Q: What fines can apply to processors?

Processors face fines of up to €10 million (or £8.7 million in the UK) or 2% of global annual turnover for violations of Article 28 (DPA requirements), Article 29 (processing only on instructions), Article 30 (records), and Article 32 (security). For more serious violations, Article 83(5) fines of up to €20 million (or £17.5 million in the UK) or 4% of the processor’s global annual turnover may apply where the processor has acted as an unlawful controller.

Summary: Controller vs Processor Obligations at a Glance

The controller/processor distinction determines your legal responsibilities under GDPR. Controllers hold primary accountability; they set the rules, establish lawful bases, respond to data subjects, and appoint processors responsibly. Processors act under instruction, but carry their own direct obligations on security, records, breach notification, and sub-processor management.

Getting this classification right is not merely administrative: it determines which contracts you need, what notices you must publish, how to handle data breaches, and how regulatory liability is allocated when things go wrong.

GDPRLocal provides specialist support for controller and processor compliance, including DPA drafting, ROPA development, and processor due diligence frameworks. Contact our team to discuss your organisation’s compliance requirements.

Note: This article was written with AI assistance.