Promotional banner for the pentest readiness checklist

Category: Third-Party & Vendor

Sub-Processor

Also known as: Subprocessor, Sub-processor, Downstream processor

Simply put

A sub-processor is a third party that a data processor brings in to help carry out part of the work of handling personal data on behalf of the original organization (the controller). For example, if a company hires a service provider to process personal data, and that provider in turn uses a cloud vendor to do part of the job, the cloud vendor is acting as a sub-processor. Under the UK GDPR, a processor generally cannot engage a sub-processor without the controller's prior written authorization.

Formal definition

Under the EU and UK GDPR frameworks, a sub-processor is a processor engaged by another (primary) processor to carry out specific processing activities in connection with the controller's personal data. The sub-processor processes personal data on behalf of, and under the instructions passed down from, the primary processor, which itself acts on the controller's documented instructions. Per ICO guidance implementing the UK GDPR, a processor generally must not engage a sub-processor without the controller's prior specific or general written authorisation, and equivalent data protection obligations are typically required to be flowed down through contractual arrangements. A sub-processor is distinct from a controller (which determines the purposes and means of processing) and from the primary processor (with which the controller contracts directly). Note that the precise authorisation, flow-down, and liability requirements are set out in the applicable data protection law and contracts, and may differ across jurisdictions; readers should verify obligations against the current authoritative text and their specific contractual terms.

Why it matters

Sub-processors matter because most modern data processing arrangements involve chains of vendors rather than a single provider. When a controller contracts a processor, that processor often relies on downstream vendors — cloud infrastructure, support tools, analytics services — each of which may touch the controller's personal data. Under the EU and UK GDPR frameworks, the controller remains accountable for the processing even where it occurs several links down the chain, so understanding where sub-processors sit is central to managing accountability and risk.

The practical significance lies in authorisation and control. Per ICO guidance implementing the UK GDPR, a processor generally must not engage a sub-processor without the controller's prior specific or general written authorisation. Where general authorisation is used, the controller typically retains the right to be informed of intended changes and to object. This means organisations cannot silently extend their processing chain; each new downstream vendor is a point where equivalent data protection obligations must be flowed down through contract, and where a gap in those obligations can expose the controller to compliance risk.

Because obligations depend on the applicable law and the specific contractual terms in place, the sub-processor relationship is fact-specific. Authorisation mechanics, flow-down requirements, and liability allocation can differ across jurisdictions and between individual contracts, and enforcement practice may diverge from the bare text of the law. Readers should treat sub-processor management as an ongoing governance activity rather than a one-time contractual step, and verify their obligations against the current authoritative text and their own agreements.

Who it's relevant to

Data Protection Officers and Privacy Teams

DPOs and privacy teams need to map processing chains to know which third parties act as sub-processors and whether the required authorisations are in place. They are typically responsible for tracking notice-and-objection rights under general authorisation arrangements and confirming that equivalent obligations have been flowed down. The specifics depend on the organisation's contracts and applicable law.

Processors and Service Providers

Organisations acting as processors must understand that they generally cannot engage a sub-processor without the controller's prior specific or general written authorisation under the UK GDPR. They are usually responsible for imposing equivalent data protection obligations on any sub-processor by contract, and should verify the applicable requirements against the current authoritative text and their controller agreements.

Controllers Procuring Services

Controllers remain accountable for processing carried out down the chain, so they have an interest in knowing which sub-processors their processors rely on. They typically negotiate authorisation mechanisms — specific or general — and, where general authorisation applies, may retain rights to be informed of changes and to object. Application to a given arrangement turns on the specific contract terms.

Legal Counsel and Contract Managers

Those drafting and reviewing data processing agreements handle the authorisation clauses, flow-down provisions, and liability allocation that govern sub-processor relationships. Because these requirements are set by the applicable data protection law and the contracts themselves and can differ across jurisdictions, counsel should confirm terms against current authoritative sources rather than relying on standard templates alone.

Auditors and Assessors

Auditors and assessors examining a processing arrangement often need to trace the sub-processor chain and verify that authorisation and flow-down requirements have been met. This is an assessment of the arrangement's alignment with stated obligations and contract terms rather than a legal determination, and findings depend on the specific facts and documentation reviewed.

Inside Sub-Processor

Sub-Processor Definition

A third party engaged by a processor to carry out specific processing activities on behalf of, and under the instructions of, a controller. The sub-processor sits downstream of the processor in the data processing chain and does not have a direct contractual relationship with the controller in most cases.

Chain of Processing

Sub-processing extends the controller-to-processor relationship to a further layer. The processor remains accountable to the controller for the sub-processor's compliance, and contractual obligations generally must flow down through the chain.

Authorization Requirement

