What is a sub-processor under GDPR

What is a Sub-Processor Under GDPR?

Summary

A sub-processor is a third party that a processor engages to process personal data on behalf of a controller. Under Article 28(2) GDPR, the processor needs the controller’s prior written authorisation, either specific or general. Article 28(4) requires the controller to impose the same data protection obligations on the sub-processor by contract, and the initial processor remains fully liable to the controller for the sub-processor’s performance.

This guide covers what a sub-processor is, how authorisation works, what the contract must contain, who is liable, breach notification, international transfers and the records to keep. It applies to Article 28 of the GDPR, and the UK GDPR has equivalent provisions.

Key Takeaways

• A processor cannot engage a sub-processor without the controller’s prior specific or general written authorisation. Under general authorisation, the processor must inform the controller of any intended additions or replacements and give it a chance to object.

• The sub-processor contract must impose the same data protection obligations as the controller-processor contract. The initial processor remains fully liable to the controller if the sub-processor fails to meet them (Article 28(4)).

• The EDPB’s Opinion 22/2024 says a controller should have the identity of all processors and sub-processors readily available at all times. The controller ultimately decides whether to engage a sub-processor and remains responsible for verifying its guarantees.

A Sub-Processor Is a Processor Engaged by Another Processor

The GDPR does not define a sub-processor as a separate role. Article 28(2) and (4) refer to a processor engaging “another processor”. The sub-processor processes personal data for the controller’s purposes, on the first processor’s instructions, and does not decide why or how the data is used.

Typical examples are a cloud hosting provider used by a software company, an email delivery service used by a marketing platform, and a call centre used by a payroll provider.

The line between roles follows what the party does in practice. Under Article 28(10), a processor that determines the purposes and means of processing in breach of the GDPR is treated as a controller for that processing. Our guide to controllers and processors explains how to tell them apart.

The Controller Must Authorise Every Sub-Processor in Writing

Article 28(2) says the processor must not engage another processor without the controller’s prior specific or general written authorisation. There are two models:

• Specific authorisation: the controller approves each named sub-processor. This provides the most oversight and administrative burden.

• General authorisation: the controller approves in advance that the processor may use sub-processors, usually from a stated list or category. The processor must inform the controller of any intended addition or replacement, allowing it to object.

The GDPR does not fix a notice period or say what happens if the controller objects. Those are matters for the contract. A contract usually states the notice period, what happens to the new sub-processor while an objection is open, and whether the controller may terminate.

The EDPB’s Opinion 22/2024 of October 2024 adds that the processor should propose sub-processors that offer sufficient guarantees, and that the controller retains the ultimate decision-making authority and responsibility for engaging a specific sub-processor.

The Sub-Processor Contract Must Pass Down the Same Obligations

Article 28(4) requires a contract or other legal act that imposes on the sub-processor the same data protection obligations as those in the controller-processor contract. It must give sufficient guarantees to implement appropriate technical and organisational measures.

The obligations that must flow down are those listed in Article 28(3). The sub-processor must:

• process personal data only on documented instructions, including on transfers to third countries;

• ensure that people authorised to process the data are bound by confidentiality;

• take the security measures required by Article 32;

• respect the conditions for engaging further processors;

• assist with data subject requests and with the controller’s duties under Articles 32 to 36;

• delete or return the data at the end of the services; and

• make available the information needed to show compliance and allow audits.

Article 28(9) requires the contract to be in writing, including in electronic form. The Commission has adopted standard contractual clauses for controller-to-processor contracts under Article 28(7) in Implementing Decision (EU) 2021/915, and the contract can be based on them in whole or in part.

Adherence to an approved code of conduct or certification can demonstrate sufficient guarantees (Article 28(5)). It does not replace the contract.

The Initial Processor Stays Liable to the Controller

Article 28(4) says that where a sub-processor fails to fulfil its data protection obligations, the initial processor remains fully liable to the controller for the performance of the sub-processor’s obligations. The controller therefore has one counterparty for the whole chain. The processor can then pursue the sub-processor under their contract.

Liability to individuals follows a different rule. Article 82 gives a person who suffers damage the right to claim compensation from the controller or processor. A processor is liable for damage only if it has failed to comply with obligations specifically aimed at processors or has acted outside or against the controller’s lawful instructions. Where several parties are responsible for the same damage, each can be held liable for the entire amount, with a right to recover the shares of others.

