Controller vs Processor: Why the Distinction Changes Your Obligations

Controller vs Processor: Why the Distinction Changes Your Obligations

In privacy, few distinctions carry more weight than controller versus processor. It decides which obligations you hold, what your contracts must say, and what a regulator or auditor expects of you. Most companies are both, depending on the data, and many get the line wrong.

Here is the difference, why it matters, and how to get it right.

The Basic Difference

A controller decides why and how personal data is processed. It sets the purpose. A processor acts on the controller's instructions and does not decide the purpose for itself. If you determine what data is collected and why, you are a controller. If you handle data on behalf of someone else, following their direction, you are a processor.

A simple test: whose decision is it? If your company decides the purpose of the processing, you are the controller. If a client decides and you execute, you are the processor for that data.

Why It Changes Your Obligations

Under GDPR and similar laws, the two roles carry different duties. Controllers bear the primary accountability: a lawful basis for processing, honoring data subject rights, transparency, and deciding retention. Processors have narrower but real obligations: process only on documented instructions, secure the data, support the controller's compliance, and not bring in sub-processors without permission.

Get the role wrong and you either take on duties that are not yours or, worse, miss duties that are. Both are risk.

Most Companies Are Both

The same company is often a controller for some data and a processor for other data. You are a controller of your own employee and marketing data. You may be a processor of the customer data your clients send you to handle. The role is per data flow, not per company. This is why data mapping matters: you cannot assign roles you have not identified.

What This Means for Your Contracts

The controller and processor relationship has to be written down. A data processing agreement sets out what the processor may do, the security expected, how sub-processors are handled, and what happens at the end of the relationship. If you are a processor, expect your clients to require one. If you are a controller using vendors, you should be putting one in place with each of them.

How ISO 27701 Handles It

The 2025 update to ISO 27701 sharpened the distinction between controller and processor responsibilities, making accountability easier to demonstrate. If you certify to ISO 27701, you map your controls to the role you actually play for each data flow. Getting the role right is not academic. It determines which requirements apply and what you must show an auditor.

Frequently Asked Questions

Can we be a controller and a processor at the same time?

Yes. It is normal. You are typically a controller of your own business data and a processor of data your clients entrust to you. The role is decided per data flow.

Do we need a data processing agreement?

If you process personal data on behalf of a client, expect to sign one. If you are a controller using vendors that touch personal data, you should have one with each of them.

How does this affect ISO 27701 certification?

Your controls and evidence are scoped to the roles you play. The 2025 revision made the controller and processor split clearer, so identifying your role correctly is a prerequisite, not a detail.

If you are not sure where your company sits as a controller or processor, that is the starting point of any real privacy program. A readiness assessment maps it out. Talk with a senior advisor at JBW Group.

← Back to all posts