GDPR Article 28: subprocessor obligations explained

GDPR Article 28 is the regulatory foundation for processor and subprocessor relationships. It sets out the binding legal obligations that must be in place whenever a processor handles personal data on behalf of a controller. Understanding Article 28 is essential for any B2B company using cloud services, vendors, or subcontractors to process data—which is virtually every B2B SaaS company.

Article 28(1) requires that any processor acting on behalf of a controller must ensure 'sufficient guarantees' regarding appropriate technical and organisational measures (TOMs). This means the processor must implement security controls, access restrictions, encryption, audit logs, and incident response procedures appropriate to the risk. The processor must also be bound to the controller by a contract or other legal act—the DPA—that reflects the processor's obligations under Article 28.

Article 28(2) addresses processor authorisation and notification. Before a processor engages a subprocessor, the controller must give prior specific or general written authorisation. 'Specific' authorisation means the controller approves each subprocessor individually; 'general' authorisation means the controller approves a framework allowing the processor to add subprocessors under agreed conditions. Crucially, the processor must inform the controller of any intended change concerning the addition or replacement of subprocessors and give the controller a reasonable opportunity to object. If the controller objects on reasonable grounds, the processor must not engage the subprocessor or must find a solution acceptable to the controller.

Article 28(3) lists eight mandatory DPA terms: (a) the processor acts only on the controller's documented instructions; (b) persons authorised to process the data are under confidentiality obligations; (c) the processor implements the security measures required by Article 32; (d) sub-processor processing is governed by a contract imposing the same data protection obligations; (e) the processor assists the controller in ensuring the rights of data subjects (access, rectification, erasure, portability, etc.); (f) the processor assists the controller in fulfilling its own obligations under Articles 32 (security), 33 (breach notification), 34 (breach communication), 35 (impact assessment), and 36 (authority consultation); (g) personal data is deleted or returned after the end of the service; (h) the processor makes available all information necessary to demonstrate compliance and allows for audits and inspections by the controller or the controller's auditor. These eight obligations are non-negotiable.

Article 28(4) establishes full processor liability for sub-processors. If a processor engages a subprocessor without proper authorisation or without a compliant contract in place, the processor remains fully liable to the controller for the subprocessor's non-performance of the data protection obligations. In other words, the processor cannot off-load its compliance responsibility to a subprocessor; the processor is ultimately accountable for all subprocessors in its chain, no matter how long the chain becomes.

What records must a processor keep? You should be able to produce, on request, your current subprocessor list, the history of changes (additions and removals with dates), evidence that controllers were notified (timestamps and delivery records), the notice period applied for each customer, any objections received and how they were resolved, and the DPAs with each subprocessor. A shared inbox is not a record; auditors expect a structured, timestamped trail.

Common compliance mistakes include: engaging subprocessors without prior controller notification; failing to pass down all eight Article 28(3) obligations to subprocessors in writing; not getting the controller's authorisation in advance; claiming a vendor is 'not a subprocessor' when it clearly processes personal data; using a DPA that omits or weakens one of the eight mandatory terms; relying on a single public list rather than per-client scoped lists; and treating the DPA as a one-time document rather than a living record.