What is a data controller?
A data controller is the party that decides why and how personal data is processed, and carries the main responsibility no matter which vendors are used. The test question is who decides the purpose. You remain responsible even when operations sit with a cloud vendor – the responsibility can be delegated in practice, but never contracted away.
Of all the roles in GDPR, the data controller is the most important to understand – because it’s usually you. It’s a role that’s easy to mistake for something you can outsource, but that’s exactly the core of it: the responsibility stays with you no matter how many vendors you bring in. Here’s what the role means.
The definition: whoever decides
The data controller is the party that decides why and how personal data is to be processed. It’s whoever makes the decisions: which data is collected, for what purpose, and broadly in what way. Responsibility follows that decision.
In the vast majority of cases, that’s you – the company that owns the customer relationship and runs the business. When you decide to keep a customer register, send newsletters, or store order history, you’re the data controller for that processing. You decided it should happen, and for what.
It’s a role about decisions, not about hands on the keyboard. Who technically carries out the processing is a separate question.
The test question: who decides the purpose?
The simplest way to determine whether you’re the controller is a single question: who decides the purpose? Whoever determines why the data is processed is the data controller.
The question cuts straight through what otherwise causes confusion. It doesn’t matter who stores the data, who operates the server, or who built the system. If you decided the data should be collected and for what purpose, the responsibility is yours. If someone else decides their own purpose for it, they’re responsible for that specific part.
Keep this separate from execution. A vendor that processes data for you according to your instructions is a data processor, not a controller. The distinction decides who answers to the authority when something goes wrong.
The responsibility can’t be outsourced
Here’s the most common and most dangerous misconception: that you can hand the responsibility to the vendor that handles the technology. You can’t.
You can outsource the actual processing – let a cloud vendor store the data, a hosting partner run the servers, an agency build the system. They then become your processors. But the overall responsibility stays with you, as the one who decided the purpose. The fact that operations physically sit elsewhere changes nothing.
A concrete example: you store your customer register with a major cloud vendor in their data center. It’s their hardware, their operations, their security at the infrastructure level. Yet you’re still the data controller for the register. You decided it should exist and why; the cloud vendor is a processor handling it for you. If something goes wrong with how the data is used, you’re the one who answers for it to the supervisory authority.
| Situation | Who's responsible? |
|---|---|
| You decide to keep a customer register | You – you chose the purpose |
| A cloud vendor stores the register for you | Still you; the cloud vendor is a processor |
| An agency builds the system for you | Still you; the agency is a processor |
The conclusion is that choosing vendors and contracts is part of managing your responsibility, not a way to get rid of it.
Joint data controllership, briefly
Sometimes there isn’t a single controller. Joint data controllership means two or more parties jointly decide why and how personal data is processed, and therefore share the responsibility and need to agree on how it’s divided between them. It should be kept separate from the controller-processor relationship, where only one party decides the purpose.
How to use this
In practice, the role means data protection is your responsibility, even when the technology belongs to someone else. Assume you’re the data controller for whatever you decide to collect. Treat choosing vendors that hold up and signing the right contracts as your responsibility. And raise these questions as early as the requirements stage, when they’re cheapest to build in.
Want help building systems where the responsibility is thought through from the start? At Weapp we’re happy to bring that into the systems work. Get in touch and we’ll go through what your responsibility means in practice.
Frequently asked questions
How do I know if we're the data controller?
Ask the test question: who decides why and how the personal data is processed? If you're the one deciding that the data should be collected and for what purpose, you're the data controller. That applies even if someone else technically stores or handles the data for you. Responsibility follows the decision about the purpose, not where the data happens to sit.
Can we hand the responsibility to the cloud vendor?
No. You can outsource the actual processing to a vendor, who then becomes a data processor, but the overall responsibility stays with you as the one who decides the purpose. Having operations sit with a cloud provider doesn't change that. Responsibility can be distributed in practical execution, but it can't be contracted away from whoever decides why.
What's the difference from a data processor?
The data controller decides why and how data is processed and carries the main responsibility. A data processor handles the data on the controller's behalf, following instructions, without deciding the purpose. The controller owns the decision, the processor carries it out. A cloud vendor or hosting partner is typically a processor, while you as the buyer are usually the controller.
What does joint data controllership mean?
Joint data controllership means two or more parties jointly decide why and how personal data is processed and therefore share the responsibility. It occurs when several actors jointly steer a processing activity, and requires them to agree on how responsibility is divided between them. It should be kept distinct from the controller-processor relationship.
What happens if we mishandle our responsibility?
As the data controller, you're the one who answers to the supervisory authority if something goes wrong, even when the cause lay with a vendor. That can lead to fines and reputational damage. That's exactly why it's worth taking the responsibility seriously as soon as a system is planned, and choosing vendors and contracts that hold up.