When a vendor adds or replaces a sub-processor, the General Data Protection Regulation (GDPR) gives the controller a short, specific entitlement: to be informed of the intended change and to have the opportunity to object. That entitlement, set out in Article 28(2), is the legal core of every sub-processor change notification — the emails, portal announcements, and page updates through which vendors tell customers that the processing chain behind a service is about to change.
The provision is brief, and everything operational about it — how notice arrives, how long the objection window runs, what objecting achieves — is delegated to the contract. That makes change notifications a place where legal rights and operational reality meet, and sometimes miss: a right to object is only as good as the notification that reaches a mailbox someone actually reads, inside a window that has not already expired.
This article covers the authorization models behind notifications, the objection right and its limits, the delivery mechanisms in common use, what a controller should do when a notice arrives, and how to keep the whole channel from failing silently.
The legal starting point: Article 28(2)
Article 28(2) of the GDPR prohibits a processor from engaging another processor without the controller's prior specific or general written authorization. The two authorization models produce two very different notification duties.
General authorization
Under general written authorization — the standard model in software-as-a-service (SaaS) — the controller approves sub-processing up front, usually by accepting the vendor's current sub-processor list as part of the Data Processing Agreement (DPA). The regulation then attaches a continuing duty: the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object. Two words in that duty carry weight. "Intended" means notice should precede the change, not follow it. And "opportunity to object" means the window between notice and effect must be real enough for a controller to use it.
Specific authorization
Under specific authorization, there is no unilateral change to announce: each new sub-processor requires the controller's approval before engagement. Notifications become requests. This model appears where controllers demand a veto — high-sensitivity data, regulated sectors — and it trades the operational churn of notifications for the heavier process of case-by-case consent. Most controllers meet it rarely; the notification workflow this article describes belongs to the general-authorization world that dominates SaaS contracting.
The right to object and its limits
The GDPR grants the opportunity to object and stops there. It does not say what happens next — no script for negotiation, no mandated remedy. Those consequences live in the DPA, and the common pattern is sobering: if the controller objects and no resolution is found, the practical remedy is usually the right to terminate the affected service, sometimes with a pro-rated refund of prepaid fees. Vendors running shared infrastructure generally cannot exclude one sub-processor for one customer, and their DPAs are drafted accordingly.
Silence, meanwhile, is almost always deemed acceptance once the window closes. That default is what makes the operational side of notifications matter so much: a controller that never saw the notice has, contractually speaking, still accepted the change. The European Data Protection Board (EDPB) underlines in its Guidelines 07/2020 on the concepts of controller and processor that the controller's authorization role is a genuine decision point in the chain — which is hard to square with a process where the decision expires unseen.
How notices arrive in practice
Because the GDPR leaves the mechanism to the parties, vendor practice varies widely. A few patterns recur across the market.
- An email notification, sent either to a contact named in the agreement or to whoever subscribed to a notification list the vendor operates.
- A subscription mechanism on the sub-processor page itself — often the only channel through which proactive notice is available at all.
- A dated updates section or change log on the vendor's trust or legal pages, which counts as notice under some DPAs whether or not anyone reads it.
- A portal or in-app announcement, visible to administrators who log in but invisible to a legal team that does not.
The variation is not cosmetic; it changes who carries the burden of noticing. A DPA that promises email to a named contact puts the burden on the vendor to send. A DPA that deems a web-page update to be notice puts the burden on the controller to check. Reading your own DPAs for which model they use — vendor by vendor — is the unglamorous first step of a working notification process, and the notice clause deserves the same scrutiny as any other term in our guide to GDPR Article 28 DPA requirements.
What to do when a notification arrives
A sub-processor change notice is a small compliance event with a deadline attached. A repeatable sequence keeps it manageable.
- Read the notice against the contract: confirm it matches the promised mechanism and that you know when the objection window closes.
- Establish what is changing: which entity is added or replaced, what function it performs, and which personal data it will touch. If the role is unclear, our explainer on what a subprocessor is covers how to place a new party in the chain.
- Check locations and transfers: a new processing country can alter the transfer analysis for the service, pulling in Chapter V questions that the original assessment never faced.
- Assess proportionately: a replacement hosting region may need minutes; a new analytics provider touching customer content deserves more.
- Decide: accept, ask questions, or object through the contractual path — and calendar the deadline, because the path closes when the window does.
- Record the outcome: update your Records of Processing Activities (RoPA) where recipient categories changed, and file the assessment with the decision.
Most changes will be accepted; that is not a failure of the process but its normal output. The value of the sequence is that acceptance becomes a documented decision rather than a default.
The failure mode: notices that never land
Every privacy team eventually discovers a sub-processor change it was never told about — or was told about in a way nobody caught. The causes are mundane. The notification subscription was created by an employee who has since left, and the confirmation email to re-subscribe went nowhere. The vendor's notice went to a procurement alias that filters external mail. The DPA deemed a web-page update to be sufficient notice, and no one was checking the page. Or the vendor simply updated the list quietly, out of step with its own contract.
The consequences compound because the mechanism fails silently. The objection window expires unused. The authorization stands by default without any assessment behind it. The RoPA drifts out of date, and a transfer analysis keeps relying on a processing map that no longer exists. None of this announces itself; it surfaces later, in an audit, a customer questionnaire, or an incident, when the question "when did this sub-processor appear?" has no documented answer.
The mitigation is redundancy: treat vendor notifications as the primary channel, and monitor the sub-processor pages themselves as the safety net that catches what the primary channel drops. Our guide on how to monitor subprocessor changes covers how to build that second layer without turning it into a manual chore.
Documenting the decision trail
The GDPR's accountability principle — Article 5(2), reinforced by Article 24 — expects controllers to be able to demonstrate how they meet their obligations, and sub-processor governance is part of that. A defensible trail for each change is short: the notice as received (or the page change as detected), the date it arrived and the date the window closed, the assessment performed, the decision taken, and who took it. Kept consistently, the trail converts a scattered inbox history into evidence that the authorization regime in your DPAs is actually operated.
The trail also has an audience beyond regulators. Your own customers' due-diligence questionnaires increasingly ask how you govern your processors' chains, and a dated record of assessed changes answers in a way that a policy document cannot.
Where DPAFlow fits in
The weakest link in this whole chain is delivery — notices that miss, pages that change silently, windows that expire. DPAFlow monitors your vendors' sub-processor lists, DPA pages, and trust-center pages on a scheduled, recurring basis and detects changes with dated evidence: captured page text, change diffs, and screenshots where available. Detected changes trigger email alerts — immediately or in a daily digest — and enter a review workflow where your team assesses the change and documents the decision, building the trail as a by-product of handling each event.
You can see how monitoring, alerts, and the review trail fit together on the DPAFlow product page.