Article 28(2) of the General Data Protection Regulation (GDPR) states that a processor shall not engage another processor without prior specific or general written authorization of the controller. Those two words describe two different operating models, and choosing between them determines who carries the ongoing work of supervising the chain.
Under specific authorization, the processor asks before each engagement and waits for your answer. Under general authorization, you approve a described set of sub-processors up front, and the processor must inform you of intended additions or replacements and give you the opportunity to object.
Both are lawful. They are not equivalent in practice, and the difference is not really about legal risk. It is about where the burden sits.
Specific authorization
The processor identifies a proposed sub-processor and seeks your approval before engaging it. Nothing happens until you respond.
This model gives the controller the most direct control, and it is workable where the chain is short and stable: a payroll bureau with two named sub-processors, a specialist supplier serving a handful of clients, a bespoke arrangement negotiated between two parties of comparable size.
It becomes unworkable at scale. A large software supplier serving thousands of customers cannot pause a regional infrastructure migration while it collects individual approvals. That is why the model appears mostly in negotiated enterprise arrangements and rarely in standard terms.
The practical cost to you is responsiveness. If you hold approval rights and do not exercise them promptly, you become the bottleneck, and suppliers will push to move you onto a general model at renewal.
General authorization
You approve sub-processing in principle, usually by accepting the supplier's current sub-processor list as part of the contract. The supplier may then change that list, subject to two duties: informing you of intended changes, and giving you an opportunity to object.
This is the standard model in software-as-a-service, and it is the right default for most relationships. It also transfers a real obligation onto you, and the obligation is easy to miss because nothing about it feels like work until it goes wrong.
Under general authorization, your protection is entirely procedural. It consists of noticing the notification, assessing the change, and objecting inside the window. If any of those three steps fails, the change takes effect by default and your authorization becomes a formality. Our article on subprocessor change notifications covers the delivery mechanics, and how to handle an objection covers what to do when you decide the change is unacceptable.
What "inform" actually means in contracts
The GDPR requires the processor to inform the controller of intended changes. Contracts vary considerably in how that duty is discharged, and the differences matter more than the clause length suggests.
Things worth checking in the drafting:
- The channel: a direct email to a named contact, a notification you must subscribe to, or a page you are expected to check.
- The lead time: how many days before the change takes effect.
- The objection window: how long you have, and whether it runs from the notice or from publication.
- The consequence of objecting: whether the supplier must propose an alternative, whether the change is paused, or whether your only remedy is termination.
- Whether replacements are treated differently from additions.
A subscription-based notice combined with a short window is the pattern most likely to fail quietly, because it depends on a subscription that one person set up and nobody maintains. A clause obliging the supplier to notify a role-based address is materially more robust than one obliging you to watch a page.
The objection remedy is usually weaker than it looks
Most standard terms provide that if you object on reasonable data protection grounds, the supplier will use reasonable efforts to make an alternative available, and if it cannot, you may terminate the affected service.
Read that carefully before relying on it. For a deeply embedded system, termination is not a remedy you can realistically exercise over a single sub-processor change. This is not a reason to accept the clause without thought; it is a reason to weight the assessment towards vendors whose chain you can live with, and to know in advance which of your suppliers you could actually leave.
Which model to ask for
For most relationships, general authorization with strong notice mechanics is a better outcome than specific authorization with weak ones. Negotiating hard for specific authorization from a supplier that cannot operate it produces either a refusal or a clause the supplier will breach routinely.
Concentrate negotiating effort on the notice terms instead:
- Notification pushed to a role-based address rather than a page you must poll.
- A lead time long enough to run an assessment, not merely to read an email.
- An objection window that starts when you are notified.
- An explicit obligation to identify the entity, its role, and its location, rather than announcing a change in the abstract.
Where the data is sensitive enough to warrant it, specific authorization for a defined subset, such as any sub-processor outside the European Economic Area, is a middle position some suppliers will accept.
Frequently asked questions
Does general authorization mean we have approved future sub-processors?
Not unconditionally. You have approved the model, and the supplier owes you notice and an opportunity to object. The authorization operates prospectively but the objection right is what preserves your position.
What are reasonable grounds for objection?
Data protection grounds: a destination that changes the transfer analysis, a sub-processor whose guarantees you consider insufficient, or a change that conflicts with commitments you have made to your own customers. Commercial dislike is not a data protection ground.
Does silence count as approval?
Under general authorization, an unanswered notice usually means the change proceeds. That is precisely why the delivery of the notice matters more than the wording of the right.
Do we need to record which model each vendor uses?
Yes. It determines what you must do when a change arrives, and it varies across your vendor population. Recording it alongside the contract makes the difference actionable rather than theoretical.
Where DPAFlow fits in
General authorization only protects you if changes reach a person inside the window. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records what changed with dated evidence including captured page text and change differences, and sends email alerts. Detected changes enter a review workflow where your team assesses the change and documents its decision.
That covers the failure mode this model is most exposed to: a change published to a page you were expected to watch. DPAFlow does not decide whether grounds for objection exist and does not provide legal advice. The wider workflow is described on the product page.
This article explains two contractual models in general terms. It is not legal advice, and the drafting and objection calls belong to your counsel.