Sub Processor Agreement: What It Covers and a Template (2026)

What is a sub-processor agreement, and when do you need one? A sub-processor agreement is a contract between a data processor and a party it engages to help it process personal data (the sub-processor). Under the General Data Protection Regulation (GDPR), a processor may only use a sub-processor if it binds that sub-processor by contract to the same data protection obligations the controller imposed on the processor. The sub-processor agreement is how the processor does that. You need one whenever your company processes personal data for a customer (so you are a processor) and you rely on another vendor to do part of the work: a cloud host, an email or messaging service, an analytics provider, an offshore support team. Each of those is a sub-processor, and Article 28 says the obligations must flow down to them. This article is general guidance, not legal advice. Data protection law varies by jurisdiction, so have a qualified professional review your arrangements. ## How the chain works Picture three levels: - Controller. Your customer, who decides why and how personal data is processed.

• Processor. Your company, processing that data on the customer's behalf under a data processing agreement (DPA).
• Sub-processor. A vendor you engage to help you process the data. GDPR Article 28(4) requires the processor to impose on the sub-processor the same data protection obligations set out in the controller-to-processor DPA, in particular the duty to give sufficient guarantees of appropriate technical and organisational measures. If the sub-processor fails to meet its obligations, the original processor stays fully liable to the controller. The duty does not transfer away with the work. Two more Article 28 points shape the agreement: - Prior authorisation (Article 28(2)). The processor needs the controller's authorisation before engaging a sub-processor. It can be specific (named vendors) or general (a list plus a right to object to changes). Under general authorisation the processor must inform the controller of intended changes and give a chance to object.
• Same obligations, written contract (Article 28(3) and (4)). The flowed-down terms typically cover processing only on instructions, confidentiality, security, sub-processing control, assistance with data-subject rights, breach notification, audits, and deletion or return of data at the end. ## Sub-processor agreement template Copy the block below. It is written to flow down from a standard controller-to-processor DPA. ``` SUB-PROCESSOR AGREEMENT This Sub-Processor Agreement ("Agreement") is made on [DATE] BETWEEN: [PROCESSOR NAME], [address] ("Processor") AND [SUB-PROCESSOR NAME], [address] ("Sub-Processor") Background: The Processor processes Personal Data on behalf of its customers (each a "Controller") and engages the Sub-Processor to carry out part of that processing. The Sub-Processor acts only as a processor on the Processor's documented instructions. 1. SCOPE Schedule 1 sets out the subject matter, duration, nature and purpose of the processing, the types of Personal Data and categories of data subjects. 2. PROCESSING ON INSTRUCTIONS The Sub-Processor will process Personal Data only on the Processor's documented instructions, including on international transfers, unless law requires otherwise, in which case it will tell the Processor first unless prohibited. 3. CONFIDENTIALITY The Sub-Processor will ensure persons authorised to process the data are under a duty of confidentiality. 4. SECURITY The Sub-Processor will implement appropriate technical and organisational measures as in Schedule 2, no less protective than those the Processor owes the Controller. 5. FURTHER SUB-PROCESSING The Sub-Processor will not engage another sub-processor without the Processor's prior written authorisation, and will flow down these same obligations to any it engages, staying liable for them. 6. DATA SUBJECT RIGHTS The Sub-Processor will assist the Processor, by appropriate measures, to respond to data subject requests. 7. ASSISTANCE The Sub-Processor will assist the Processor with security, breach notification, data protection impact assessments and prior consultation. 8. BREACH NOTIFICATION The Sub-Processor will notify the Processor without undue delay, and in any event within [N] hours, after becoming aware of a personal data breach, with the detail the Processor needs to meet its own deadlines. 9. AUDIT The Sub-Processor will make available information needed to show compliance and allow and contribute to audits, including inspections, by the Processor or an auditor it mandates. 10. INTERNATIONAL TRANSFERS Any transfer outside the permitted region will use an approved transfer mechanism (for example, Standard Contractual Clauses) as in Schedule 3. 11. DELETION OR RETURN On end of services the Sub-Processor will, at the Processor's choice, delete or return all Personal Data and delete existing copies unless law requires retention. 12. LIABILITY AND TERM [Liability as in Schedule 4.] This Agreement lasts as long as the Sub-Processor processes Personal Data for the Processor. Signed for the Processor: __________ Signed for the Sub-Processor: ______

- **Security (Schedule 2).** Set measures at least as strong as those you promised your customer. A weaker sub-processor is your liability.
- **Further sub-processing (clause 5).** Require your authorisation and the same flow-down, so the chain does not leak obligations at the next level.
- **Breach notification (clause 8).** Set a deadline shorter than your own to the controller, so you have time to assess and report within the GDPR's own timelines.
- **Transfers (clause 10).** If the sub-processor is outside the permitted region, attach the right transfer mechanism. ## Common mistakes to avoid - Flowing down less protection than you promised the controller, which leaves you exposed.
- No control over further sub-processing, so obligations leak at the next level.
- A breach-notification window that is too long for you to meet your own deadlines.
- Treating a sub-processor agreement as the same as the controller-to-processor DPA; it is one level down and must mirror, not replace, it.
- Forgetting international transfer terms when the sub-processor is offshore. ## A note on jurisdiction The flow-down idea is GDPR-specific but the pattern repeats elsewhere. The UK GDPR mirrors Article 28. California's CCPA, as amended by the CPRA, requires service providers to impose the same requirements on their subcontractors. India's Digital Personal Data Protection Act, 2023 restricts a data processor's engagement of others through the controller relationship. The defined terms differ by law, so align the sub-processor agreement with whichever regime your controller contract is built on, and attach a valid transfer mechanism for cross-border flows. Last verified October 2026. ## Where one contract workspace helps A template gets you a sound sub-processor agreement. The ongoing work is keeping flow-down terms consistent across every sub-processor, checking each signed version for a weaker security or breach term before you rely on it, keeping an accurate sub-processor list and remembering to notify controllers of changes, and keeping versions straight as vendors come and go. Drafting, reviewing and tracking sub-processor contracts can also sit in one AI workspace tuned to the DPA you owe your customers. It can draft from your template, model each contract as linked clauses so it flags where a term falls short of what you promised upstream and surfaces the obligations you carry, let you edit a clause in plain language with a tracked diff, and keep breach windows, audits and renewal dates in view. [Adira](https://adiralaw.com) is one tool that brings this into a single workspace. The template alone is enough to put a fair sub-processor agreement in place; a workspace just makes drafting, review and tracking one connected job.