GDPR controller or processor: how to decide your role

Am I a GDPR controller or processor for each activity?

Your role under the GDPR is set for each processing activity, not for the company as a whole. Under Article 4, a controller is the body that determines the purposes and means of processing, and a processor is the one that processes personal data on the controller's behalf. The same company can be a controller for its own marketing list and a processor for a customer's user records, so the question to answer is: for this activity, who decided why the data is processed and how it is handled? Customers who ask for a processor agreement are usually asking that question in a contractual form, and they are entitled to a clear answer before they sign anything. The organization owns this determination. No auditor, assessor or certification body issues a ruling on your role, and the GDPR does not require one. Your legal and privacy team should record the reasoning for each activity, based on who sets the purpose (for example, why the records are kept and for whom) and who sets the means (for example, which systems, storage locations, security settings and sub-processors are chosen). An implementation partner can help document the technical facts behind that reasoning, but it cannot make the role decision on your behalf. Confirm with your data protection lead which person signs off on each determination and how often it is reviewed. The answer differs by business model. A SaaS vendor that offers a platform and lets customers decide what data to load and who may see it is usually a processor for that customer content, but it is a controller for its own account, billing and usage analytics. A hosting provider that runs infrastructure without looking at the contents is normally a processor, yet it may become a controller if it reuses customer data for its own purposes. A company that uses a vendor is the controller of its own data and should check whether the vendor is acting only on its instructions. If your vendor starts deciding new purposes, the Article 28(10) rule treats it as a controller for that processing, so re-check the role whenever product features or data uses change.

How to work out your role in five steps

This sequence turns a vague sense of "we are the vendor" or "we are the controller" into a dated, reasoned record for each processing activity, so the role your contracts state matches what your systems actually do.

Inventory each processing activity
List every activity in which your organization or product touches personal data, such as account sign-up, support ticketing, analytics, backups, and hosting for customers. Work at the level of a purpose, not a system, because one platform can serve several activities with different roles. Assign an owner from product or operations to each line. The output is a register with one row per activity, a plain description of the data involved, and the people who can answer questions about it.
Identify who decides the purposes
For each activity, ask who decides why the personal data is processed and what outcome the processing is meant to achieve. Look at who set the goal, who benefits, and whether the other party could refuse the processing and still get the service. Record the answer and the evidence behind it, such as a product specification, a customer instruction, or a internal decision memo. The output is a named purpose-holder per activity, with the reasoning written down.
Identify who decides the means
Next, determine who decides the essential means of processing: which data is collected, which system holds it, how long it is kept, who can access it, and which third parties receive it. Non-essential technical choices, such as the choice of a database engine, can be left to a processor. Check your product configuration and your standard contract terms to see whether the customer or your company sets these details. The output is a note for each activity that separates essential decisions from operational ones.
Test the result against the EDPB examples
Compare each provisional role with the examples in the EDPB's guidance for small businesses and its Guidelines 07/2020 on controllers and processors. A bookkeeping firm keeping a client's books, or a payroll company acting solely on an employer's behalf, shows the processor pattern. Where your activity sits between these patterns, flag it for legal review. Do not rely on the contract label alone. The output is a confirmed role or a flagged case, with the matching example noted.
Check for joint control and processor drift
Look for activities where two parties together determine purposes and means, which points to joint controllers that need a transparent arrangement covering data subject rights and information duties. Also check whether a processor has begun setting its own purposes, such as reusing customer data to train its own products. Under Article 28(10), a processor that does this is treated as a controller for that processing. The output is either a documented joint control arrangement or a list of processing activities where drift must be stopped or the role changed.
Record the decision and its reasoning
Write a short decision record for each activity covering the role held, the reasons, the examples relied on, the date, and the approver. Link the record to the matching processing agreement, joint control arrangement, or record of processing so auditors and customers can follow the chain. Schedule a review when a product change alters purposes or means. Ask your counsel to confirm the approach where the facts are unusual. The output is a role decision file that a compliance lead can produce on request.

Why the contract label does not decide your role

A contract that calls one party a processor does not make it one. Under the GDPR, the role follows from who actually determines the purposes and means of the processing, and Article 28(10) is explicit about the consequence: a processor that infringes the Regulation by determining purposes and means is treated as a controller for that processing. A vendor that writes its own retention rules, decides which customer records to use for product analytics, or chooses to share data with a partner for its own benefit can be a controller for those activities even when the customer agreement says otherwise. Before signing or accepting a processing agreement, list each activity you perform on customer data and ask who set its purpose and who chose the technical means. Those answers, not the heading in the contract, are what a supervisory authority will test.

