This is the monthly edition of “Ask the DPO”. Our Head of DPO Services, Guy Bakshi, looks at frequent questions that the DPO is asked. This time, we examine an area service providers tend to struggle with – sub-processor mapping and list management.
Every company relies on vendors that process personal data in different ways. Some support core product or service functions, some store data, and others access sensitive systems. Vendors that process customer data on a company’s behalf in delivering its services are sub-processors. Managing them properly is essential to meeting contractual and privacy obligations and maintaining customer trust.
The basics: what are sub-processors?
Modern privacy laws generally distinguish between controllers and processors. Although terminology varies by jurisdiction – for example, “business” and “service provider” in California, or “database controller” and “database holder” in Israel – the underlying concepts are similar. This article uses the terms “controller” and “processor.”
A controller determines why and how personal data is processed. In practical terms, it is the entity responsible for the data and for decisions about its use, sharing, retention, processing purposes, etc. For example, a company is generally the controller of its employees’ personal data. Controllers often engage vendors to process personal data on their behalf. These vendors are processors. To determine whether a vendor is a processor, ask two questions:
- Does it process personal data? Note that “Processing” is broadly defined, and its minimum form includes mere storage.
- Does it process the data on the controller’s behalf – that is, for the controller’s purposes and benefit?
If the answer to both questions is yes, the vendor is a processor.
When a processor engages another processor to perform processing activities, that other processor is a sub-processor. Here is a practical example:
CONTROLLER — The Customer; Determines the purposes and means of the processing.
↓ (processes on the controller’s behalf)
PROCESSOR — The SaaS Provider; Processes personal data on the controller’s behalf.
↓ processes on the processor’s behalf
SUB-PROCESSORS — For example: AWS (stores the data) · SendGrid (sends notifications); Process personal data on the processor’s behalf.
Map your sub-processors and maintain a sub-processor list as part of your broader vendor mapping.
A vendor that processes customer data to help deliver services to customers will generally be a sub-processor. A vendor that processes data primarily for your own purposes may instead be your processor, supporting you in your capacity as controller.
Ask three questions about every vendor that touches customer data:
Which vendor do we use? → What data do they process? → What purpose do they serve?
The first two matter, but the purpose is what actually decides the classification – it tells you in whose controllership the vendor operates.
Take the same customer data and ask: whose benefit is the processing for?
- For the customer’s benefit (delivering the service) → e.g. AWS hosting the product → the vendor is your sub-processor (it processes on your behalf, and you’re processing on the customer’s behalf).
- For your benefit (your own purpose) → e.g. an analytics provider you use to improve the product → the vendor is your processor, because you set the purpose. For that processing you act as a controller, not a processor.
Bottom line: the same vendor and the same data may fall into different categories depending not only on the nature of the tool, but also on the purpose for which the data is processed.
Once assembled, your sub-processor list should include:
- Sub-processor name: Use the full contracting entity name, as it may indicate whether data is transferred internationally. For example, engaging a vendor’s U.S. entity indicates a transfer to the United States.
- Service description: Briefly describe the services provided, such as customer data hosting, enabling AI features, or communications provider.
- Processing location: Record where data is processed, which may differ from the contracting entity’s location and include multiple jurisdictions.
- Optional details: Consider including sub-processor contact information and whether a Data Processing Agreement is in place.
Disclosure. Most privacy laws require processors to disclose their sub-processors to controllers. Choose a method that suits your business operations.
Offline disclosure: Attach the list to the Data Processing Agreement as an annex, allowing customers to raise questions during negotiations. If you choose offline disclosure, note that each update may require amending the agreement.
Online disclosure: Publish the list with the Data Processing Agreement on your website, which is particularly suitable for self-service offerings. Allow customers to subscribe to email updates, notify subscribers of changes, and require subscription in the Data Processing Agreement.
Either method is effective if it meets your operational needs, the requirements of the Data Processing Agreement and applicable privacy law.
Sub-processor updates and notifications. Under the GDPR, controllers and processors may agree to either general or prior authorization for sub-processors. General authorization is the industry standard and is generally preferable for processors.
Prior authorization from every customer for each update can be operationally impractical and may create contractual risk. Under a general authorization model, the processor gives advance notice of proposed changes and allows the controller to object on reasonable grounds. This approach is more practical while preserving appropriate controller oversight.
Your Data Processing Agreement should establish a clear, workable process for update notices and objections that supports both operational needs and customer confidence.
Choose sub-processors carefully. They are integral to your service, and you remain responsible for their processing of customer data. Assess whether each sub-processor maintains privacy and security standards comparable to your own. Key red flags include the absence of a data processing agreement, vague privacy terms, and rights to use customer data for its own purposes, such as model training or product improvement. A robust procurement and onboarding process can reduce future costs and liability.
