Controller vs Processor

The short answer

The controller makes the decisions about personal data: what to collect, why, and for how long. The processor handles the data for the controller and only on its instructions.

The role depends on what a company actually does with the data, not on what the contract calls it. One vendor can be a processor for your data and a controller for its own uses.

Controller

GDPR Article 4(7) defines the controller as the body that "determines the purposes and means of the processing of personal data." In plain words, it decides why the data is used and how.

• Who it is: usually you, when you put your customers' or employees' data into a SaaS tool.
• What it owes: it needs a legal reason to use the data (Article 6), must tell people how their data is used (Article 13), and must pick processors that give "sufficient guarantees" (Article 28(1)).
• Signs you are one: the UK regulator lists signs such as deciding to collect the data, choosing the purpose, and having a direct relationship with the people involved (ICO guide).

Processor

Article 4(8) defines the processor as the body that processes personal data "on behalf of the controller."

• Who it is: most SaaS vendors, for the data you load into their product.
• What it owes: it must work under a contract (Article 28(3)), usually a data processing agreement, and use the data only on your documented instructions.
• Its own vendors: it needs your written authorization, for a named company or in general, to bring in a subprocessor and stays fully liable to you for that subprocessor's work (Article 28(2) and 28(4)).

Labels do not settle it. The ICO says a company that decides purposes and means is a controller "regardless of how they are described in any contract." And under Article 28(10), a processor that starts setting its own purposes is treated as a controller for that processing.

Which one applies to you

For data you put into a vendor's product, you are normally the controller and the vendor is your processor. If you are a SaaS company yourself, you may be a processor for your customers and hire your own vendors as subprocessors.

Vendors often play both roles. The Atlassian DPA, for example, says Atlassian is a processor of Customer Data, and separately says it acts as a controller for the personal data described in its privacy policy.

Watch for the moment a vendor moves from one role to the other. This often shows up when a vendor wants to use customer data for its own goals, such as training AI models, building a commercial dataset, or advertising. For that use, it is acting more like a controller, and your DPA may no longer describe what is happening.

Example

Venpo flagged a change where HubSpot now collects your email engagement data for its commercial dataset. In its July 2026 privacy policy update, HubSpot described email open, click and bounce data from emails its customers send as data it collects in its own right, and listed it as a source for the business contact dataset it offers to enrichment customers. Using customer data to build the vendor's own dataset is the kind of use where you should ask which role the vendor claims, and what your DPA allows.

For example, imagine a support tool that stores your tickets as your processor. If its terms later say it may use ticket text to train a model it sells to everyone, that new use is decided by the vendor, not by you. You would ask the vendor to confirm in writing whether your tickets are included, and whether you can opt out.

How Venpo helps

Venpo monitors your vendors' DPAs, privacy policies and terms, and emails you a plain-English alert when wording about how they use your data changes. Its Fine Print Scan also answers whether each vendor trains AI on your data or uses it for ads, two common signs that a vendor is acting for its own purposes.