EDPB Guidelines 07/2020 also shape what a processing agreement must contain to be useful. The guidelines say the agreement should not simply restate the GDPR's obligations. It should specify how each requirement will be met and the level of security required. A clause that says the processor will keep data secure adds little; a clause that names the encryption standard, access review frequency, breach notice window and the personnel who may administer the system shows the controller what it is relying on. Confirm with your counsel which details your contracts already specify and which are generic, because a generic agreement can be read as evidence that the parties never worked out who decides what.

Regulators look at decision-making because the contract is written by the party with the stronger position, often the controller's procurement team or the vendor's legal team, and it may not reflect daily practice. Ask who writes the operational instructions. If the controller sends documented instructions for each processing purpose and the processor works within them, the processor role is credible. If the processor designs the feature, picks the purpose and tells customers afterwards, the agreement will not protect it. Keep a short record of who approved each processing purpose and each significant change to it, so that you can show the decision trail if a customer, auditor or regulator asks.

What the EDPB's processor examples show

The EDPB's small business guide gives three examples of processors. Each is illustrative and drawn from EDPB guidance, not a determination for any organization. Read them together: in each, the service provider works within the client's purposes and follows its instructions.

Bookkeeping service keeping the books

In the EDPB example, a bookkeeping service keeps an SME's books, and the SME decides why the financial records exist and what they are used for. The provider decides how to run the ledger tools and store the records, which is a means question it can answer without changing the purpose. Check whether your own bookkeeping-style tasks stay inside the client's purpose, and whether you ever reuse client records for your own product analytics or benchmarking, which would move you toward controller status.

Payroll company processing staff data

In the EDPB example, a payroll company processes staff data solely on behalf of the SME, so the employer sets the purpose of paying staff and the payroll company carries out that processing. The role holds because the provider does not use the employee data for its own ends. Check whether your payroll or HR-adjacent service ever uses client employee records to build products, train models or sell aggregated insights, since that use would be a purpose the client did not set.

Marketing company collecting email addresses

In the EDPB example, a marketing company collects email addresses on the SME's explicit instructions and for the SME's exclusive purposes. The processor role depends on both conditions: the instructions are explicit, and the data serves only the client's campaign. Check whether your campaign or lead tools retain addresses for your own lists, enrich them with third-party data, or reuse them across customers, because any of these would make you a controller for that activity.

Explicit instructions and exclusive purpose

Across the three examples, the processor role holds on two conditions: the client sets the purposes, and the processor acts only on documented instructions. Article 28(3) requires the processing agreement to set out these instructions. Check that your contract and your actual system configuration describe the same processing, and record who decided each new use of the data.

When a processor decides purposes

Under Article 28(10), a processor that infringes the GDPR by determining the purposes and means of processing is treated as a controller for that processing. Article 28(3) also requires the processor to tell the controller immediately if it believes an instruction infringes the GDPR. Check whether your team has a process to escalate doubtful instructions, and whether any feature changes quietly widen what you do with customer data.

Which role outcome fits each processing activity

This table compares the four outcomes you can reach for a processing activity: sole controller, processor on instructions, joint controllers, and a processor that has become a controller. Read each row against the activity in question, starting with who actually sets the purposes and means, then check the written arrangement the outcome requires.

Role outcome	When it fits	Written arrangement required	First question to ask
Sole controller	One organization decides why and how the personal data is processed	Own controller duties, with processor contracts for any vendors it uses under Article 28	Who decides the purpose, and who decides the means?
Processor on instructions	The customer sets purposes and key means, and you process only on its documented instructions	Article 28 contract covering instructions, security, sub-processors, breach notice and audit support	Did we decide anything about the purpose that the customer did not instruct?
Joint controllers	Two or more organizations jointly determine purposes and means of the same processing	Transparent arrangement under Article 26(1) allocating rights requests and information duties	Who answers data subjects, and is the split written and shared?
Processor that became a controller	A processor determines purposes or means in breach of the GDPR for that processing	It is treated as a controller for that processing under Article 28(10), so controller duties apply	Have we used customer data for our own product, analytics or training purposes?

What changes when a processor starts deciding purposes

A processor that determines the purposes and means of an activity is treated as a controller for that activity. Article 28(10) makes this shift automatic: the processor does not need a regulator to rule on it. The consequence is that the processor takes on controller duties for that processing, including a lawful basis, transparency to the data subjects, and the handling of their rights. If your organization is the processor on a contract but also decides why certain data is used, plan for that status change in writing before the activity goes live rather than discovering it during an audit.