The two rules answer different questions: Article 28(4) covers who answers to the controller, and Article 82 covers who answers to the individual.

A Processor Must Tell the Controller About a Breach Without Undue Delay

Article 33(2) says a processor must notify the controller “without undue delay” after becoming aware of a personal data breach. In a chain, the contract should require the sub-processor to notify its processor in the same way, so the processor can then notify the controller.

The 72-hour period in Article 33(1) applies to the controller’s notification to the supervisory authority, where feasible, after the controller becomes aware of the breach. The GDPR gives processors no 72-hour window.

A contract can require faster notice from the sub-processor, such as 24 or 48 hours, so the chain doesn’t use up the controller’s time. See our guide to data breach reporting.

Sub-Processors Outside the EEA Need a Transfer Route

If a sub-processor is outside the EU and the EEA, or can access the data from there, the transfer needs a Chapter V route: an adequacy decision, appropriate safeguards such as standard contractual clauses, or a narrow derogation. If you rely on clauses, the exporter must assess whether the destination country’s law and practice allow compliance. That follows from the Schrems II judgment.

The controller’s Article 28(1) duty to use only processors that provide sufficient guarantees applies to the processors it engages, and it needs to be able to see the chain below them.

Our guide to transferring personal data outside the EU covers each route.

A Current Register and Review Process Support Compliance

Controllers and processors should keep:

• a list of every sub-processor with its name, address, contact person, location, purpose and the data involved;

• the authorisation record and any objection and the response;

• the contract and its version, with the sub-processor’s security evidence;

• the transfer route and any assessment for each sub-processor outside the EEA; and

• the date of the last review.

The EDPB’s opinion says the identity information should be available at all times, so the register needs an owner and an update process. Processors must also provide this information to controllers. A published sub-processor page with a change notice sign-up often does this.

The UK GDPR Has Equivalent Rules

UK GDPR Article 28 contains the same authorisation, contract and liability rules. The ICO’s guidance on contracts and liabilities between controllers and processors explains them. For transfers out of the UK, the UK International Data Transfer Agreement and the UK Addendum to the EU clauses are the common safeguards.

Conclusion

A sub-processor relationship is lawful when the controller has authorised it, the contract passes down the same obligations, the processor stays accountable, and the controller can see who is in the chain. The breach notice duty runs without undue delay at each step, and transfers need their own route.

We are publishing this guide because sub-processor chains are where controllers most often lose sight of who holds their data, and the EDPB addressed the point in its October 2024 opinion. Review your processing agreements and sub-processor lists against Article 28 and that opinion, and speak to our GDPR consultants if you want them checked.

Frequently Asked Questions

Can a Processor Use a Sub-Processor Without Controller Approval?

No. Article 28(2) requires the controller’s prior written authorisation, either specific or general. Under general authorisation, the processor must inform the controller of intended changes and allow it to object.

Who Is Liable if a Sub-Processor Causes a Breach?

The initial processor remains fully liable to the controller for the sub-processor’s performance under Article 28(4). Individuals can claim compensation under Article 82, and the processor can pursue the sub-processor under their contract.

Can a Sub-Processor Engage Its Own Sub-Processors?

Yes, if the same authorisation rules are followed down the chain. Each further processor must be bound by the same data protection obligations in contract, and the controller must be able to identify everyone in the chain.

Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.

Ana Mishova

About the Author

Ana Mishova

Sales and Business Development Consultant — GDPRLocal

Ana focuses on helping organisations understand their compliance obligations and find the right data protection solutions. At GDPRLocal she works closely with businesses of all sizes, making GDPR and privacy compliance clear, practical, and accessible.

About the Author

Ana Mishova

Sales & Business Development Consultant

Ana Mishova is a Sales & Business Development Consultant at GDPRLocal, the UK’s fastest-growing B2B compliance partner. With four years at the company, she has experience across operations, from creating processes and shaping compliance services to driving growth through sales, marketing, and strategic partnerships.

Her prior experience includes working closely with current and prospective clients and coordinating with stakeholders to design and plan compliance products. She has led internal change initiatives, driven sales, and guided organisations in selecting the most appropriate compliance strategies.

She holds a degree in psychology, which enhances her ability to connect with people and understand their needs. At GDPRLocal, she works with colleagues to strengthen the sales function and plays an active role in developing the sales strategy.