What is a data processor?
A data processor is whoever handles personal data on behalf of someone else – typically a cloud vendor, hosting partner, or development agency. The processor follows the data controller's instructions and never decides the purpose itself. Under GDPR, the relationship requires a written processing agreement governing how the data may be handled.
When you buy a cloud service or hire an agency that handles your customers’ data, the other party is almost always a data processor. The term is central to GDPR, but easy to confuse with the controller’s role. Here’s what a processor is, where the line falls, and what the relationship requires of you.
The definition: whoever processes on someone’s behalf
A data processor is whoever handles personal data on behalf of someone else. The key phrase is “on behalf of.” The processor handles data belonging to another party’s business, according to that party’s instructions, without having decided itself why it was collected.
In practice, the processor is usually a vendor in your digital chain:
- The cloud vendor that stores your database of customer data.
- The hosting partner that runs the servers where your service operates.
- The development agency that gets access to personal data while building or maintaining the system.
What they all have in common is that they work with the data on your behalf. They’re tools and executors in your processing, not owners of it.
The line to the data controller
The most important distinction is the one against the data controller, and the best test question is simple: who decides the purpose?
The data controller is whoever decides why and how data should be processed. That’s usually you – the company that owns the customer relationship and decides what’s collected and for what. The processor, by contrast, takes that data and handles it according to your instructions, with no say of its own over the purpose.
A concrete example makes it clear. You sell a service and keep a customer register in a SaaS system. You’re the data controller: you decided the register should exist, and why. The SaaS vendor that stores and runs the system is the processor: they handle the data for you, but they weren’t the one who decided to collect it. Same data, two roles – and the role is decided by who makes the decision, not who technically stores it.
The relationship requires a written agreement
As soon as a processor handles personal data on your behalf, GDPR requires a written data processing agreement – often called a DPA. It’s not a formality to put off; it’s a precondition for the processing to be lawful.
The agreement sets the ground rules between you:
| Part of the agreement | What it governs |
|---|---|
| Instructions | That the processor only handles the data as you've determined |
| Security measures | What protection the processor must have in place |
| Subprocessors | Which vendors the processor may in turn engage |
| Deletion | How the data is to be handled when the collaboration ends |
Large vendors usually have a ready-made standard agreement that’s rarely negotiable. That doesn’t mean you can skip reading it – on the contrary. It’s there you see which subprocessors are used, where your data ends up, and what protection is promised.
The most common misunderstanding
The misconception that keeps coming back is that the processor “takes over responsibility” once you outsource the processing. It doesn’t. A processor never decides the purpose, and therefore can’t carry the overall responsibility for it either.
The moment a vendor starts using the data for its own purposes – say, analyzing your customer data for its own ends – it’s no longer just a processor for that particular processing, but becomes a controller for it itself. The line always falls at who decides why.
How to put this to use
In practice, that means three things for you as a system buyer. Map out which of your vendors are processors – usually more than you’d think, since even analytics, support, and email tools can process personal data. Make sure there’s a processing agreement with each one. And read the agreement, especially what it says about subprocessors and data handling.
The payoff for doing this early is twofold. First, the processing becomes lawful, which is your responsibility as the data controller. Second, you get a map of where your customers’ data actually ends up – something that’s hard to piece together after the fact, once the vendors are already in place and the integrations are built.
If you’d like help building data protection and the right contract requirements in from the start, at Weapp we’re happy to be part of that systems work. Get in touch and we’ll go through what your processor chain looks like.
Frequently asked questions
Who is the data processor in a typical systems project?
Usually the vendors around your service: the cloud vendor that stores the data, the hosting partner that runs the servers, and the development agency that handles personal data during the work. What they have in common is that they process data on your behalf, according to your instructions, without deciding themselves why the data is collected or what it's used for.
What's the difference between a data processor and a data controller?
The controller decides why and how personal data is processed – that's usually you, as the party that owns the customer relationship. The processor handles the data on your behalf and according to your instructions, with no say over the purpose. In short: the controller owns the decision, the processor carries it out. That distinction is what the whole division of responsibility rests on.
Do you need an agreement with your data processor?
Yes. GDPR requires a written data processing agreement, often called a DPA, as soon as someone processes personal data on your behalf. Among other things, the agreement governs which instructions apply, what security measures are required, and how the data is to be deleted. Without such an agreement, the processing isn't compliant with the regulation.
Can a data processor decide how the data is used?
No, and that's the whole point of the role. A processor may only handle the data according to the controller's instructions. The moment a vendor starts deciding its own purposes for the data, it effectively becomes a controller for that particular processing itself. The line falls at who decides why, not who touches the data.
What is a subprocessor?
A subprocessor is a vendor that your processor, in turn, brings in to carry out parts of the processing – for example, an underlying cloud service. These must be disclosed and approved, and the processing agreement governs how they may be used. You retain responsibility even for links you don't have a direct contract with, so the chain is worth knowing.