Quick Answer: Under the GDPR, a data controller determines why and how personal data is processed, while a data processor handles data solely on the controller's instructions. Liability differs significantly: controllers bear the broadest accountability, while processors face direct liability only when they act outside lawful instructions or breach GDPR obligations specifically directed at them.
Key Takeaways
- A data controller decides the purposes and means of processing; a data processor acts on the controller's behalf.
- Controllers carry primary GDPR liability; processors face direct liability under Article 82 only in specific circumstances.
- Both roles can exist simultaneously within one organization, a company can be a controller for its own customers and a processor for another business.
- A legally binding Data Processing Agreement (DPA) is mandatory whenever a controller engages a processor.
- Sub-processors require prior written authorization from the controller; the main processor remains fully liable for sub-processor conduct.
- Misclassifying your role is a compliance risk that can expose your organization to regulatory penalties.
- Processors who use personal data for their own purposes automatically become controllers for that processing activity.
- The UK's Data (Use and Access) Act 2026 introduces further changes that organizations operating under UK GDPR should review promptly.
What Is the Difference Between a Data Controller and a Data Processor Under GDPR?
A data controller is any entity that determines the purposes and means of processing personal data. A data processor is any entity that processes personal data on behalf of a controller, strictly following the controller's instructions [1].
The distinction hinges on decision-making authority. If your organization decides why data is collected and how it will be used, you are the controller. If your organization only handles data because another entity has instructed you to, and you have no independent say in the purpose, you are the processor.
Practical examples:
| Scenario | Role |
|---|---|
| An e-commerce retailer collecting customer purchase data | Controller |
| A cloud hosting provider storing that retailer's database | Processor |
| A payroll SaaS platform processing employee data for an employer | Processor |
| A marketing agency building its own prospect list | Controller |
| A CRM vendor accessing client data to provide support | Processor |
The ICO emphasizes that the label in a contract does not determine the role, actual conduct does [1]. A vendor called a "processor" in a contract but making independent decisions about data use is legally a controller regardless of what the agreement says.
What Are the Main Responsibilities of a Data Controller Under GDPR?
Controllers bear the heaviest compliance burden under the GDPR. They are accountable for the entire data lifecycle and must ensure any processor they engage meets GDPR standards [3].
Core controller obligations include:
- Establishing and documenting a lawful basis for every processing activity
- Providing transparent privacy notices to data subjects
- Facilitating data subject rights, access, rectification, erasure, portability, and objection
- Conducting Data Protection Impact Assessments (DPIAs) for high-risk processing
- Appointing a Data Protection Officer (DPO) where required
- Conducting due diligence before engaging processors and monitoring their ongoing compliance
- Executing a written Data Processing Agreement with every processor engaged [3]
Controllers cannot outsource accountability. Even when a processor causes a breach, the controller remains answerable to supervisory authorities for its choice of processor and the adequacy of contractual safeguards.
What Are the Main Responsibilities of a Data Processor Under GDPR?
Processors have direct GDPR obligations, not merely contractual ones, and cannot treat compliance as the controller's problem alone [3].
Direct processor obligations under GDPR include:
- Processing data only on documented instructions from the controller
- Implementing appropriate technical and organizational security measures
- Maintaining records of all processing activities carried out on behalf of controllers
- Notifying the controller of any data breach without undue delay
- Assisting the controller in fulfilling data subject rights requests
- Deleting or returning all personal data upon contract termination
- Engaging sub-processors only with prior written authorization from the controller [3]
"Processors have direct obligations under the GDPR, not just contractual duties, and face regulatory exposure if they act outside the controller's lawful instructions."
Who Is Liable If There Is a Data Breach: Controller or Processor?
Both can be liable, but the scope differs. Under Article 82 of the GDPR, any person who suffers damage from a GDPR infringement has the right to claim compensation from the controller or processor responsible [2].
Controllers are liable for damages caused by any processing that infringes the GDPR. Processors are liable only when they have failed to comply with GDPR obligations specifically directed at processors, or when they acted outside or contrary to the controller's lawful instructions [2].
Liability allocation in practice:
- If a processor suffers a breach because the controller gave inadequate security instructions, the controller likely bears primary liability.
- If a processor ignored the controller's security requirements, the processor bears direct liability.
- Both can be held jointly and severally liable, meaning a data subject can pursue either party for the full amount of damages, leaving them to apportion responsibility between themselves afterward.
A processor can escape liability by proving it was not at fault for the event causing the damage [2]. This is a high bar: the processor must demonstrate full compliance with its GDPR obligations.
Can a Company Be Both a Controller and a Processor at the Same Time?
Yes. An organization can simultaneously act as a controller for some processing activities and a processor for others, even within the same business relationship [1].
For example, a digital marketing agency may act as a controller when it manages its own employee HR data, and as a processor when it runs advertising campaigns using a client's customer data. The role is determined activity by activity, not company by company.
Can a Processor Become a Controller If They Use Data for Their Own Purposes?
A processor automatically becomes a controller the moment it uses personal data for purposes beyond the controller's instructions [1]. This is one of the most consequential misclassifications in practice.
If a cloud analytics vendor begins mining client data to train its own AI models without authorization, it has stepped outside the processor role and assumed controller status for that activity, with all the attendant GDPR obligations and liability exposure. No contract clause can prevent this reclassification; it is a matter of fact, not agreement.
How Do Data Processing Agreements Protect Processors from Liability?
A Data Processing Agreement (DPA) is a mandatory legal instrument under GDPR whenever a controller engages a processor [3]. For processors, a well-drafted DPA is the primary mechanism for limiting liability exposure.
A compliant DPA must specify:
- The subject matter, duration, nature, and purpose of processing
- The type of personal data and categories of data subjects involved
- The controller's obligations and rights
- Confidentiality requirements for authorized personnel
- Security measures to be implemented
- Conditions for engaging sub-processors
- Procedures for returning or deleting data at contract end [3]
When a processor acts strictly within the DPA's scope, liability for any resulting harm shifts predominantly to the controller. Conversely, if a processor exceeds those instructions, the DPA becomes evidence of the deviation rather than a shield.
What Happens If a Processor Violates GDPR Rules?
Processors that violate GDPR face both regulatory fines and civil liability for damages. Supervisory authorities can impose administrative fines directly on processors, up to EUR 20 million or 4% of global annual turnover for the most serious infringements, whichever is higher [2].
Beyond fines, processors face claims under Article 82 from data subjects who suffered harm. They may also face contractual liability to the controller under the DPA, including indemnification obligations.
Do Processors Need Their Own Data Protection Officer?
Processors are subject to the same DPO appointment thresholds as controllers. A processor must appoint a DPO if it carries out large-scale, systematic monitoring of individuals, or processes special categories of data or criminal conviction data on a large scale [1].
Being a processor does not exempt an organization from the DPO requirement. Many large cloud providers and SaaS platforms that act as processors are required to maintain a DPO precisely because of the volume and sensitivity of data they handle.
What Is the Difference in GDPR Fines Between Controllers and Processors?
The GDPR's two-tier fine structure applies equally to controllers and processors. Tier one covers less severe infringements (up to EUR 10 million or 2% of global turnover); tier two covers the most serious violations, including unlawful processing and failure to respect data subjects' rights (up to EUR 20 million or 4% of global turnover) [2].
There is no statutory discount for processors. However, in practice, supervisory authorities assess culpability, cooperation, and the nature of the infringement when determining fine amounts, factors that may result in different outcomes for controllers versus processors in the same incident.
Do Sub-Processors Have Different Liability Than Main Processors?
Sub-processors carry the same GDPR obligations as main processors but are contractually bound to the main processor rather than directly to the controller. The critical distinction: the main processor remains fully liable to the controller for the sub-processor's performance [3].
If a sub-processor causes a breach, the controller's legal recourse runs against the main processor. The main processor must then pursue the sub-processor separately. Sub-processors may also face direct regulatory action from supervisory authorities for their own GDPR violations.
Sub-processor rules at a glance:
- Prior written authorization from the controller is required before engaging any sub-processor
- The main processor must impose equivalent data protection obligations on the sub-processor
- The main processor cannot escape liability by pointing to sub-processor fault
How Do You Determine If You Are a Controller or Processor for Your Business?
The determination turns on a single question: does your organization independently decide why personal data is being processed? If yes, you are a controller. If you only process data because another entity has instructed you to, and you have no independent purpose, you are a processor [1].
A practical decision checklist:
- Who decided to collect this data in the first place?
- Who determined what the data would be used for?
- Does your organization have discretion over how the data is processed, or are you following another party's specifications?
- Would the processing stop if the other party withdrew their instructions?
- Are you using the data for any purpose that benefits your organization independently?
If your answers point in different directions across these questions, you may be a joint controller, a situation requiring a separate transparency arrangement with the other party [1].
What Are Common Mistakes Companies Make With Controller and Processor Roles?
Misclassification is the most prevalent error, and it carries real compliance consequences. Organizations frequently assume that being called a "vendor" or "service provider" in a contract makes them a processor, when their actual conduct qualifies them as a controller.
Other frequent mistakes:
- Skipping the DPA: Controllers engaging processors without a written DPA are in direct breach of GDPR, regardless of how secure the processor's systems are.
- Failing to vet sub-processors: Controllers often overlook that their processor has engaged sub-processors without authorization or equivalent contractual protections.
- Assuming processors handle data subject rights: Controllers remain responsible for responding to data subject requests; processors only assist.
- Ignoring re-classification risk: Processors that expand their services and begin using client data for analytics, model training, or benchmarking may inadvertently become controllers without recognizing the shift.
For organizations managing consent and data flows across websites and digital properties, a consent management platform such as Biscotti CMP can help controllers document lawful bases and manage consent records, a foundational element of controller accountability under GDPR.
How Should a Small Business Handle Controller vs. Processor Responsibilities?
Small businesses are not exempt from GDPR's controller-processor framework. If a small business collects customer data, even just email addresses for a newsletter, it is a controller and must comply with all controller obligations.
Practical steps for small businesses:
- Map every tool or vendor that handles personal data on your behalf (email platforms, analytics tools, payment processors, CRMs).
- Confirm whether a signed DPA exists with each vendor.
- Verify that each vendor's DPA meets GDPR minimum requirements.
- Publish a compliant privacy notice that accurately describes your processing activities.
- Establish a process for responding to data subject requests within the 30-day statutory window.
The UK's Data (Use and Access) Act 2026, which received Royal Assent on June 19, 2026, introduces further modifications to data protection law that UK-based small businesses should review with legal counsel to ensure their controller obligations remain current [1].
Frequently Asked Questions
Q: Is a SaaS company always a processor? A SaaS company is a processor only when it processes personal data strictly on behalf of its customers and for no independent purpose. If it uses customer data for its own analytics, product improvement, or marketing, it becomes a controller for those activities.
Q: Does a processor need to register with a supervisory authority? Registration requirements vary by EU member state. However, processors must maintain internal Records of Processing Activities (RoPA) under Article 30 of the GDPR if they employ 250 or more people, or if the processing is likely to result in a risk to data subjects.
Q: Can a processor refuse a controller's instruction? Yes, if following the instruction would require the processor to violate GDPR. In such cases, the processor should notify the controller and, if the instruction is not corrected, may need to terminate the relationship.
Q: What is a joint controller arrangement? Joint controllers exist when two or more entities jointly determine the purposes and means of processing. They must document their respective responsibilities in a transparent arrangement and make the essence of that arrangement available to data subjects [1].
Q: How long does a DPA need to remain in force? A DPA should remain in force for the duration of the processing relationship. Upon termination, it governs the processor's obligation to delete or return all personal data.
Q: Are processors liable for fines imposed on controllers? No. Fines are assessed against the entity that committed the infringement. However, processors may face separate fines for their own violations, and may face indemnification claims from controllers under the DPA.
Q: Does GDPR apply to processors located outside the EU? Yes. GDPR applies to processors outside the EU when they process personal data of EU residents on behalf of EU-based controllers, or when they are otherwise subject to GDPR's territorial scope under Article 3.
Q: What is the difference between a DPA and a Standard Contractual Clause? A DPA governs the controller-processor relationship domestically. Standard Contractual Clauses (SCCs) are specific contractual mechanisms for transferring personal data to third countries outside the EU/EEA that lack an adequacy decision.
Conclusion
Controller vs. Processor: Understanding Your Liability Under the GDPR is not an abstract legal exercise, it determines who faces regulatory fines, who compensates data subjects, and who is answerable to supervisory authorities when something goes wrong. The distinction rests on a factual question about decision-making authority, not on contract labels.
Actionable next steps:
- Conduct a data mapping exercise to identify every processing activity and your organization's role in each.
- Audit existing vendor contracts to confirm compliant DPAs are in place with every processor you engage.
- Review sub-processor arrangements to ensure prior authorization exists and equivalent obligations are imposed.
- If you operate as both a controller and a processor across different activities, document each role separately.
- For UK organizations, review the implications of the Data (Use and Access) Act 2026 with qualified legal counsel.
- Deploy a consent management solution such as Biscotti CMP to maintain auditable consent records and support your controller obligations.
Misclassification is not a technicality, it is a compliance gap with direct financial and reputational consequences. Getting the roles right from the outset is the most cost-effective GDPR investment any organization can make.
References
[1] What Are Controllers And Processors - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/controllers-and-processors/what-are-controllers-and-processors/?utm_source=openai
[2] Art 82 GDPR - https://gdpr-info.eu/art-82-gdpr/?utm_source=openai
[3] Controller And Processor Relationships - https://dataprotection.ie/en/organisations/know-your-obligations/controller-and-processor-relationships?utm_source=openai