Sub-Processor Agreements, Explained (2026)

A sub-processor is a company that a processor hires to help it process personal data on a controller's behalf. If you use a SaaS vendor, and that vendor runs on a cloud host, sends emails through a messaging provider, and uses an analytics tool, those downstream providers are sub-processors. The GDPR controls this chain tightly, because the controller still answers for data it never directly handed to those downstream parties. This guide explains what the rules require, how flow-down works, and how to draft the sub-processor clause so the chain holds. ## What a sub-processor is The roles under the GDPR are controller (decides why and how data is processed), processor (processes on the controller's instructions), and sub-processor (processes on the processor's instructions, further down the chain). A sub-processor is sometimes called a sub-contracted processor. The defining feature is that it handles the controller's personal data but has no direct contract with the controller; its contract is with the processor. This matters because the controller remains responsible to data subjects and regulators for the whole chain. If a sub-processor leaks data, it is the controller's breach to manage. The law therefore does not let a processor hire sub-processors freely. ## Authorisation: the Article 28 rule Under GDPR Article 28, a processor may not engage a sub-processor without the controller's authorisation. There are two accepted forms: - Specific authorisation. The controller approves each named sub-processor individually. This gives the controller the most control but is impractical for large SaaS vendors with many sub-processors.

• General written authorisation. The controller authorises the processor to use sub-processors generally, on condition that the processor keeps an up-to-date list, informs the controller of any intended addition or replacement, and gives the controller a chance to object before the change takes effect. Most modern vendor DPAs use general authorisation with a published sub-processor list and a change-notice-and-objection process. This is the practical standard, but the controller should check the notice period and what rights it has if it objects. ## Flow-down: the same obligations all the way down Article 28 requires that where a processor engages a sub-processor, it must impose on that sub-processor, by contract, the same data protection obligations that apply to the processor under its contract with the controller, in particular the Article 32 security obligations. This is flow-down. The obligations the controller imposed on the processor must cascade, unchanged in substance, to every link in the chain. Flow-down also governs international transfers. If the chain crosses a border into a non-adequate country, the right Standard Contractual Clauses module must be used at that link too, often the processor-to-processor module (Module Three). The sub-processor agreement therefore carries both the Article 28 obligations and, where relevant, the transfer mechanism. ## Liability: the processor stays on the hook Article 28 is explicit that where a sub-processor fails to meet its data protection obligations, the initial processor remains fully liable to the controller for the sub-processor's performance. The processor cannot escape responsibility by pointing downstream. For the controller, this is reassuring, but it only helps if the processor can actually meet a claim, so the indemnity and liability cap in the main DPA, and the processor's insurance, still matter. ## The sub-processor list and change notice Under general authorisation, the sub-processor list is the controller's main visibility into the chain. A good clause requires: - a current list, often maintained at a public URL, naming each sub-processor, its location, and the processing it performs;
• advance notice of any new or replacement sub-processor, with a stated notice period;
• a right for the controller to object on reasonable, data-protection grounds within a window; and
• a consequence if the controller objects and the parties cannot resolve it, usually a right for the controller to terminate the affected service. The weak point in many vendor DPAs is the objection remedy. If the only remedy for objecting is termination, a controller locked into the service has little real choice. Negotiate a workable notice period and a sensible resolution path. ## What each side wants The controller wants visibility of the full chain, meaningful advance notice, a real right to object, flow-down of its security standards, confirmation that the processor stays liable, and SCCs where the chain crosses borders. The processor wants general authorisation so it can manage its supply chain without seeking consent for every change, a reasonable notice period, and an objection process that does not let a single customer block a change needed for all customers. It will resist specific authorisation and very short notice periods. ## Illustrative wording > "The Customer grants the Processor general authorisation to engage Sub-processors, subject to this clause. The Processor shall maintain a current list of Sub-processors at [URL] and shall notify the Customer at least [30] days before adding or replacing a Sub-processor. The Customer may object on reasonable data protection grounds within [15] days of notice; if the parties cannot resolve the objection, the Customer may terminate the affected Services. The Processor shall impose on each Sub-processor, by written contract, data protection obligations no less protective than those in this Agreement, including the security measures, and shall remain fully liable to the Customer for each Sub-processor's performance. Where a Sub-processor is located in a country without an adequacy decision, the Processor shall put in place the appropriate Standard Contractual Clauses." ## Common mistakes to avoid - Relying on general authorisation without checking the notice period and objection remedy.
• No flow-down clause, so downstream providers are not bound to the same standards.
• Forgetting SCCs at the sub-processor link where the chain crosses a non-adequate border.
• Assuming the processor's liability for sub-processors is enough without checking it can actually pay.
• A sub-processor list that is never kept current, so the controller cannot see the real chain.
• An objection process whose only remedy is termination the controller cannot realistically use.
• Not aligning the sub-processor list across the DPA and the SCC annexes. ## Keeping the processing chain visible across vendors The sub-processor chain changes constantly: vendors add cloud regions, swap analytics tools, and update their lists. Keeping track of who sits downstream of each of your vendors, whether flow-down and SCCs are in place, and whether a new sub-processor triggered an objection window is slow manual work when done across many DPAs. An AI contract workspace that extracts sub-processor terms and transfer mechanisms across your vendor contracts, and flags changes, keeps the chain visible. Adira drafts, reviews, and tracks contracts, including data processing and sub-processor terms, in one place. More at Adira. The guidance above stands on its own. ## Bottom line A sub-processor agreement governs the companies a processor hires further down the chain to handle your personal data. Under GDPR Article 28, a processor needs the controller's authorisation (specific or general) to use sub-processors, must flow the same data protection and security obligations down by contract, and remains fully liable for them. Add SCCs where the chain crosses into a non-adequate country, insist on a current list and a workable notice-and-objection process, and keep the list consistent across your DPA and SCC annexes. Get specialist data protection advice for live arrangements.