Share this article
Controllers vs processors vs subprocessors: All you need to know
Evan Rowse
GRC Subject Matter Expert
Accelerating security solutions for small businesses Tagore offers strategic services to small businesses. | A partnership that can scale Tagore prioritized finding a managed compliance partner with an established product, dedicated support team, and rapid release rate. | Standing out from competitors Tagore's partnership with Vanta enhances its strategic focus and deepens client value, creating differentiation in a competitive market. |
Organizations often participate in multiple data processing relationships, acting as a controller, processor, or subprocessor depending on the activity. As vendor ecosystems expand, a single processing activity can involve several parties, each with different responsibilities under the General Data Protection Regulation (GDPR).
Misclassifying these roles can create gaps in your contracts, Records of Processing Activities (RoPAs), vendor oversight, and breach response, increasing the risk of GDPR violations and substantial financial penalties. This guide breaks down the differences between controllers, processors, and subprocessors and explains how their responsibilities fit together under the GDPR.
What is a data controller?
A data controller is the entity that decides why and how the processing activity takes place. Under GDPR Article 4, in specific cases the purposes and means of processing, and the controller itself, may instead be determined by Union or Member State law.
A controller doesn’t necessarily have to be an organization; individuals, consultants and experts, public authorities, agencies, and other bodies that initiate processing activities can all be data controllers.
More than one organization can also act as a controller for the same processing activity. Under GDPR Article 26, if two organizations determine the purpose and means of processing, they are joint controllers. Joint controllers must transparently determine their respective roles and responsibilities, particularly for fulfilling data subject rights, and inform data subjects of the arrangement.
Under GDPR Article 24, controllers are responsible for implementing appropriate technical and organizational measures to ensure and demonstrate that processing meets GDPR requirements. They are also responsible for reporting personal data breaches where required (Articles 33 and 34), and taking reasonable steps to ensure downstream processing arrangements support GDPR compliance.
Sample scenario: AcmeCo is an online retailer that sells consumer electronics. To fulfill orders and manage customer accounts, it collects customers’ names, email addresses, shipping addresses, payment information, and order history. It decides which information to collect, why it’s needed, how long to retain it, and which systems and vendors can access it. Because AcmeCo determines the purposes and means of this processing, it is the controller.
{{cta_withimage14="/cta-blocks"}} | GDPR compliance checklist
What is a data processor?
A data processor is an entity that handles personal information on behalf of a controller. Processors don’t have to be organizations and can also include individuals, public authorities, agencies, and other bodies that process personal data.
Unlike controllers, processors don't determine the purposes and essential means of processing, though they may choose non-essential, technical means such as the specific systems or security tooling used. Their responsibilities are more limited and primarily revolve around following the controller's documented instructions and meeting the obligations set out in GDPR Article 28.
When a processor is onboarded with a controller, both parties are required under GDPR Article 28 to enter into a data processing agreement (DPA). This document outlines the controller’s expectations surrounding the processing activity, including:
- Processing personal data only on the controller's documented instructions
- Implementing appropriate technical and organizational measures
- Helping the controller meet its obligations under Articles 32–36
- Assisting the controller with data subject rights
- Notifying the controller of personal data breaches
- Deleting or returning all personal data at the end of the engagement
Sample scenario: AcmeCo uses SupportXYZ, a SaaS customer service platform, to manage tickets from its buyers. SupportXYZ processes customer names, contact details, order information, and support interactions related to customer inquiries and payment disputes in order to provide the service. AcmeCo determines how and why the information is used for customer support, while SupportXYZ handles the data on AcmeCo’s behalf under the DPA, making it the processor.
What is a data subprocessor?
Subprocessors are entities that handle personal information on behalf of processors. In a standard vendor relationship, you can think of subprocessors as fourth parties and other downstream dependencies, such as a ticketing system or computing infrastructure your vendor uses.
Under the GDPR, a processor is required under GDPR Article 28 to obtain the controller's prior written authorization before engaging a subprocessor. The controller can either approve a specific subprocessor in advance or give the processor general authorization to engage subprocessors. With general authorization, the processor is required to inform the controller before adding or replacing a subprocessor, as well as give the controller an opportunity to object.
When a processor engages a subprocessor, it is required to enter into a written contract with the subprocessor that requires the same level of data protection as the controller-processor DPA. This requirement also applies to existing subprocessor relationships, as pre-existing commercial arrangements don’t automatically satisfy GDPR requirements. If a processor already relies on a subprocessor, it should take steps such as:
- Obtain controller authorization to continue relying on them
- Execute a written subprocessor agreement
- Address applicable international transfer requirements
- Update RoPAs to reflect the relationship
- Notify controllers if the subprocessor wasn’t disclosed
Sample scenario: SupportXYZ relies on CloudHostABC to host its customer service application and store the customer data it processes for AcmeCo. CloudHostABC provides the underlying infrastructure, including servers and storage, but does not decide why AcmeCo’s customer data is processed or use it for its own purposes. Because CloudHostABC has no direct relationship with AcmeCo and processes the data on behalf of SupportXYZ, it is a subprocessor.
Controllers vs processors vs subprocessors at a glance
An organization doesn’t have one fixed GDPR role. Its role is determined by the processing activity, so the same organization may be a controller for one activity but a processor or subprocessor for another.
The table below summarizes the key differences between the three roles:
{{cta_withimage11="/cta-blocks"}}| The US data privacy checklist
How to accurately determine your role under the GDPR
To determine your role under the GDPR, assess whether you decide the purpose (controller), process on behalf (processor), or support a processor (subprocessor) in handling personal data. Also, consider whether different roles apply to you.
“Under the GDPR, roles are determined per processing activity, not per company. The same SaaS provider is a controller for its employee payroll data, a processor for its customers' end-user data, and a joint controller with an ad partner for its own marketing analytics. Until teams internalize that role is activity-scoped, their RoPA and DPAs could be misaligned with what they’re actually doing.”
Evan Rowse
For example, Company X operates a customer support SaaS platform that businesses use to manage customer tickets. Company X provides the platform to Customer Y, a retailer. Customer Y’s support agents use the platform to manage tickets from their customers, which contain their name, email, order history, and potentially order disputes. Here, Customer Y is the controller and Company X is the processor since the data belongs to Customer Y’s relationship with its users.
At the same time, Company X can also be a controller for other processing activities. For instance, Company X collects information on Customer Y employees who use the platform, such as admin names, emails, login timestamps, and usage analytics. This time, Company X is the one determining why it’s collecting data, setting retention periods, and establishing a lawful basis.
These practices can help you determine your role in processing activities more accurately:
- Assess only current processing activities: Review only the processing activities your organization is currently participating in, avoiding outdated assumptions or past arrangements
- Identify who determines the means and purpose of processing: The entity deciding why personal data is processed and how the processing is carried out is typically the controller
- Determine if another entity is processing data on your behalf: If your organization is processing personal data based on another organization’s instructions, you’re the processor
- Document roles and responsibilities in internal records: Record controller, processor, and subprocessor relationships in internal documentation to ensure responsibilities are clearly assigned
- Revisit roles if processing activities change: Changes to vendors, processing activities, data flows, and processing purposes might impact your role-based obligations and warrant a reassessment
Why misidentifying your role creates compliance risks
Getting your role wrong means applying the wrong GDPR requirements. You might assign responsibilities to the wrong party or miss safeguards you need, which increases regulatory risk and can lead to enforcement action.
Processors, for example, process personal data only on the controller’s documented instructions and don’t determine the purposes or lawful basis for that processing. The mistake happens when a processor treats customer data stored on its platform as its own and uses it for additional purposes, such as improving the product or training AI models. Under Article 28(10), a processor that determines its own purposes and means for that data may be treated as a controller for that processing, which can result in controller liability, in addition to potentially breaching its contractual obligations and the controller's documented instructions.
“As a processor, you don't get your own lawful basis. You act on the controller’s instructions, and that’s it. The mistake is treating customer data like it's yours, usually by claiming ‘legitimate interest’ as a lawful basis to improve the product or train a model.”
Evan Rowse
Misunderstanding your role can also lead to broader compliance issues, such as:
- Compliance gaps in vendor contracts
- Limited usefulness of RoPAs
- Delayed breach response
All of these become more pronounced as the vendor ecosystem expands and you navigate increasingly complex networks of processors, subprocessors, and other third parties. The best practice is to reassess existing contractual relationships, compliance processes, and data flows using a top GDPR compliance solution.
How Vanta helps you manage GDPR roles and responsibilities
Vanta is the #1 agentic trust platform that helps organizations manage their GDPR obligations across roles. The platform provides continuous compliance monitoring, automated gap identification with suggestions for remediation, risk management, and vendor and privacy modules that help operationalize your controller, processor, and subprocessor obligations in one system. It turns complex, role-specific tasks into actionable items your teams can follow.
Vanta’s GDPR software comes with dedicated features such as:
- Live data inventories
- RoPA management
- Automated evidence collection powered by 400+ integrations
- Pre-built policy templates
- Risk mitigation supported by risk management capabilities, including a risk register with risk scoring and treatment plans
- Vanta AI, which helps you draft and update policies
Vanta’s privacy module helps you manage your data privacy obligations more effectively. Use it to run data protection impact assessments (DPIAs) and RoPAs, maintain live records, and map requirements to other privacy frameworks.
Schedule a custom demo to see how Vanta helps you manage GDPR compliance.
{{cta_simple19="/cta-blocks"}} | GDPR product page
FAQs
Can a company be both a controller and a processor?
Yes, an organization can be both a controller and a processor at the same time, but not for the same processing activity. For example, a SaaS platform can be a processor when it handles personal data on behalf of another organization, but a controller when it collects user data for its own processing purposes.
Who is responsible for a data breach involving a subprocessor?
The processor is responsible to the controller for the subprocessor’s compliance with its GDPR obligations. The controller remains responsible for its own GDPR compliance and may be accountable to supervisory authorities and data subjects.
Does every vendor qualify as a subprocessor?
Under the GDPR, entities that process personal data on behalf of a processor qualify as subprocessors. Vendors that don't process personal data at all, such as hardware suppliers with no access to it, aren't processors or subprocessors, and so aren't subject to the requirements under GDPR Article 28. Whether a vendor qualifies depends on its actual access to and processing of personal data, not solely on the type of service it provides.
Vanta is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.
“
“
FEATURED VANTA RESOURCE
The ultimate guide to scaling your compliance program
Learn how to scale, manage, and optimize alongside your business goals.
.png)
.svg)
.svg)
