Data Controller vs Processor: What’s the Difference and Why It Matters

Privacy laws are full of vocabulary that sounds interchangeable until you realize it decides who’s responsible when something goes wrong. Two of the most important terms are “data controller” and “data processor.” They show up in the GDPR, in a growing number of US state privacy laws, and in almost every vendor contract that touches personal information.

The difference isn’t just academic. Whether your business is a controller or a processor determines which legal obligations apply to you, what your contracts need to say, and who regulators and customers will look to first after a data breach. Here’s a plain-English breakdown of data controller vs. processor, with examples, gray areas, and what each role means in practice.

A quick reminder: I’m not a lawyer, and this is a plain-English explainer, not legal advice. Privacy law is complex and varies by jurisdiction, so talk to a privacy professional about your specific situation.

The Short Version

• A data controller decides why and how personal data is processed.
• A data processor handles personal data on behalf of a controller, following the controller’s instructions.

The European Data Protection Board puts it simply in its FAQ on controllers and processors: the controller decides the “how and why” of processing, while the processor acts on the controller’s behalf, and that relationship needs to be governed by a contract. The EDPB also notes that the controller carries more responsibility and more obligations than the processor.

A quick way to remember it: the controller is the decision-maker, and the processor is the service provider carrying out those decisions.

What Is a Data Controller?

A data controller is any organization, or sometimes an individual, that determines the purposes and means of processing personal data. In practice, that usually means the business that collects information from its own customers, employees, or website visitors for its own reasons.

Examples of controllers include:

• An online store collecting customer names, addresses, and payment details to fulfill orders.
• A company keeping employee records for payroll and HR.
• A dental office storing patient contact information to schedule appointments.
• A newsletter publisher maintaining a subscriber list.

The key question is: who decided to collect this data, and for what purpose? That’s usually your controller.

What Is a Data Processor?

A data processor handles personal data on behalf of a controller. It doesn’t decide why the data is being processed. It provides a service, and personal data comes along for the ride.

Examples of processors include:

• A cloud hosting provider storing a company’s customer database.
• An email marketing platform sending newsletters to a business’s subscriber list.
• A payroll service processing employee pay on the employer’s behalf.
• A texting platform delivering appointment reminders to a business’s customers. (If you’re curious how business texting works behind the scenes, my guide to what 10DLC is covers the basics.)

The UK’s Information Commissioner’s Office offers a helpful test in its guide to controllers and processors: if you have no purpose of your own for processing the data and you only act on a client’s instructions, you’re likely a processor, even if you make some technical decisions about how the processing happens.

That last part is important. A cloud provider decides which servers to use and how to secure them, but that doesn’t make it a controller. Technical choices about how are allowed. Deciding why is what makes you a controller.

Data Controller vs Processor at a Glance

	Data Controller	Data Processor
Role	Decides why and how data is processed	Processes data on the controller’s behalf
Relationship to the data	Usually collects it for its own purposes	Receives it to provide a service
Main obligations	Legal basis, transparency, individual rights, security, vendor oversight	Follow instructions, keep data secure, support the controller
Level of responsibility	Highest	Lower, but still significant
Contract required	Must put one in place with each processor	Must sign one with each controller
Example	An online retailer	The retailer’s email marketing platform

What Controllers Are Responsible For

Controllers carry the heaviest compliance load. Under the GDPR and similar laws, a controller is generally responsible for:

• Having a lawful reason to collect and use personal data, such as consent or a contract.
• Being transparent through privacy notices that explain what data is collected and why.
• Honoring individual rights, such as requests to access, correct, or delete data.
• Keeping data secure and limiting collection to what’s actually needed.
• Reporting breaches to regulators and affected individuals when required.
• Choosing trustworthy processors and putting contracts in place with them.

That last point is often overlooked. Controllers are responsible for the processors they choose. If a vendor mishandles your customers’ data, regulators and customers will usually still look at you.

What Processors Are Responsible For

