Sub-processor management is one of the operational hot spots of GDPR compliance. Article 28(2) requires that a processor obtain prior authorisation from the controller before engaging another processor — either specific authorisation for a named sub-processor, or general authorisation under a notification regime. In practice, almost every commercial SaaS DPA uses the general authorisation model, with a published list and a notice-and-objection workflow.
That sounds clean on paper. In practice, a mid-size organisation with thirty to sixty SaaS vendors will receive several sub-processor change notifications every month, each requiring some level of triage. Most teams have no documented workflow, so the notifications either get ignored or trigger panicked one-off assessments. Both extremes create regulatory exposure.
This guide describes a workflow that scales — what to track, how to triage incoming notifications, and where the regulatory risk actually lives.
What Art. 28(2) requires, precisely
The controller-processor relationship is the legal frame. The processor is acting on the controller’s behalf, on documented instructions. When the processor wants to engage a sub-processor — another entity that will process the same personal data — the controller has a right to know and, if the DPA uses general authorisation, a right to object.
The 2021 EU SCC framework, Module Two, Clause 9, codifies the general authorisation model. The processor must inform the controller in advance of intended changes to the sub-processor list, the notice must include enough information for the controller to assess the change, and the controller must have a reasonable period to object.
What counts as “reasonable” is not defined in the regulation, and DPAs vary widely. Thirty days is common. Fourteen days appears for some vendors. Some aggressive vendors push for as little as seven days. The shorter the window, the harder it is to do meaningful assessment.
When a controller objects, the consequence depends on the DPA. The minimum protection is the right to terminate the contract without penalty if the parties cannot agree on a workaround. Stronger DPAs require the processor to refrain from using the new sub-processor for the objecting controller’s data while the dispute is being worked. Negotiating that stronger version is meaningful leverage.
The four types of sub-processor change
Not all sub-processor changes are equivalent. A defensible workflow triages incoming notifications by category before deciding how much effort to spend.
Type one: infrastructure scope. The vendor is adding a new cloud region or expanding into a new data centre operated by an existing sub-processor (typically AWS, Azure, or GCP). The legal risk is usually low if the controller is already comfortable with the cloud provider relationship. Most notifications fall in this bucket and warrant a quick acknowledgement rather than a full assessment.
Type two: like-for-like swap. The vendor is replacing one sub-processor with another offering the same service — switching from one email delivery provider to another, replacing one error tracking service with another. The assessment hinges on whether the new sub-processor’s location, ownership, and certification footprint are equivalent or better than the previous one. A swap from a US-headquartered email provider to an EU-headquartered email provider is a positive change. The reverse warrants scrutiny.
Type three: new function. The vendor is introducing a sub-processor for a function it previously handled in-house, or for a new product feature. This is the highest-risk category. The new sub-processor will see personal data it has not previously seen. The controller’s TIA needs updating. The questions are: what data flows to this new sub-processor, is the legal basis for the transfer maintained, what are the technical and organisational measures.
Type four: removal. The vendor is removing a sub-processor. Usually a positive change. Worth confirming that data previously processed by the removed sub-processor has been deleted on the appropriate timeline.
Building a sub-processor inventory that doesn’t rot
The single most useful artefact in this space is a current view of all sub-processor relationships across all vendors. Without it, every sub-processor notification triggers a full re-scoping from scratch.
The inventory needs three columns at minimum. First, the vendor relationship — which of your SaaS vendors uses this sub-processor. Second, the sub-processor identity — legal entity, country, function. Third, the data category — what kind of personal data flows to this sub-processor under this vendor relationship.
A modest organisation with thirty SaaS vendors might have a sub-processor inventory of two hundred to four hundred entries, since most enterprise SaaS vendors disclose ten to twenty sub-processors each. The inventory is large but not unmanageable. A spreadsheet works for organisations under one hundred SaaS vendors. Larger organisations need a tool.
The inventory’s value is that it lets you answer two operationally important questions quickly. First, which of my vendors uses [a specific sub-processor] — useful when that sub-processor has a breach or regulatory issue. Second, which sub-processors am I exposed to across my entire vendor footprint — useful for the annual board-level data protection report.
The maintenance discipline is to update the inventory every time a sub-processor notification arrives. If you let it slide for three months, you have an artefact that is more dangerous than useful — it reads as authoritative but is actually outdated.
The triage workflow
For a typical notification, the workflow is short.
Read the notification and classify the change into one of the four types above. Update the sub-processor inventory to reflect the change.
For type-one and type-four changes, log the change and move on. No further action needed unless the inventory reveals a previously unnoticed concentration risk.
For type-two changes, compare the new sub-processor against the old one on the four data points that matter: ownership country, processing country, certification footprint, published transparency posture. If the new sub-processor is materially worse than the old one — for instance, moving from an EU sub-processor to a US one — flag for fuller review.
For type-three changes, schedule a fuller review. Update the TIA for the vendor. Confirm that the new processing relationship is covered by the existing DPA scope. Decide whether to accept, negotiate, or object.
The objection mechanism is rarely used in practice, partly because the consequence — termination — is high friction, and partly because most type-three changes are accompanied by genuine product improvements that the controller wants to use. The threat of objection is more leverage than the act of objection. Vendors who know their customers are paying attention to sub-processor changes tend to give better notice, more detail, and softer transitions.
When sub-processor concentrations matter
A subtle risk emerges from the cumulative pattern of sub-processor relationships across a vendor portfolio. If thirty of your SaaS vendors all use the same email delivery provider, the data protection profile of that provider becomes a portfolio-level concern, not a per-vendor one. A breach at that single provider would have outsized impact.
The sub-processor inventory reveals these concentrations. Common ones in EU SaaS portfolios include AWS for hosting, Stripe for payments, Mailgun and Postmark for transactional email, Sentry for error tracking, Datadog for observability, and Salesforce or HubSpot for CRM linkages where the vendor uses these as marketing infrastructure rather than as the primary processor.
For each concentration, the analytical question is the same: does the provider’s location, ownership, and compliance posture meet the standard you would require if they were a directly contracted processor? If not, the concentration is a procurement-level risk, not a vendor-level one. The fix is sometimes to pick vendors that use a different infrastructure stack — which is one of the practical reasons EU-native SaaS vendors that use European hosting infrastructure rather than US hyperscalers are appealing in some procurement contexts.
What good vendor practice looks like
A vendor that takes sub-processor management seriously will exhibit a few clear signals. The sub-processor list is public, versioned, and dated. The change notification mechanism is something more than a buried email — typically an RSS feed, a webhook, or an opt-in email list specifically for sub-processor changes. The notice period is at least thirty days. The notification includes the new sub-processor’s function, location, and certification footprint, not just the name. There is a documented objection mechanism with a real consequence.
A vendor that meets all of these signals is the exception rather than the rule, but the gap is narrowing. The vendors who are weakest on this dimension tend to be older, established enterprise vendors who built their sub-processor practices before GDPR enforcement matured. Newer EU-native vendors built sub-processor governance into the product from the start and tend to outperform on this dimension.
The annual sub-processor audit
Once a year, sit with the sub-processor inventory and ask the structural questions. Are there sub-processors that have changed ownership? Are there sub-processors in countries whose data protection regime has shifted (CLOUD Act developments, adequacy decisions reviewed, Schrems II follow-on litigation)? Are there sub-processor concentrations that have become uncomfortable? Are there vendors who have been quietly drifting toward third-country sub-processors?
The annual audit closes the loop on the year of notifications. It is the artefact that demonstrates to a regulator that you are not merely reacting to vendor announcements but actively managing your sub-processor exposure.
Sub-processor management is unglamorous procurement infrastructure, but it is one of the dimensions where the buyer side actually has leverage. Vendors notice when their customers ask informed questions about sub-processor changes. The vendors who respond well are usually the ones worth keeping; the ones who respond poorly are signalling something useful about the next several years of the relationship.