What Is the Difference Between a Data Controller and a Data Processor?
GDPR splits obligations between controllers and processors, and getting the label wrong for your business can mean missing entire categories of legal requirements. Here's how to tell which one you are.
GDPR builds most of its obligations around a distinction that trips up a surprising number of businesses: whether you’re a controller or a processor for a given piece of personal data. The two roles carry meaningfully different responsibilities, and many businesses are actually both, just for different data, at the same time.
The definitions
- Controller: the entity that determines the purposes and means of processing personal data, in plain terms, the one deciding why the data is collected and how it will be used. If you decide to run Google Analytics on your site to understand your own visitors, you’re the controller of that analytics data.
- Processor: the entity that processes personal data on behalf of and under the instructions of a controller, without deciding the purposes itself. A payroll provider processing your employees’ data according to your instructions, or a customer support platform hosting your users’ tickets, is acting as a processor.
Why the distinction actually matters
The two roles carry different obligations under GDPR:
| Controller | Processor | |
|---|---|---|
| Lawful basis | Must establish and document one | N/A, relies on the controller’s basis |
| Data subject rights requests | Must respond directly | Must assist the controller in responding |
| Breach notification | Must notify the supervisory authority within 72 hours | Must notify the controller “without undue delay” |
| Contract requirement | Must have a Data Processing Agreement (DPA) with any processor it uses | Must have a DPA with the controller |
| Primary liability | Generally bears the greater share of regulatory exposure | Can still be independently liable, particularly for security failures |
Get the label wrong, and you can miss an entire category of obligation, a business that’s actually a controller but assumes it’s “just processing data for someone else” may skip the lawful-basis and direct-response requirements it actually owes.
You can be both, for different data
This is the part that catches businesses off guard. A SaaS company is typically:
- The controller of its own website visitors’ analytics data, its employees’ HR data, and its own marketing lists, and
- The processor of its customers’ end-user data that flows through the product, since the customer decided to collect that data and the SaaS company just handles it on their behalf.
Same company, two different roles, depending on whose data and whose decision it was to collect it.
The contract that formalizes this: the DPA
Whenever a controller uses a processor, GDPR (Article 28) requires a Data Processing Agreement spelling out the processor’s obligations, security measures, sub-processor rules, and breach notification timelines. If you’re a controller sending data to any vendor, that vendor should have a DPA available; if you’re a processor for your own customers, you should be able to offer one. We cover this in depth in our DPA guide and our Article 28 checklist.
Usercentrics
Once you're tracking controller and processor relationships across multiple vendors and, if you're a SaaS business, your own customers, keeping the DPAs and responsibility mapping straight becomes its own project. Usercentrics' multi-brand, multi-domain management and detailed consent reporting are built for exactly that kind of multi-relationship tracking.
A quick test for your own business
For any given piece of personal data, ask: who decided this data would be collected, and why? If the answer is “we did, for our own purposes,” you’re the controller. If the answer is “our customer/client decided that, we’re just handling it for them,” you’re the processor for that data.
This guide is educational and not legal advice. Controller/processor determinations can be fact-specific and occasionally involve joint-controller arrangements not covered here; consult a privacy attorney for your specific relationships.