Under the GDPR, a processor generally may not engage a sub-processor without the controller's prior authorization, which may be specific or general. Where general authorization is given, the processor is typically required to inform the controller of intended changes so the controller can object.

Flow-Down Contractual Obligations

The data protection obligations imposed on the processor are generally required to be imposed on the sub-processor through a written contract, so that equivalent protections apply throughout the chain.

Continuing Liability

Where a sub-processor fails to meet its data protection obligations, the initial processor generally remains fully liable to the controller for the performance of that sub-processor's obligations.

Common questions

Answers to the questions practitioners most commonly ask about Sub-Processor.

Does appointing a sub-processor transfer the primary processor's compliance responsibility away from it?

No. Engaging a sub-processor does not discharge the original processor's obligations. In most cases, the processor that engages another processor remains liable to the controller for the sub-processor's performance of its data protection duties. The chain of accountability is generally intended to flow through each party rather than shift entirely downstream. The precise allocation of liability depends on the governing contract and applicable law, so readers should verify against the relevant agreement and the current authoritative text.

Is a sub-processor the same thing as a separate controller, or does it hold controller-level obligations?

No, these roles should be kept distinct. A sub-processor is a processor engaged by another processor and, like any processor, generally acts on documented instructions rather than determining the purposes and means of processing. A controller, by contrast, decides why and how personal data is processed. Characterising a sub-processor as a controller would misstate the role and the obligations that attach to it. Where a party begins to determine purposes and means, its classification may change, and that assessment is fact-specific.

What authorisation is typically needed from the controller before engaging a sub-processor?

Arrangements vary, but a processor generally needs some form of controller authorisation before engaging a sub-processor. This may take the form of specific prior authorisation for a named sub-processor, or general written authorisation subject to notice of intended changes and an opportunity for the controller to object. The applicable mechanism depends on the data processing agreement and the requirements of the relevant jurisdiction, so the specific terms should be confirmed against the governing contract and current official sources.

How should the terms imposed on a sub-processor relate to the original controller-processor agreement?

As a general practice, the processor is expected to impose on the sub-processor data protection obligations that are consistent with those it owes the controller, so that protections are not diluted down the chain. This is commonly described as flowing down equivalent terms through a back-to-back contractual arrangement. The exact obligations that must be replicated depend on the applicable legal regime and the parent agreement, and application to particular circumstances requires professional judgment.

What records or documentation are commonly maintained regarding sub-processors?

Organisations often maintain a list or register of sub-processors, together with the written agreements governing each engagement and records of the authorisations or notices exchanged with the controller. Such documentation can support demonstrating accountability across the processing chain. The specific record-keeping expectations differ by jurisdiction, sector, and contract, and this entry does not prescribe a fixed format; verify requirements against the applicable rules and agreements.

How are changes to sub-processors typically handled during an ongoing engagement?

Where general authorisation is used, changes such as adding or replacing a sub-processor are commonly handled by notifying the controller in advance and allowing time to raise objections, according to the process set out in the data processing agreement. The consequences of an unresolved objection are usually addressed contractually. Because these procedures are contract- and jurisdiction-dependent and enforcement practice can evolve, the governing agreement and current authoritative sources should be consulted rather than assuming a universal approach.

Common misconceptions

A sub-processor has a direct legal relationship with the controller.

In most cases the sub-processor is engaged by and contracts with the processor, not the controller. The processor generally remains accountable to the controller for the sub-processor's compliance, rather than the controller and sub-processor being directly bound to one another.

A processor can freely appoint sub-processors as it sees fit.

Under the GDPR, engaging a sub-processor generally requires the controller's prior authorization, whether specific or general. Where general authorization applies, the processor is typically obliged to notify the controller of changes and allow an opportunity to object. Requirements may differ in other jurisdictions and should be verified against the applicable text.

Once processing is delegated to a sub-processor, the processor is no longer responsible for it.

Delegation does not transfer accountability. The initial processor generally remains fully liable to the controller for the sub-processor's performance of data protection obligations.

Best practices

Maintain an up-to-date inventory of all sub-processors in the processing chain, including the activities each performs and the data categories involved.

Confirm the basis of authorization (specific or general) with the controller and implement a documented process for notifying controllers of intended sub-processor changes and handling objections.

Ensure written contracts with sub-processors impose data protection obligations equivalent to those the processor owes the controller, so protections flow down through the chain.

Recognize that liability for a sub-processor's failures generally remains with the engaging processor, and factor this into due diligence and ongoing oversight.

Periodically review sub-processor arrangements and their contractual terms, as regulatory requirements are subject to amendment and enforcement practice may evolve.

Verify applicable obligations against the current official regulatory text for the relevant jurisdiction, as sub-processing requirements differ across the EU, the United States, the United Kingdom, and elsewhere, and seek professional judgment for specific circumstances.