Controllers and Processors: The Roles Behind “GDPR Compliance”

Details: Category: Digital & Data Responsibilities; 3 m; Last Updated: 26 May 2026; 61

Applicability Scope: UK‑wide
Authority Level: Factual / Descriptive
Who This Applies To: All businesses
Content Status: Current
Last Verified Against: ICO guidance (version current at writing)
What This Does Not Do: This article does not determine which role applies in a specific situation, provide guidance on assigning roles, or explain how to draft contracts or processing agreements. It does not resolve edge cases or interpret enforcement outcomes.
Next Step When This Isn’t Enough: If you need to establish how these roles apply to a particular arrangement, consult official guidance from the relevant authorities or seek professional advice. WBI explains role structure, not how to classify individual cases.
Editorial Sensitivity: Medium

“Controller” and “processor” are defined roles within data protection law, not interchangeable labels. This article explains what each role represents, how responsibility is distributed between them, and why understanding these roles is essential to making sense of “GDPR compliance”.

Discussions about data protection often use the phrase “GDPR compliance” as if it were a single state a business can achieve. In practice, responsibility under data protection law is not assigned to organisations in the abstract, but to defined roles within a system.

The two core roles you will see referenced most often are controller and processor. These are not informal labels or job titles. They are structural positions defined in law, and they determine how responsibility is distributed when personal data is used.

What a “role” means in data protection

In this context, a role describes how an organisation relates to personal data within a wider system. It answers questions such as:

Who decides why personal data is used?
Who decides how it is used?
Who is acting on whose behalf?

The answers to those questions are what define the controller and processor roles. Responsibility flows from those answers, not from contracts alone, and not from how parties describe themselves.

The controller: deciding purpose and means

A controller is the party that determines the purposes and means of processing personal data. In simpler terms, the controller decides why personal data is being used and how that use will take place.

This does not require technical control or day‑to‑day handling of the data. A controller may never directly touch the systems where data is stored. What matters is decision‑making authority over the use of that data.

Because of this position, the controller carries primary responsibility within the system. Many of the obligations discussed under data protection law attach to the controller role because that role sets the direction for processing activity.

The processor: acting on behalf of the controller

A processor is a party that processes personal data on behalf of a controller. The processor does not decide the purpose of processing for itself. Instead, it carries out processing activity within the boundaries set by the controller.

Processors are often service providers — such as hosting companies, software platforms, or outsourced services — but being a service provider does not automatically make an organisation a processor. The defining feature is not the commercial relationship, but whether the organisation is acting under the controller’s instruction rather than determining its own purposes.

Although processors have their own defined responsibilities, those responsibilities exist in relation to the controller’s decisions. The processor role is therefore inherently relational: it only makes sense within a system that includes a controller.

How the roles relate to each other

The controller and processor roles are not peers in the same way two contracting businesses might be. They occupy different structural positions within the same system.

One way to think about this is:

The controller sets direction.
The processor carries out processing within that direction.

This relationship explains why responsibility is not evenly distributed, and why it cannot be reassigned simply by agreement or convenience. Contracts can reflect roles, but they do not create them.

Common sources of confusion

Many misunderstandings about data protection arise from treating “controller” and “processor” as flexible or negotiable labels. Some common points of confusion include:

Assuming a party is a processor simply because it provides a service.
Assuming responsibility is shared equally whenever multiple organisations are involved.
Treating role assignment as a contractual choice rather than a structural outcome.

This article does not resolve those situations or provide tests for classification. Its purpose is to make clear that the roles exist as part of a defined system, and that responsibility follows those roles once they are established.

Why this role structure matters

The controller–processor distinction underpins much of the data protection framework. Later concepts — such as lawful bases for processing, data handling obligations, and enforcement — rely on these roles being clearly understood.

Without a clear role model, “compliance” becomes a vague aspiration rather than a structured set of responsibilities. Understanding the roles does not tell you what to do in a specific situation, but it does explain where accountability originates and how it is distributed.

Using this article within the WBI system

This article is designed to function as a structural reference. Other WBI articles can build on it by discussing:

the conditions under which processing is permitted,
how obligations attach to different roles, and
what happens when responsibilities are not met.

Together with the The ICO: What It Is, What It Regulates, and When It Gets Involved, this establishes a stable mental model: institutions regulate the system, roles define responsibility within it, and obligations flow from those roles.