Two further consequences follow from the processor's own position. Under Article 82(2), a processor is liable for damage only where it breached obligations aimed at processors or acted outside or contrary to the controller's lawful instructions, so every instruction you follow is also a liability question. Under Article 28(3), the processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other data protection rules. Build that check into your intake process for new customer requirements, and record each notice you send. Article 83 sets the fine ceilings that apply to either role: up to EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, and up to EUR 20 million or 4% for infringements of the principles, lawful basis, data subject rights and transfer rules, whichever is higher.

The change applies activity by activity, not to the company as a whole. A SaaS vendor may be a clean processor for its customers' records while deciding its own purposes for product analytics, security telemetry or model improvement. Map each processing activity separately, note who sets its purposes, and document the result. Confirm with your counsel or data protection lead which activities fall into the controller category, and check whether the processing agreement and your privacy notice reflect that split.

Who owns the role decision and who prepares the evidence

Your legal, privacy and product teams make the controller or processor determination for each processing activity and sign it off. The GDPR defines the roles by what an organization actually does, so the decision rests on facts about purposes and means, not on the label a contract uses. The people who build features and set data flows know those facts best, so product and engineering leads should be part of the review rather than receiving the outcome afterwards.

Named sign-off: record which person approves each activity's role, with a date and the facts relied on.
Activity-level records: decide the role for each processing activity, since one company can be a controller for its own staff data and a processor for customer data.
Change triggers: re-review when a new feature, analytics use or sub-processor changes who sets purposes or means.
Processor drift check: test whether any processing you run for a customer is now serving your own purposes, which would make you a controller for that processing under Article 28(10).
Documented reasoning: keep the written analysis that explains why each role fits.

Check that every processing activity in your inventory has a named owner and a recorded role decision.

Mistakes that flip or blur the role

Most role errors come from treating a label as the answer or from never revisiting the analysis after the service changes. The cards below cover the mistakes that most often flip a processor into a controller or leave joint controllers without a workable arrangement, with the check that prevents each one.

Relying on the contract label

A processing agreement that calls the vendor a processor does not settle the question. Role follows from who actually determines the purposes and means of each activity, and an assessor will read the product behavior and the vendor's decisions before the wording. Avoid this by mapping each processing activity, naming who chose its purpose and its key design choices, and then checking the contract matches that finding. Where it does not, correct one or the other.

Reusing customer data for product improvement

A vendor that uses customer records to train models, build analytics or improve its own product is often determining its own purposes for that data, which can make it a controller for that use. Under Article 28(10), a processor that infringes the GDPR by setting purposes is treated as a controller for that processing. Avoid this by listing every secondary use of customer data, deciding whether each is an instruction from the customer, and either removing the use or documenting a separate controller basis and notice.

Leaving joint controllers without an arrangement

When two organizations jointly decide purposes and means, Article 26(1) requires them to set their respective responsibilities in a transparent arrangement, including who answers data subject rights and information duties. Many teams assume each party will handle its own side, which leaves individuals and regulators without a clear point of contact. Avoid this by drafting a binding joint-controller document covering principles, legal basis, security, breach notice, DPIAs, transfers and contacts with authorities, and publishing the essence of it to data subjects where required.

Ignoring role changes from new features

A new feature, integration or sub-processor can shift who decides purposes or means without anyone updating the role analysis. A recommendation engine, a new analytics tool or a partner that receives data for its own use can each change the picture. Avoid this by requiring a role check as part of every release that adds a processing purpose, data category or recipient, and recording the outcome in the processing records.

Accepting instructions that breach the GDPR

A processor that follows an instruction it believes infringes the GDPR can end up sharing responsibility for the outcome. Article 28(3) requires the processor to inform the controller immediately when it considers an instruction infringes the regulation or other data protection provisions. Avoid this by setting a written escalation path for doubtful instructions, logging each instruction received, and treating an unlawful instruction as a reason to pause and raise the issue rather than to comply silently.

Assuming processor status shields from liability

Article 82(2) makes a processor liable where it breached obligations aimed at processors or acted outside or contrary to lawful controller instructions. Teams that treat the processor role as a low-exposure position often skip the processor-specific controls, such as documented instructions and sub-processor oversight. Avoid this by confirming that each processor duty in the agreement has a named owner, an operating procedure and retained evidence, and reviewing those duties when the service scope changes.

Questions buyers ask about GDPR roles

Can we decide our GDPR role in-house without outside help?

Yes, in most cases, if someone with authority over the processing can answer a few factual questions for each activity. The test is who determines the purposes and the means of processing, and the EDPB's guidance treats that as a question of facts, not a label in a contract. Legal and product staff can work through it using the EDPB's examples, such as a bookkeeping service or payroll company acting only on a client's instructions. Outside help makes sense when activities are complex, when a customer disputes your role, or when you lack anyone who can read the EDPB guidelines with confidence. Independent advisers can prepare the analysis, but the organization must own the conclusion and the resulting contracts.

