Classifying a company as a controller or a processor under GDPR is not a paperwork exercise. It affects your privacy notice, your contracts, your security responsibilities, how you respond to access and deletion requests, and how you assess vendors. For SaaS teams, website owners, and technical operators, the difficult part is that one business can be a controller for some data and a processor for other data at the same time. This guide gives you a practical way to classify roles, compare common scenarios, and document your reasoning so your privacy compliance work stays usable as your tools, features, and vendor relationships change.
Overview
The simplest GDPR distinction is this: a controller decides why and how personal data will be used, while a processor handles personal data on behalf of a controller. That framing aligns with standard GDPR terminology and with how major vendors explain their role. For example, enterprise cloud providers often describe themselves as processors for customer data when the customer decides the purposes and means of processing and the provider follows the customer’s documented instructions under a data processing addendum.
In practice, however, most small and mid-sized organizations are not just one thing. A SaaS company may be a controller for its own employee data, billing records, sales leads, product analytics choices, and website visitor marketing data. The same company may also be a processor for customer-uploaded data inside its platform. A web agency may be a processor when hosting or maintaining a client site under the client’s instructions, but a controller for its own CRM, recruitment, and finance systems. A website owner is often a controller for site analytics, newsletter signups, and cookie choices, even when a separate platform runs the infrastructure.
That is why the better question is not “What is our company under GDPR?” but “For this specific processing activity, which role are we playing?” Role classification should be done per data flow, system, and purpose.
For operational compliance, that means building a habit of mapping:
- what personal data is involved,
- whose data it is,
- why it is being processed,
- who decides that purpose,
- who chooses the essential means, and
- who is acting under whose instructions.
If you can answer those six questions clearly, controller versus processor becomes much easier to defend in contracts, records of processing, vendor reviews, and internal security policy.
A useful caution: technology alone does not decide the role. Simply storing, transmitting, securing, or analyzing data does not automatically make a company a processor. If the company independently decides to use that same data for its own product improvement, behavioral profiling, advertising, or business intelligence beyond what the customer has instructed, it may be acting as a controller for at least part of that processing.
How to compare options
If you are trying to classify a relationship, compare the options using a short decision framework instead of relying on labels in marketing pages or contract headings. The safest evergreen approach is to look at substance over wording.
1. Start with the business purpose
Ask: who decided the reason the data is being processed?
- If your company decides to collect email addresses for a newsletter, you are acting as controller.
- If your customer uploads employee records into your HR tool and decides how the tool will be used for workforce administration, the customer is typically the controller for that customer data.
- If your platform processes that customer data only to provide the service under the customer’s instructions, your platform is typically acting as processor for that activity.
The party that sets the purpose usually carries controller responsibilities for that activity.
2. Separate essential means from technical means
A processor can make technical or operational decisions without becoming a controller. A hosting provider can choose server architecture, logging methods, redundancy design, and security tooling. Those are usually service-delivery choices. But if the provider decides to repurpose customer data for its own unrelated analytics, advertising, or data brokerage, that points toward controller behavior for that separate use.
For SMBs and SaaS teams, this is one of the most common mistakes: assuming that because a vendor controls the technical stack, it must also control the data purpose. Usually it does not. Technical discretion is not the same as deciding why personal data is used.
3. Check for documented instructions
Processors act on behalf of controllers. A strong sign of processor status is that the service is governed by documented instructions in the contract or DPA. The source material provided reflects this model: a processor handles customer data to provide services according to the customer’s instructions and the relevant contractual terms.
Operationally, review whether your agreement covers:
- subject matter and duration of processing,
- types of personal data,
- categories of data subjects,
- purpose of processing,
- security obligations,
- subprocessor use,
- assistance with data subject requests, and
- return or deletion of data at the end of the service.
If those elements are missing, role confusion usually follows.
4. Identify whether the provider uses the data for its own ends
This is often the decisive comparison point. Ask:
- Does the provider use customer data solely to deliver the service?
- Or does it also use the data to improve unrelated models, build marketing profiles, conduct independent research, or enrich other datasets?
Independent use does not always make the entire provider relationship controller-based, but it may create separate controller processing layered on top of processor services. That split should be reflected in the privacy notice, DPA language, and risk assessment.
5. Classify by processing activity, not by vendor category
A CRM vendor, analytics tool, payment processor, cloud host, email platform, or support desk system can sit in different roles depending on the facts. Do not assume that all SaaS vendors are processors. Do not assume that all website owners are controllers for everything. Review each data flow separately.
This activity-based method also makes your records of processing more accurate and makes later vendor risk assessment easier.
Feature-by-feature breakdown
Below is a practical breakdown of the main features that distinguish controller and processor roles in day-to-day compliance work.
Who defines the purpose
Controller: Defines the business objective. Examples include running payroll, sending product updates, measuring campaign performance, screening job applicants, or operating a customer portal.
Processor: Carries out processing so the controller can meet that objective.
Operational takeaway: In your data map, assign ownership of the purpose first. If that is unclear, the rest of the analysis will be weak.
Who chooses the rules of use
Controller: Decides what data should be collected, which users should be targeted, how long data should be retained in principle, and what lawful basis or notice framework applies.
Processor: Applies the controller’s instructions and implements service-level controls to support them.
Operational takeaway: Product requirements, privacy settings, and retention defaults often reveal who is acting as controller.
Who has direct responsibilities to data subjects
Controller: Usually owns the main obligation to provide privacy information and honor rights requests such as access, deletion, or objection, unless a processor contractually helps fulfill them.
Processor: Must support the controller where required by contract and law, but does not usually replace the controller’s primary accountability.
Operational takeaway: If you receive a user request and you are a processor for the relevant data, you should have a workflow to route the request to the controller unless the contract says otherwise.
Who signs the DPA and vendor terms
Controller: Engages processors and should perform due diligence on their security and privacy posture.
Processor: Accepts instructions, security commitments, audit or evidence obligations, and subprocessors terms.
Operational takeaway: Your vendor intake process should include a role classification field before procurement finishes. This prevents mismatched contract templates.
Who handles security decisions
Controller: Remains responsible for choosing vendors and assessing whether the processing setup is appropriate for the risk.
Processor: Must implement suitable technical and organizational measures for the processing it performs on behalf of the controller.
The source material supports this shared structure: processors deliver services under instructions, while controllers remain responsible for risk assessment and broader accountability decisions.
Operational takeaway: Security ownership is shared, not transferred. A controller cannot outsource accountability merely by using a reputable cloud platform.
Who appears in the privacy notice
Controller: Should be identified in the notice for the processing activities it determines.
Processor: May be named as a category of recipient or service provider, depending on the context and disclosure model.
Operational takeaway: Review your notice against your actual data map. If your site uses analytics, forms, payments, chat tools, and embedded media, you are almost certainly acting as controller for at least some website data. For a practical companion, see Privacy Policy Checklist for Websites and SaaS: What to Disclose and When to Update It.
Common examples
SaaS product handling customer records: Usually processor for customer content inside the service; controller for account administration, billing, security logs tied to its own business operations, and product marketing.
Website owner using analytics and contact forms: Usually controller for visitor data collection on the site, even if tools from third parties process the information.
Managed hosting provider: Often processor for hosted customer data when acting only under customer instructions; may be controller for its own service telemetry, billing, fraud prevention, and support administration.
Email delivery platform: Often processor when sending transactional mail on behalf of a customer; may be controller for its own service abuse monitoring, account management, or independently determined analytics.
Agency building and maintaining a client website: Often processor for client customer data accessed during support or administration; controller for the agency’s own prospecting, contracts, HR, and finance data.
These examples are useful, but they should not replace a documented review of the exact service terms and actual data uses.
Best fit by scenario
This section turns the framework into concrete classifications that technical teams can reuse.
Scenario 1: A small SaaS platform serving business customers
You host a project management tool. Customers create accounts for their employees and upload files, comments, and task data.
- Customer workspace data: Your customer is typically the controller; you are typically the processor.
- Your own billing and subscription records: You are the controller.
- Security logs needed to protect the service: Often your company is acting as controller for some of this operational data, especially where you determine the security purpose for your own service environment.
- Marketing emails to trial users: You are the controller.
Best fit: Dual role model. Most SaaS businesses should maintain separate documentation for customer data processing and for internally determined business processing.
Scenario 2: A brochure website with forms, cookies, and analytics
You run a company website with a contact form, newsletter signup, analytics tags, and a chat widget.
- Form submissions and newsletter signups: You are typically the controller.
- Analytics provider or chat vendor: Often processor or separate controller depending on the service design and terms.
Best fit: Treat the website owner as controller first, then examine each tool for whether it acts only on instructions or uses data for its own purposes. This is where cookie consent requirements, vendor terms, and your privacy notice need to align.
If you need a broader operational checklist, see GDPR Compliance Checklist for Small Businesses: Website, App, and Customer Data Requirements.
Scenario 3: A developer or IT team choosing cloud infrastructure
You deploy customer-facing workloads to a major cloud provider.
- Your organization: Usually controller for the personal data in your application.
- Cloud provider: Often processor for customer data processed to provide the contracted service, consistent with the provider’s DPA and your instructions.
- Provider’s own account, billing, and operational logging: The provider may be controller for those separate activities.
Best fit: Split the relationship into service-delivery processing versus provider-owned operational processing. Do not collapse everything into one label.
Scenario 4: An agency administering a client’s CMS and mailing list
You access the client’s website backend, customer database, and mailing platform only to maintain the site and publish campaigns the client approves.
- Client customer data: Client is usually controller; agency is usually processor.
- Agency account management, invoicing, and staff data: Agency is controller.
Best fit: Processor role for client data should be expressly covered in a DPA, with security, confidentiality, and access control terms. Limit use of the data to the client’s documented instructions.
Scenario 5: A vendor that wants broad rights to service data
A tool provider’s terms say it may use uploaded data to improve models, analyze market trends, or share insights across customers.
Best fit: High caution. This may indicate that the provider is not acting purely as a processor for all uses. You need to identify which data uses are on your instructions and which are independently determined by the vendor. That affects notice language, transfer of risk, and whether the tool fits your data protection compliance requirements at all.
When to revisit
Role classification is not a one-time legal memo. It should be revisited whenever the underlying processing changes. This is especially important for SMBs and SaaS teams because products, integrations, and vendor terms evolve quickly.
Review your controller versus processor analysis when:
- you launch a new feature that changes why data is used,
- you add analytics, AI, fraud detection, or tracking functions,
- you onboard a new vendor or subprocessor,
- vendor terms, DPAs, or privacy policies change,
- you expand into a new customer segment or geography,
- you begin using customer data for training, benchmarking, or product improvement,
- your sales team promises different handling terms to enterprise customers, or
- you receive customer or auditor questions that reveal ambiguity in your current model.
A practical action plan for staying current:
- Maintain a processing inventory. List each system, the data categories involved, the purpose, and the role played by each party.
- Add a role check to procurement and product review. Before a tool goes live or a feature ships, ask whether it changes controller or processor status for any data flow.
- Align the documents. Your privacy notice, DPA, records of processing, security policy, and incident response contacts should all reflect the same role logic.
- Train operational teams. Support, engineering, and vendor management staff should know when to escalate a role question instead of guessing.
- Keep evidence. Save the contract version, DPA, privacy terms, and your classification notes. This makes customer due diligence and audit responses much easier.
If you want one evergreen rule to keep, it is this: classify the role based on who decides the purpose and essential means for each processing activity, then document the answer where your technical, legal, and vendor teams can actually use it.
That approach is more durable than relying on slogans, and it scales better as your stack grows. It also gives you a repeatable way to assess new SaaS tools, website plugins, cloud services, and data-sharing arrangements without starting from scratch every time.
