Data Processor
What is a Data Processor?
A Data Processor is any entity that processes personal data on behalf of a data controller, following the controller's documented instructions rather than determining the purposes and means of processing independently. Under GDPR and similar privacy regulations, the data processor acts as a service provider that handles, stores, analyzes, or transmits personal information according to contractual obligations defined in a Data Processing Agreement.
The processor-controller distinction is fundamental to privacy law because it determines legal responsibilities, liability exposure, and contractual requirements. Data processors do not decide what personal data to collect, why to collect it, or how long to retain it—those decisions belong to the data controller. Instead, processors provide technical infrastructure and services that enable controllers to execute their data strategies. For example, when a B2B SaaS company uses HubSpot to manage marketing campaigns, HubSpot acts as a data processor: the company (controller) decides which contacts to email and what content to send, while HubSpot (processor) provides the technical capability to deliver those emails following the company's instructions.
This role distinction carries significant implications for B2B SaaS vendors. Companies that misclassify themselves as processors when they're actually controllers face heightened regulatory scrutiny and potential GDPR fines. Conversely, vendors who clearly operate as processors must ensure they have proper Data Processing Agreements with customers, implement appropriate security measures, and support customer obligations around data subject rights and breach notification. According to research by the International Association of Privacy Professionals, 68% of GDPR enforcement actions involve questions of processor versus controller responsibilities, making accurate classification essential for compliance.
Key Takeaways
Follows Controller Instructions: Processors act only on documented instructions from controllers and cannot use personal data for their own purposes without becoming controllers themselves
Requires Data Processing Agreement: GDPR Article 28 mandates formal contracts between controllers and processors defining processing terms, security measures, and obligations
Limited Liability but Significant Obligations: Processors face direct GDPR liability for security failures, unauthorized processing, or failure to assist controllers with compliance obligations
Common in SaaS Ecosystems: Most B2B SaaS platforms act as processors for customer data, including CRM systems, marketing automation tools, analytics platforms, and infrastructure providers
Can Use Subprocessors: Processors may engage other processors (subprocessors) to assist with processing, subject to controller approval and appropriate contractual safeguards
How It Works
The data processor relationship operates through a defined contractual framework that translates regulatory requirements into operational practices.
Establishing the Processing Relationship: The relationship begins when a data controller (typically a business) engages a service provider to perform specific data processing activities. The controller maintains responsibility for determining what data to process, for what purposes, how long to retain it, and what security measures are required. The processor provides the technical infrastructure or service capability to execute those decisions. This relationship must be formalized through a data-processing-agreement that meets GDPR Article 28 requirements, including processing scope, security obligations, breach notification procedures, and subprocessor management.
Processing Personal Data Under Instructions: Once the DPA is executed, the processor handles personal data strictly according to controller instructions. For a marketing automation platform, this means sending emails only to contacts the controller uploads, tracking only the engagement metrics the controller configures, and storing data only in the regions the controller specifies. Processors cannot repurpose customer data for their own analytics, training machine learning models on customer data without permission, or sharing data with third parties beyond approved subprocessors. Any processing beyond documented instructions converts the processor into a controller with corresponding liability.
Implementing Security Measures: Processors must implement technical and organizational measures to ensure appropriate data security, considering the state of the art, implementation costs, and the nature, scope, and context of processing. This typically includes encryption at rest and in transit, access controls and authentication systems, regular security testing and vulnerability assessments, employee training on data protection, and logging and monitoring systems. Many B2B SaaS processors demonstrate these measures through SOC 2 Type II certifications or ISO 27001 compliance, which customers review during security diligence.
Managing Subprocessors: Most processors use other service providers to deliver their services—cloud infrastructure providers like AWS or Google Cloud, email delivery services like SendGrid, or analytics platforms like Segment. These subprocessors require careful management: processors must maintain current lists of all subprocessors, obtain controller approval before engaging new subprocessors (typically through advance notification with objection rights), and flow down the same data protection obligations to subprocessors through their own agreements. This creates chains of Data Processing Agreements throughout the SaaS ecosystem.
Supporting Controller Obligations: When data subjects exercise rights under GDPR (access requests, deletion requests, data portability requests), controllers must respond within regulatory timelines. Processors support these obligations by providing tools and processes for controllers to search, export, or delete personal data from the processor's systems. Similarly, when security incidents occur, processors must notify controllers rapidly (typically within 24-72 hours) so controllers can meet their own breach notification obligations to supervisory authorities and data subjects.
Data Return and Deletion: When the processing relationship ends (contract termination, service migration), processors must return all personal data to the controller or securely delete it according to the controller's instructions. Most B2B SaaS processors provide data export capabilities and certify deletion within 30-90 days after contract termination, though some enterprise agreements include longer retention periods for legal or dispute resolution purposes.
Key Features
Contractually Bound Processing: All processing activities must align with documented controller instructions in the Data Processing Agreement
Security Obligations: Processors implement and maintain technical and organizational security measures appropriate to the risk level
Transparency Requirements: Processors must disclose processing activities, subprocessors, data locations, and security measures to controllers
Breach Notification Duties: Processors must detect and report personal data breaches to controllers within defined timelines, typically 24-72 hours
Audit and Compliance Support: Processors enable controller audits through certifications (SOC 2, ISO 27001) or direct inspection rights
Use Cases
Use Case 1: Marketing Automation Platform as Processor
A B2B SaaS company uses HubSpot to manage marketing campaigns and lead nurturing. The company (controller) decides which contacts to include in campaigns, what email content to send, and when to move contacts between lifecycle stages. HubSpot (processor) provides the platform infrastructure to execute these campaigns, track engagement metrics, and store contact data. HubSpot processes personal data only according to the company's instructions: sending specified emails, tracking configured events, and storing data in controller-selected regions. The Data Processing Agreement defines HubSpot's obligations to encrypt data, notify the company of breaches within 72 hours, and support data subject access requests when customers exercise GDPR rights.
Use Case 2: Analytics Platform Processing Product Usage Data
A product analytics platform like Amplitude acts as a data processor for SaaS companies tracking user behavior. The SaaS company (controller) determines what events to track, what user properties to capture, and how long to retain analytics data. Amplitude (processor) receives event data through its SDK, processes it to generate reports and insights, and stores it according to the company's data residency requirements. When the company's customers submit data deletion requests under data-subject-rights, Amplitude provides APIs and interfaces enabling the controller to identify and delete specific user data from the analytics platform, supporting the controller's GDPR compliance obligations.
Use Case 3: Cloud Infrastructure Provider Chain
A B2B SaaS company builds its product on AWS infrastructure, using Snowflake for data warehousing and Segment for customer data collection. The company acts as controller for its end customers' personal data. AWS acts as processor for the SaaS company, providing compute, storage, and networking infrastructure. Snowflake acts as subprocessor (processor to AWS or direct processor to the company, depending on architecture), storing structured data in its multi-tenant environment. Segment acts as another processor, collecting and routing behavioral-signals to various destinations. Each relationship requires Data Processing Agreements, creating a chain where each party must flow down appropriate data protection obligations and maintain transparency about the processing chain to the ultimate controller.
Implementation Example
Understanding processor responsibilities is critical for both SaaS vendors providing services and companies using those services. Here's a practical framework for implementing processor obligations.
Processor Obligations Checklist for B2B SaaS Vendors
Obligation Category | Specific Requirements | Implementation Approach |
|---|---|---|
Legal Framework | Execute DPA with all customers, Include Standard Contractual Clauses for international transfers, Document processing instructions | Standardized DPA template, SCC exhibits, Processing documentation in DPA |
Security Measures | Encryption (data at rest and in transit), Access controls and authentication, Security testing and assessments, Employee training and background checks | SOC 2 Type II certification, Annual penetration testing, Security awareness training program |
Subprocessor Management | Maintain public subprocessor list, 30-day advance notice for new subprocessors, Execute DPAs with all subprocessors, Customer objection rights process | Public subprocessor page, Notification email system, Subprocessor DPA templates |
Breach Response | Incident detection and monitoring, Controller notification within 72 hours, Detailed breach documentation, Remediation action planning | Security information and event management (SIEM), Incident response playbook, Breach notification templates |
Data Subject Rights Support | Data access and portability tools, Deletion capabilities and workflows, Processing records for transparency, Controller support documentation | API endpoints for data access, Automated deletion workflows, Processing records register |
Data Lifecycle Management | Data return upon termination, Certified deletion within 90 days, No processing after termination, Destruction verification | Data export tools, Secure deletion procedures, Certificates of destruction |
Processing Activities Record (GDPR Article 30)
Data Processor vs Data Controller Decision Matrix
Question | Processor Answer | Controller Answer |
|---|---|---|
Who decides what personal data to collect? | The customer (controller) | Our organization |
Who determines the purposes of processing? | The customer defines purposes in the DPA | Our business needs and strategy |
Who decides how long to retain data? | Customer retention policies apply | Our retention schedule |
Can we use customer data for our own analytics? | No, unless explicitly permitted and disclosed | Yes, it's our data |
Do we market to customer contacts? | No, only the customer can send to their contacts | Yes, they're our marketing database |
Who responds to data subject access requests? | We support the customer's response | We respond directly to the data subject |
Common Processor Misclassification Scenarios
B2B SaaS vendors sometimes incorrectly claim processor status when they're actually controllers for certain processing activities:
Analytics on Customer Data: Vendor analyzes aggregate customer usage patterns to improve its product → This makes the vendor a controller for that purpose (requires disclosure in vendor's privacy policy)
Marketing to Trial Users: Vendor sends promotional emails to individuals who signed up for free trials → Vendor is controller for its own marketing activities
Training Machine Learning Models: Vendor uses customer data to train AI models for all customers → Without explicit permission, this makes the vendor a controller
Product Improvement Research: Vendor analyzes customer support tickets to identify product issues → Vendor acts as controller for this purpose unless covered in DPA
The key test: if the vendor determines the purpose and means of processing (even for a subset of activities), they're acting as a controller for those activities and need appropriate legal bases beyond the DPA.
Related Terms
Data Processing Agreement: The mandatory contract between controllers and processors defining processing terms and obligations
GDPR: The European regulation that defines processor obligations and requirements
Data Privacy: Broader framework encompassing processor-controller relationships and data protection principles
Data Subject Rights: Individual rights that processors must help controllers fulfill, including access, deletion, and portability
Privacy Compliance: Overall approach to meeting privacy obligations including proper processor classification
Data Warehouse: Infrastructure commonly provided by processors like Snowflake or BigQuery
Customer Data Platform: Technology that often acts as processor for customer signal collection and activation
Consent Management: System for capturing consent that works alongside processor obligations
Frequently Asked Questions
What is a data processor?
Quick Answer: A data processor is an entity that processes personal data on behalf of a data controller according to the controller's instructions, without independently determining the purposes or means of processing.
Data processors provide services that involve handling personal information—hosting data, sending communications, analyzing behavior, managing customer records—but do so as service providers following customer directions rather than for their own business purposes. Most B2B SaaS platforms operate as data processors for their customers' data while simultaneously acting as data controllers for their own employee, vendor, and business data. The distinction determines which GDPR obligations apply and what contractual requirements must be met.
What's the difference between a data processor and data controller?
Quick Answer: Data controllers determine why and how personal data is processed (purposes and means), while data processors handle personal data on behalf of controllers following the controller's documented instructions.
The controller makes strategic decisions about data collection, usage, and retention aligned with their business objectives. The processor provides technical capabilities to execute those decisions. For example, when a company uses Salesforce as their crm, the company (controller) decides which customer information to store, what fields to track, and what reports to generate. Salesforce (processor) provides the software infrastructure to store, process, and report on that data according to the company's configuration and instructions. Controllers have broader GDPR obligations including legal basis determination and privacy notice publication, while processors focus on security, confidentiality, and supporting controller compliance efforts.
Can a data processor also be a data controller?
Quick Answer: Yes, the same entity can be a processor for some processing activities and a controller for others, depending on who determines the purposes and means for each specific processing activity.
Most B2B SaaS companies act as processors for customer data (customer contacts in their CRM, customer analytics in their platform) while simultaneously acting as controllers for their own business operations (employee data, their own marketing database, their own financial records). The classification is activity-specific, not entity-specific. Additionally, in some complex scenarios, two entities can be "joint controllers" when they jointly determine purposes and means of processing. What's prohibited is a processor acting outside documented controller instructions—this converts them into an unauthorized controller with corresponding liability.
Do data processors need privacy policies?
Yes, data processors need privacy policies for processing activities where they act as controllers. While processors don't need privacy policies specifically for data they process on behalf of customers (the customer's privacy policy covers that), they do need policies for data they control: employee information, their own website visitors, free trial users they market to, or any data they collect for their own business purposes. Additionally, processor privacy policies should explain their role as a processor, reference their Data Processing Agreements with customers, and describe security measures they implement. This transparency helps customers understand the processor's data protection practices during vendor security reviews.
What happens if a data processor violates GDPR?
Data processors face direct liability under GDPR Article 82 for damages resulting from processing that violates GDPR or from failure to follow lawful controller instructions. Processors can be fined up to €10 million or 2% of global annual revenue (whichever is higher) for violations of processor-specific obligations, or up to €20 million or 4% for more serious violations like inadequate security measures. Controllers remain liable for choosing appropriate processors and monitoring their compliance, creating shared accountability. In practice, major GDPR enforcement actions against processors have focused on security failures (data breaches), unauthorized processing beyond controller instructions, and failure to maintain adequate data-processing-agreement contracts with customers.
Conclusion
Understanding the data processor role is fundamental for B2B SaaS vendors and the companies that use their services. As the SaaS ecosystem grows increasingly complex with organizations using 15-20 different tools in their gtm-tech-stack, each processing relationship requires careful classification, appropriate contractual documentation, and clear operational boundaries. Marketing teams using marketing automation platforms, sales teams working in CRM systems, and customer success teams leveraging analytics tools all create processor relationships that require Data Processing Agreements and ongoing compliance monitoring.
For SaaS vendors, correctly identifying when they act as processors versus controllers determines their legal obligations, contractual requirements, and liability exposure. Companies that clearly define their processor role, implement robust security measures, maintain transparent subprocessor lists, and provide strong customer support for data subject rights position themselves as trustworthy partners in an increasingly privacy-conscious market. According to Gartner, 89% of enterprise buyers consider vendor privacy practices in purchasing decisions, making processor compliance a competitive advantage rather than just a legal checkbox.
Organizations building their data infrastructure should maintain clear documentation of all processor relationships, regularly review Data Processing Agreements for alignment with current processing activities, and ensure processors provide adequate security measures and breach notification capabilities. Understanding the interplay between processors, data-processing-agreement requirements, and privacy-compliance obligations creates a foundation for responsible data-driven growth in B2B SaaS. For deeper understanding of compliance frameworks, explore related concepts around gdpr requirements and data-subject-rights fulfillment.
Last Updated: January 18, 2026
