Every SaaS company that processes customer data on its customers' behalf has sub-processors. The hosting provider, the email delivery service and the support tool all touch customer personal data. Customers know this. What they expect is a current list, advance notice of changes, and a real chance to object.
Most sub-processor problems are operational, not legal. The data processing agreement says the right things. Then an engineering team adds a new vendor, nobody updates the list, and a customer finds out from a questionnaire answer that does not match the published page.
This article covers what GDPR requires, how to decide who belongs on the list, and how to run the notice and objection process so it holds up.
What Article 28 actually requires
Two paragraphs of GDPR Article 28 do most of the work.
Article 28(2) says a processor must not engage another processor without the controller's prior specific or general written authorization. Under a general authorization, the processor must inform the controller of any intended addition or replacement of other processors, giving the controller the opportunity to object.
Article 28(4) says that when a processor engages a sub-processor, the same data protection obligations set out in the controller contract must be imposed on the sub-processor by contract. If the sub-processor fails to meet them, the original processor remains fully liable to the controller.
Two things follow. First, the notice must come before the change, because the point is to allow an objection. Second, you are accountable for your sub-processors' performance, so selecting and monitoring them is your job, not the customer's.
GDPR does not set a notice period. The parties agree one in the data processing agreement. The EU standard contractual clauses for processor-to-processor transfers follow the same model: under the general authorization option, the parties fill in the advance notice period themselves. Contract terms for sub-processing are covered in what belongs in a GDPR data processing agreement. This article assumes you have one and focuses on running it.
Who counts as a sub-processor
A sub-processor is a third party that processes personal data on your behalf, where that data is data you process on behalf of your customer. If you are not sure which data you hold as a processor, start with controller vs processor: which one are you?.
That definition excludes more vendors than people expect. A practical test is to ask three questions of each vendor:
Does it process personal data? Not only store it: access, transmit or analyze it.
Is that data customer data you process as a processor? Your own payroll provider processes personal data, but it is your employees' data, held as a controller. It is a vendor, not a sub-processor.
Does it process the data on your behalf? A cloud provider hosting your database does. A vendor you share an anonymized aggregate report with does not.
Groups that usually belong on the list:
Infrastructure and hosting providers
Email, SMS and notification delivery services carrying customer data
Support, ticketing and chat tools that hold customer user data
Error tracking and logging services that receive personal data in payloads
AI model providers that receive customer content
Your own affiliates that process customer data, such as an overseas support entity
Error tracking and AI providers are the two most often missed. Engineers add them for good reasons, and nobody connects them to the list until a customer asks.
What the sub-processor list should show
A useful list gives a customer's privacy team what they need to assess the change without writing to you. For each entry:
| Field | Why the customer needs it |
|---|---|
| Legal entity name | Identifies who holds the data, not only the brand |
| Service or purpose | Lets them judge whether the processing is proportionate |
| Categories of data | Shows what the sub-processor actually receives |
| Processing location | Determines whether a transfer mechanism is needed |
| Transfer mechanism | Shows how transfers outside the EEA are covered |
| Products or features affected | Lets customers who do not use a feature ignore the change |
Publish the list at a stable URL, and keep a dated change log on the same page. The change log is what you will point to when someone asks whether a vendor was on the list in a given month.
When a sub-processor is outside the EEA, the transfer needs a mechanism, such as the standard contractual clauses, and usually a transfer impact assessment. Record which applies on the list itself.
Running the notice process
The notice process should be boring and identical every time. A workable flow:
Catch the change early. Put a sub-processor question into vendor intake and into engineering design review. "Will this vendor receive customer personal data?" is enough to route it.
Complete due diligence before notice. Security review, data protection terms with the vendor, and a transfer assessment if needed. Do not notify customers of a vendor you might not use.
Update the list with a future effective date. Show the vendor as "planned", with the date it will start processing.
Notify subscribers. Most companies offer an email subscription for list changes. Send the notice to that list and to any customer whose contract requires direct notice to a named contact.
Wait out the notice period. Do not start sending customer data to the vendor until the period has passed.
Handle objections, as described below.
Go live and record it. Update the status, and keep the notice, the recipient list and the date as evidence.
The most common failure is step five. The vendor is already in production when the notice goes out, which defeats the purpose and breaches the contract.
When a customer objects
Article 28(2) gives the controller the opportunity to object. It does not say what happens next. That is set by your contract, and the options are usually some combination of these:
Discuss the concern. Many objections are requests for information. A security summary or the vendor's assurance reports often resolve them.
Offer an alternative. Configure the customer's account so the new sub-processor does not receive their data, where the architecture allows it.
Let the customer terminate the affected service. Many DPAs allow termination of the affected part of the service, sometimes with a refund of prepaid fees, if the objection cannot be resolved.
Decide your position before the first objection arrives. Make sure sales and support know where to route one. Whether your contract wording gives the customer a right to block a change, or only to terminate, is a point to confirm with counsel.
Due diligence and ongoing oversight
Because you remain liable for your sub-processors, your obligations continue after onboarding. Treat sub-processors as your highest vendor tier: they hold customer data and they appear in customer contracts. The approach in vendor tiering by data access applies directly.
For each sub-processor, keep:
- Not done:
A signed data protection agreement with Article 28-equivalent terms
- Not done:
Security assurance, such as a current SOC 2 report or ISO 27001 certificate, reviewed by someone who read it
- Not done:
The transfer mechanism and assessment, where data leaves the EEA
- Not done:
A reassessment date
- Not done:
An offboarding record when the vendor is removed, including confirmation that data was deleted or returned
Your sub-processors have sub-processors of their own. You do not need to list them on your page, but you should understand that your contract with each vendor requires them to flow obligations down. Fourth-party risk explained covers how far to look.
How TrustLynce helps
TrustLynce keeps your vendor inventory, risk tiers and reassessment dates in third-party risk, so sub-processors are tracked as your highest-risk vendors. Contractual notice commitments can be tracked against the processes that meet them in customer commitments.