A SaaS company can use dozens of vendors before its product team considers whether each one is a controller, processor, or both. That delay creates avoidable exposure. Controller versus processor obligations determine who makes decisions about personal data, who must document those decisions, and what contractual and technical controls must be in place before data enters a platform, cloud environment, or AI workflow.
For technology businesses, this is not a labeling exercise. A role assessment affects product design, procurement, incident response, international transfers, data subject rights handling, and customer negotiations. The GDPR looks at the facts of processing, not what a contract happens to call the parties.
The distinction starts with decision-making
Under the GDPR, a controller determines the purposes and means of processing personal data. In practical terms, the controller decides why personal data is used and makes the essential decisions about how that use will occur. A health-tech provider that determines what patient information to collect for its care coordination service, how long to retain it, and which users can access it is acting as a controller for that processing.
A processor processes personal data on the controller’s documented instructions. A cloud hosting provider, managed support desk, payroll platform, or analytics provider may be a processor where it handles customer data solely to deliver a defined service and does not decide the purposes of use.
The distinction becomes harder in modern technology stacks because providers often use data for several purposes. A vendor may process customer content to provide its contracted service, then use account contacts for its own billing, security logs for its own fraud prevention, and aggregated telemetry to improve its platform. Those activities may involve different roles. One data flow can support a processor relationship, while another makes the same vendor an independent controller.
A company cannot become a processor simply by promising not to use data broadly. If it independently decides to reuse personal data for product development, advertising, profiling, or its own commercial purposes, it may be acting beyond processor instructions and as a controller for that use.
Controller versus processor obligations in practice
Controllers carry the primary responsibility for lawful processing. They must establish an appropriate legal basis, provide transparent privacy information, honor applicable data subject rights, apply data minimization and retention controls, and demonstrate accountability. Article 5(2) is particularly significant: the controller must not only comply with the data protection principles but also be able to show that it complies.
For a technology company, this means privacy governance has to reach operational decisions. Product requirements should identify the data involved, intended purposes, recipients, retention periods, and lawful basis. Security and engineering teams need controls that reflect those decisions. Procurement must ensure vendors can meet the company’s instructions and security requirements. A privacy notice cannot repair a data architecture that collects more information than the product actually needs.
Processors have narrower, but still substantial, direct obligations. They must process data only on documented instructions, maintain appropriate security measures, keep records of processing where required, assist the controller with data subject rights and security obligations, notify the controller of personal data breaches without undue delay, and meet restrictions on engaging subprocessors.
The required controller-processor contract under Article 28 is therefore operational, not ceremonial. It should specify the subject matter and duration of processing, its nature and purpose, the categories of data and individuals involved, and the controller’s rights and obligations. It must also set out instructions, confidentiality commitments, security expectations, assistance duties, deletion or return requirements, audit provisions, and conditions for subprocessors.
A generic data processing addendum can be adequate for a low-risk service with simple processing. It is rarely enough for an AI provider processing sensitive data, a fintech platform sharing data across entities, or a cloud deployment involving multiple regions and support teams. The contract needs to match the actual architecture.
Accountability remains with the controller
A controller may outsource processing activities, but it cannot outsource accountability. Selecting a well-known cloud provider does not remove the need to assess whether the proposed service, configurations, transfers, and contractual terms support GDPR compliance.
Controllers should be able to explain why each processor is necessary, what instructions it receives, what data it accesses, where that data is processed, and how performance is monitored. This is particularly relevant where a vendor has broad administrative access, uses a chain of subprocessors, or supports a business function involving special category data, financial data, employee information, or children’s data.
Controllers also lead on data protection impact assessments when processing is likely to create a high risk to individuals. The processor must assist by providing relevant information about its systems, security measures, subprocessors, and processing operations. In practice, a DPIA often exposes gaps that standard vendor onboarding misses: unclear data flows, indefinite retention, insufficient access segmentation, or a lack of meaningful deletion capability.
Where two organizations jointly determine purposes and essential means, they may be joint controllers. This is common in some marketing partnerships, shared platforms, and integrated financial services. A joint controller arrangement requires a transparent allocation of responsibilities, but each party must still consider its own legal exposure. Calling the arrangement a processor relationship will not change the underlying reality.
Processors need independent governance too
Processors should not treat GDPR compliance as a contract administration task performed only when a customer asks for a data processing agreement. A mature processor needs its own repeatable privacy and security operating model.
That model should include an instruction management process, role-based access controls, security incident procedures, subprocessor due diligence, records of processing, staff confidentiality obligations, and a tested approach for returning or deleting data at the end of service. It should also define escalation paths when a customer instruction appears unlawful, technically impossible, or inconsistent with agreed security measures.
For SaaS and AI vendors, the most common pressure point is product improvement. If customer data will be used to train, evaluate, debug, or improve a general model or service, the organization should assess that activity separately. The key questions are whether the use is necessary to provide the customer service, whether the vendor determines a new purpose, whether personal data can be excluded or meaningfully de-identified, and what contractual and transparency measures are needed.
Security is another area where both roles have meaningful duties. Controllers must select processors offering sufficient guarantees and implement appropriate measures for their own systems. Processors must implement technical and organizational measures appropriate to the risk. The allocation of responsibility may differ, but neither party can rely on the other to solve a poorly configured identity environment, excessive permissions, weak encryption practices, or an untested incident response plan.
Build the role analysis into commercial workflows
The most reliable approach is to assess roles before contracts and integrations are finalized. Legal, product, security, procurement, and engineering should work from the same processing map rather than producing separate descriptions of the service.
Start by identifying the specific data flows. Ask who collects the data, who decides the business purpose, who determines retention, who can access it, whether the provider may reuse it, and which entities or subprocessors receive it. Then document the conclusion for each processing activity, not simply for each vendor.
Next, translate the conclusion into controls. A controller relationship may require privacy notice updates, a lawful basis assessment, rights-handling workflows, transfer safeguards, and a DPIA. A processor relationship requires precise instructions, an Article 28 agreement, security assurance, and subprocessor governance. If the relationship is mixed, separate the activities clearly in the contract and in operational documentation.
Finally, revisit the analysis when the product changes. New AI features, expanded analytics, a new hosting region, customer support access, or a merger can alter the role assessment. Privacy teams should receive enough visibility into these changes to assess them before data use becomes embedded in production.
For organizations operating in complex technical environments, the value is not merely having the right labels. It is creating a defensible model in which contracts, product behavior, security controls, and governance all tell the same story. That alignment gives teams greater confidence when customers, regulators, and investors ask the questions that matter most: who controls the data, why is it being used, and can the organization prove it is being handled responsibly?