One of the first questions GDPR forces you to answer is deceptively simple: are you a controller or a processor? The answer shapes your obligations, your liability and the contracts you must sign — and getting it wrong undermines the rest of your GDPR compliance.
This guide explains both roles, how to tell which applies to each activity, joint control, the mandatory Article 28 contract, and how obligations and liability differ.
Why the distinction matters
GDPR splits responsibility for personal data between two roles: the controller and the processor. Knowing which you are — for each activity — determines your obligations, your liability, and the contracts you need. It is one of the first things to get right, because almost everything else follows from it.
The short version: the controller decides why and how data is processed; the processor processes on the controller’s behalf, following instructions. Many organisations are controllers for some data and processors for other data at the same time.
Controller vs processor at a glance
The table summarises the key differences before we explore them.
| Aspect | Controller | Processor |
|---|---|---|
| Decides purposes & means | Yes | No — acts on instructions |
| Lawful basis | Must establish it | Relies on the controller’s |
| Handles rights requests | Primary responsibility | Assists the controller |
| Contract required | Must put a DPA in place | Must sign the DPA (Art 28) |
| Breach duty | Notifies the regulator (72h) | Notifies the controller without delay |
| Sub-processors | Authorises them | Needs controller permission |
| Example | A company using a SaaS tool | The SaaS provider or cloud host |
Free resource
GDPR Policy Templates
Get the processor agreement and role-mapping templates you need.
What a controller is
A controller determines the purposes (why) and the means (how) of processing personal data. If your organisation decides what data to collect, why, and what to do with it, you are the controller for that activity — and you carry primary responsibility under GDPR.
Controllers must establish a lawful basis, be transparent, honour data subject rights, and account for compliance. The buck stops with the controller.
What a processor is
A processor processes personal data on behalf of a controller, acting only on the controller’s documented instructions. Cloud hosts, SaaS tools, payroll bureaus and email providers are common examples — they handle the data, but they don’t decide the purpose.
Processors have their own direct obligations under GDPR, but they are narrower and framed around acting faithfully for the controller.
How to tell which you are
The test is decision-making power, not who physically holds the data. Ask: who decides why this data is processed and the essential means? If it is your organisation, you are the controller; if you are simply executing someone else’s instructions, you are the processor.
A processor who starts making its own decisions about the data — using it for its own purposes — becomes a controller for that activity, with the heavier obligations that brings.
You can be both
Most organisations wear both hats. A SaaS company is a processor for its customers’ data, but a controller for its own employee and prospect data. The role is assessed per processing activity, not per company.
So the right question is never “are we a controller or a processor?” in the abstract, but “what are we for this processing?”
Joint controllers
Sometimes two or more organisations jointly determine the purposes and means — they are joint controllers. They must agree, in a transparent arrangement, who is responsible for what, particularly around transparency and data subject rights.
Joint control is easy to fall into — for example through shared platforms or co-branded campaigns — so it is worth checking whether your collaborations create it.
The mandatory contract: Article 28
Whenever a controller uses a processor, GDPR requires a written contract — a Data Processing Agreement under Article 28. It must set out the subject matter, duration, nature and purpose of processing, the types of data, and a defined set of processor obligations.
Operating without this contract is itself a breach, so a DPA should be in place with every processor before data starts flowing.
Processor obligations
Under the DPA and GDPR, a processor must: act only on documented instructions; ensure staff confidentiality; implement appropriate security; not engage sub-processors without authorisation; assist the controller with rights requests, security and breach duties; and delete or return data at the end of the contract.
These obligations make the processor a genuine partner in compliance, not just a passive vendor.
Breach responsibilities
Breach duties differ by role. A controller must notify the supervisory authority of a qualifying breach within 72 hours, and affected individuals where the risk is high. A processor must notify the controller without undue delay on becoming aware of a breach, so the controller can meet its deadline.
This chain only works if your DPA and incident processes make the handoff fast and clear.
Liability of each
Both roles can be liable. Controllers are liable for damage caused by non-compliant processing; processors are liable where they breach processor-specific obligations or act outside the controller’s lawful instructions. Individuals can claim against either, and regulators can fine either.
So “we’re only the processor” is not a shield — processors carry real, direct exposure under GDPR.
Common real-world examples
Concrete cases help. A retailer using an email platform is the controller; the platform is the processor. An employer using a payroll provider is the controller; the provider is the processor. Two companies running a joint loyalty scheme may be joint controllers. A cloud host storing a customer’s data is the processor.
Mapping your relationships this way tells you exactly which contracts and obligations you need.
Getting your role right
Misclassifying your role leads to missing or misapplied obligations — a controller behaving like a processor may neglect lawful basis and rights; a processor acting like a controller may breach its instructions. Document your role for each processing activity, and reflect it in your contracts and records.
This single piece of clarity prevents a surprising number of downstream compliance problems.
How ISpectra helps
Correctly classifying controller and processor roles is foundational to GDPR compliance. ISpectra Technologies helps organisations map their roles per activity, put compliant Article 28 DPAs in place, define joint-controller arrangements, and align breach and rights processes across the chain.
If you are unsure where you sit in your data relationships, a short review will clarify it quickly.
In one paragraph
Under GDPR, the controller decides why and how personal data is processed and carries primary responsibility — lawful basis, transparency, rights and accountability — while the processor processes on the controller’s behalf under documented instructions. The role is assessed per activity, so most organisations are both. A written Article 28 DPA is mandatory between them, processors have real direct obligations and liability, and breach duties differ (controllers notify regulators in 72 hours; processors notify controllers without delay). Two organisations that jointly decide purposes are joint controllers. Get your role right for each activity, and the right obligations and contracts follow.
Free consultation
Need help with GDPR?
Talk to our data-protection specialists — we’ll map your fastest path to compliance.
A quick decision guide
If you are ever unsure of your role for a given activity, walk through three questions. First, who decided this data would be collected and why? If it was your organisation, you are the controller. Second, are we acting purely on someone else’s written instructions, with no freedom to use the data for our own ends? If so, you are the processor. Third, are we deciding the purposes jointly with another organisation? If yes, you may be joint controllers.
Run that test for each distinct activity and record the answer. The exercise rarely takes long, and it produces the clarity you need to choose the right contracts, assign breach duties correctly, and avoid the all-too-common mistake of a processor quietly drifting into controller territory by reusing client data for its own purposes.