What drives the cost of working out our GDPR roles?

The main cost driver is the number of processing activities and how many of them involve decisions about purposes or means. Each activity needs its own analysis, so a product with dozens of features and integrations takes more effort than a single service. Other drivers include the number of sub-processors, how many customer contracts use different terms, and whether the analysis must be revisited after each product change. Internal staff time is the largest recurring cost. External fees are one-time for the initial mapping and recur only if you buy periodic reviews. Ask any adviser for a written scope that lists activities, systems, contracts and deliverables, because a quote follows from that scope.

How long does the role analysis take for a product with many activities?

The duration depends mainly on how many processing activities you run and how well documented your systems are. A product with a few well-defined activities and existing data flow diagrams can be analyzed far faster than one with many integrations, custom features and undocumented data flows. Start with an inventory of activities, then analyze each one, then review the draft arrangements with legal. No researched figure in this guide sets a fixed duration, so ask any adviser to commit to a timeline in the written scope, with milestones tied to the number of activities you confirm. Build in time for customer review, since disagreements about roles often extend the schedule.

What do engineering and legal teams need to provide?

Engineering supplies the facts that decide the role: what data each feature collects, where it is stored, which sub-processors receive it, who configures processing, and whether any feature lets your company choose new uses of customer data. Legal supplies the contracts, customer terms, privacy notices and any instructions customers have given in writing. Both teams should confirm the current state, because the analysis is only as accurate as the data flow description. Expect to walk through each activity together, since engineers often know about automated decisions or analytics reuse that legal staff have not seen. Keep the output as a versioned record so changes in product behavior can trigger a fresh review.

Can one product have different GDPR roles for different activities?

Yes. The role is assessed for each processing activity, not for the company or the product as a whole. A SaaS provider may act as a processor when it hosts customer records on the customer's instructions, but act as a controller for its own billing data, account administration or product analytics where it sets the purposes. Under Article 28(10), a processor that determines purposes and means for an activity is treated as a controller for that activity, so one wrong decision can change the role for part of the service. Document each activity separately, and make sure customer contracts describe only the activities where you act as processor.

What should we do if a customer disagrees with our role?

Start by checking the facts, because the role follows from how processing actually happens, not from what either party wrote. Compare the customer's view with your activity analysis and identify which decisions about purposes or means they believe you make. If your product makes an independent decision, such as reusing customer data to train your own models, the customer may be right, and you should either change the processing or accept controller duties for that part. If the disagreement is about who holds an instruction, Article 28(3) requires a processor to tell the controller immediately when it believes an instruction infringes the GDPR. Record the dispute, the facts reviewed and the outcome. Independent counsel can help with the reasoning, but a supervisory authority decides only if the question reaches it.

Does a processor's wrong role change its liability?

Yes. Under Article 82(2), a processor is liable for damage only where it breached obligations aimed at processors or acted outside or contrary to the controller's lawful instructions. If you decide purposes or means without authority, you take on controller responsibility for that processing, and your exposure to claims and fines can rise accordingly. Fines under Article 83 depend on the infringement, so check the category that applies to the specific breach. Treat the role analysis as a risk control: it tells you which obligations apply and which instructions you must follow.

How DeployOpen works on this

DeployOpen helps teams map who decides purposes and means for each processing activity, then turns that mapping into contracts, records and system evidence. We work inside your own infrastructure, and the role decision and any legal conclusions remain yours, with your counsel and, where relevant, your supervisory authority.

How we scope

We agree a written scope listing the processing activities, systems and customer relationships to be mapped before work starts.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any role analysis begins.
Ongoing support for role changes, new products or new customer terms is available as a retainer, priced from the written scope.

How we build

We inventory each processing activity, recording who sets purposes, who sets means, and where instructions originate.
We configure the self-hosted platforms and access controls so that processing matches the role documented for each activity.
We flag activities where a processor's own decisions could make it a controller, so the team can review them before launch.

How we hand over

We deliver a role register per activity, with the reasoning, the supporting facts and the open questions for your counsel.
We prepare draft arrangements for joint controllers or processor terms, for your legal team to review and sign.
We document the technical configuration behind each role so an independent assessor can test the claims against real systems.

How we support

We review role decisions when products, sub-processors or customer instructions change, and record each revision.
We support customer audit requests and evidence reviews, while your organization answers for its own compliance position.
DeployOpen prepares systems and evidence only. Reports and certifications come from independent auditors or certification bodies.

Controller or processor: how to determine your GDPR role