A controller decides why and how data is used. A processor acts only on the controller's instructions. A data broker is a controller that collects and sells information about people it has no direct relationship with. The distinction decides who you can make demands of: you exercise your rights against the controller, not the processor — so knowing which is which tells you where to send a request that has to be answered.
The three roles
| Controller | Processor | Data broker | |
|---|---|---|---|
| Decides why data is used | ✓ | ✗ | ✓ (it's a controller) |
| Acts on someone else's instructions | ✗ | ✓ | ✗ |
| Relationship with you | Usually direct | None | None |
| Sells access to your data | Sometimes | No | That's the business |
| Who you send a rights request to | Them | Their controller | Them |
| Example | The shop you bought from | Their email platform | A people-search site |
Controller
The organisation that decides the purpose. The retailer choosing to build a customer list and market to it is the controller of that data. They carry the obligations: telling you what they hold, honouring objections, deleting when required.
Processor
Acts only on the controller's instructions. The email platform sending the retailer's newsletters is a processor — it holds your address but has no independent right to use it, and a contract restricts it to what the retailer directs.
Practical consequence: sending an erasure request to a processor usually achieves nothing. They'll forward it, or tell you to contact the controller, because acting on it unilaterally would breach their contract. Send it to the controller. How
Data broker
A controller in law, with one defining feature: no direct relationship with you. It didn't sell you anything or provide you a service. It compiled information about you from public records, commercial sources and other brokers, and sells access to the result. The full picture
Because it's a controller, your rights apply to it directly — which is exactly why broker opt-outs and erasure requests work at all.
Why the distinction is worth knowing
The commonest wasted effort in this area is sending requests to the wrong party — chasing a processor that cannot act, or a platform that is merely hosting.
Rule of thumb: ask "who decided to use my data this way?" That's the controller, and that's who owes you a response. If a company says "we only process this on behalf of our client", that's usually accurate rather than evasive — ask them who the client is.
The registration angle
Several US states now require data brokers specifically — not controllers generally — to register. California's registry underpins DROP, which is how a single request can reach every registered broker at once. Vermont, Texas and Oregon operate their own registries with different requirements.
Those registries are useful even without a platform attached: they tell you who exists in the category. The California framework
Where you sit
You're the data subject. Under the GDPR that gives you access, objection, erasure and rectification rights against controllers. Under the CCPA, Californians get rights to know, delete, correct and opt out of sale.
In both cases the rights run against whoever decided to use your data — which is why identifying the controller is the first practical step in any request. Making one