← Back to Data Processor Workflows: Third-Party Risks
Controllers vs. Processors: Navigating Liability
Whether your organisation is a controller or a processor for a given activity determines which obligations — and which liabilities — land on you. Getting this wrong is one of the most expensive mistakes in data protection, because it decides who answers to the regulator and who compensates data subjects when things go wrong.
The core distinction
The controller decides the why and the how: what data is collected, for what purpose, how long it is kept. The processor acts on the controller’s instructions: it handles the data but does not decide the purpose. The same company can be a controller for one activity and a processor for another.
Everyday examples
- A hotel is the controller of its guest records; the cloud booking system it uses is a processor.
- A payroll bureau processing salaries for client firms is a processor for client staff data — but the controller of its own employees’ records.
- A BPO answering calls for a US retailer is typically a processor; the retailer controls the purpose.
Why the label drives liability
Controllers carry primary responsibility: registration, honouring data subject rights, breach notification to the Commissioner, and answering for the whole chain — including failures by their processors. Choosing a careless vendor is itself a compliance failure by the controller. Processors are not off the hook: they face direct obligations around security and acting only on documented instructions. The moment a processor uses the data for its own purposes — say, mining a client’s customer list to market its own services — it becomes a controller for that use, and inherits full controller liability for it.
A Westmoreland restaurant signs up with a delivery app. Customer data leaks from the app’s database. Who answers? For orders placed through the app’s own platform, the app is likely a controller (it decides purposes — its own accounts, marketing, analytics). For the restaurant’s own phone-order list it uploaded for delivery routing, the app is a processor and the restaurant is the controller — meaning the restaurant must notify and answer for its vendor choice. One incident, two liability maps. This is why contracts must state the roles explicitly.
The practical test
Ask three questions about the activity: Who decided this data should be collected? Who decides what it is used for? Who decides when it is deleted? If the answers point to you, you are the controller — no matter what the contract label says. Regulators look at reality, not titles.
Quick check: Your IT support vendor can see customer data when fixing the database. Are they a processor?
Yes. Even incidental access during support work makes them a processor, which means you need a written Data Processing Agreement with them — covered in the next lesson — before granting access.
Quick check: Can two companies be joint controllers?
Yes. Where two organisations jointly decide purposes and means — e.g. co-branded promotions sharing one customer list — they are joint controllers and should document how responsibilities (notices, rights requests, breach handling) are split between them.
- Controllers decide the why and how; processors act on documented instructions.
- The same organisation can be controller for one activity and processor for another.
- Controllers answer for their processors — vendor selection is itself a compliance duty.
- A processor that uses data for its own purposes becomes a controller for that use, with full liability.