Processors have fewer obligations, but they aren’t off the hook. Generally, a processor must:

• Process personal data only on the controller’s documented instructions.
• Keep the data secure and confidential.
• Notify the controller promptly about data breaches.
• Get approval before using sub-processors and pass the same obligations down the chain.
• Help the controller respond to individual rights requests and meet its compliance duties.
• Delete or return data when the service ends.

These obligations are exactly what a data processing agreement is designed to spell out. I cover what that contract should include in What Is a Data Processing Agreement? A Plain-English Guide to DPAs.

Can a Business Be Both?

Yes, and most are. The roles apply to each processing activity, not to the company as a whole.

Take an email marketing platform. When it sends newsletters for its clients, it’s a processor for their subscriber data. But when it collects its own customers’ billing information to charge them for the service, it’s a controller for that data.

The same is true for almost any software company. It’s a processor for the data its customers upload, and a controller for its own customer accounts, employees, and website visitors.

What About Joint Controllers?

Sometimes two or more organizations decide together why and how personal data is processed. When that happens, they’re joint controllers, and they need an arrangement that spells out who handles which responsibilities, such as responding to individual requests.

Joint control comes up in situations like co-branded marketing campaigns, partnerships that pool customer data for a shared purpose, or some advertising and analytics arrangements. The key is shared decision-making about the purpose of the processing, not just working on the same data.

Common Gray Areas

The controller vs processor line isn’t always obvious. A few situations that often trip people up:

• Vendors that use data for their own purposes. If a processor starts using customer data to build its own products, train its own models, or market to those individuals, it may become a controller for that activity. This is one of the most important things to check in vendor terms.
• Professional service providers. Accountants, lawyers, and similar advisors often act as controllers in their own right, since they make independent professional decisions about the data they handle.
• Advertising and analytics tools. Some of these platforms act as processors, while others combine data across clients for their own purposes and act as controllers or joint controllers. The contract and how the tool actually works both matter.
• What the contract says isn’t the final word. Labeling a vendor a “processor” in a contract doesn’t make it one if it’s actually making its own decisions about why data is used. Regulators look at what really happens.

How These Terms Work in the US

The controller and processor terminology comes from European law, but it’s increasingly common in the US, too. Many of the comprehensive state privacy laws passed in recent years use the same “controller” and “processor” language and require written contracts between them.

California is the main exception in vocabulary. Its privacy law generally uses the term “business” for the role similar to a controller, and “service provider” or “contractor” for roles similar to a processor. The underlying idea is the same: the organization making decisions about personal data carries the main responsibility, and its vendors must be contractually limited in how they use that data.

Why Getting the Role Right Matters

Identifying your role correctly affects nearly everything about your privacy program:

• Which obligations apply to you, and how much work compliance takes.
• What your contracts need to say, including which DPAs you need to sign or provide.
• Who responds to customer requests to access or delete their data.
• Who’s accountable after a breach, and who has to notify whom.

It also helps to know where each type of personal data actually lives. If customer information is scattered across dozens of tools, it’s much harder to track which vendors are processing it and in what role. That’s one of the practical benefits of building a single source of truth for your core data.

A Quick Way to Figure Out Your Role

For any activity involving personal data, ask:

1. Did we decide to collect or use this data for our own purposes?
2. Do we decide what data is collected and how long it’s kept?
3. Would we use this data even if a client didn’t ask us to?
4. Are we following someone else’s instructions about what to do with it?

If you’re answering yes to the first three, you’re likely a controller. If the last question is the main one that applies, you’re likely a processor.

The Bottom Line

The difference between a data controller and a processor comes down to decision-making. Controllers decide why and how personal data is used, and they carry the most responsibility. Processors handle data on a controller’s behalf and must follow its instructions, keep data secure, and support its compliance.

Most businesses play both roles, depending on the data involved. Knowing which hat you’re wearing for each activity is the foundation of a sensible privacy program, and it tells you exactly what your contracts, policies, and vendor relationships need to cover.