4.8Top Rated Service 2026verified by TrustindexTrustindex verifies that the company has a review score above 4.5, based on reviews collected on Google over the past 12 months, qualifying it to receive the Top Rated Certificate.
Under the UK GDPR, the difference between a controller and a processor matters because each role carries different legal responsibilities. The key question is usually who decides why and how personal data is used, and who is acting on someone else’s instructions.
Under the UK GDPR, a controller decides why and how personal data is used, while a processor handles that data on the controller’s behalf and under its instructions. Getting that distinction right matters because the legal duties, contracts, and accountability expectations are not the same for each role.
Controller
Usually decides the purpose and main means of processing
Processor
Processes personal data for a controller and follows instructions
Why it matters
Role confusion can lead to weak contracts, unclear responsibilities, and compliance gaps
The starting point is not job title, contract label, or what a supplier says on its website. Under the UK GDPR, the real question is what the organisation actually does in practice. A business becomes a controller when it decides the purpose of the processing and the essential way it will happen. A processor processes personal data for a controller and acts on that controller’s instructions.
A controller usually decides the objective behind the processing, such as running payroll, managing customer accounts, or sending marketing communications.
A processor provides services involving personal data, but does not decide the overall purpose of the processing for itself. It follows the controller’s instructions.
If an organisation makes key decisions about data use for its own purposes, it may be a controller even if the contract tries to describe it as a processor.
That practical analysis is part of wider accountability under the UK GDPR, because organisations should be able to explain and evidence the role they are performing.
In real working relationships, the line between controller and processor is usually identified by looking at decision making, independence, and purpose. These are the kinds of questions that matter most.
If the organisation decided why the data is being used, it is usually acting as a controller. That is often the strongest indicator.
A controller usually decides key matters like what data is collected, who it is shared with, and how long it is kept, even if a processor handles the operations.
If a supplier starts using data to improve its own services, build its own datasets, or pursue its own objectives, that may indicate controller status or a separate controller role.
Processors can make technical or practical choices, but they should still be acting within the framework and purpose set by the controller rather than deciding the purpose for themselves.
Once the role is identified, the responsibilities become clearer. Controllers and processors are both subject to the UK GDPR, but the obligations are not identical.
Controllers generally need to identify a lawful basis, provide transparency information, respond to rights requests, and make sure processors are chosen and managed appropriately.
Processors must keep data secure, follow instructions, help the controller meet certain obligations, and avoid appointing sub-processors without the required authority. Their contract position matters a great deal.
A useful approach is to ask who is steering the processing and who is delivering the service. The steering role is usually the controller. The delivery role is often the processor, though some arrangements are more complex and may involve joint controllers or separate controllers.
Role confusion usually happens because organisations focus too heavily on contracts or assume every supplier is automatically a processor. In practice, the analysis is often more nuanced.
The written contract matters, but it does not override the real arrangement. If the supplier is making its own key decisions about the data, the label alone will not solve the issue.
Some providers act as processors for one part of the service but controllers for another. For example, they may process data under instruction while also using some information for their own compliance, security, or service administration purposes.
Role analysis should be documented clearly, especially where the arrangement is complex or high risk. This often sits alongside broader governance, supplier due diligence, and sometimes a DPIA where the processing creates significant privacy risk.
The distinction becomes easier when you apply it to real examples rather than abstract definitions. These are common scenarios many organisations recognise.
A business that hires a payroll company will often remain the controller because it decides why staff data is processed. The payroll company is usually the processor for that service.
If a client instructs an agency to send campaigns using the client’s contact database, the client is often the controller. The agency may be the processor, though the details matter.
A software provider may act as a processor for hosted customer data but also act as a controller for account management, fraud prevention, billing, or its own legal obligations.
Where two parties jointly decide why and how personal data will be used, the issue may not be controller versus processor at all. It may instead involve joint controllers.
If you misidentify the role, the rest of the compliance structure can weaken around it. That can affect contracts, privacy notices, data sharing arrangements, security expectations, and who is expected to respond when something goes wrong.
This article is based on ICO guidance on PECR, direct marketing, cookies and similar technologies, together with relevant UK GDPR provisions that shape how consent, transparency, and lawful processing work in practice. For recent regulatory developments affecting PECR enforcement and compliance expectations, see our updates on PECR and direct marketing compliance under increased scrutiny and Data (Use and Access) Act commencement confirmed by the ICO.
Use the glossary for key terms, or download the checklist if you want a practical starting point for reviewing marketing and cookie compliance.
We use cookies and similar technologies to make our website work and to provide optional features such as live chat. Some cookies are strictly necessary for the site to function. Others (like Tidio chat) help us improve your experience.
We use Plausible Analytics, which is privacy-friendly and does not use cookies.
You can choose to accept all cookies, reject non-essential cookies, or manage your preferences.