Skip to main content
Bureau of AI
Category: Third-Party & Supply Chain

Sub-Processor

Also known as: Subprocessor, Sub-processor
Simply put

A sub-processor is a third-party vendor that a data processor brings in to help handle personal data while providing services to another organization. For example, if a company processes personal data on behalf of its customers and then hires an outside service to help with part of that work, that outside service is a sub-processor. Under the GDPR, a processor typically cannot engage a sub-processor without the controller's prior written authorization.

Formal definition

In the context of the GDPR and UK GDPR, a sub-processor is a third-party data processor engaged by a primary data processor that has, or will have, access to or processes personal data originating from a data controller. The engagement of a sub-processor is subject to the controller's prior specific or general written authorization, as reflected in ICO guidance. This entry is scoped to data protection processing roles and does not address the distinct governance and model risk management concepts used in AI oversight; sub-processor obligations arise from data protection law rather than from model risk frameworks, and the specific contractual and authorization requirements may vary by jurisdiction and by the terms of the underlying data processing agreement.

Why it matters

The sub-processor concept matters because responsibility for personal data does not end at the first vendor in a chain. When a processor engages another party to help deliver its services, personal data can move further away from the controller who remains accountable for it. Under the GDPR and UK GDPR, this is why a processor typically cannot bring in a sub-processor without the controller's prior authorization, whether specific or general, as reflected in ICO guidance. The requirement gives the controller visibility and a degree of control over who ultimately handles data collected under its responsibility.

For compliance and privacy professionals, sub-processor arrangements are a common source of gaps between contractual promises and operational reality. A data processing agreement may commit a processor to specific safeguards, but if a downstream sub-processor is engaged without proper authorization or without equivalent obligations flowing down, the controller can lose assurance over how its data is protected. Maintaining an accurate, current list of sub-processors and honoring notification and objection mechanisms are therefore practical control points that map directly to the written authorization requirement.

This entry is scoped to data protection processing roles under the GDPR and UK GDPR and does not address AI governance or model risk management concepts. Sub-processor obligations arise from data protection law rather than from model risk frameworks, and the specific contractual and authorization requirements vary by jurisdiction and by the terms of the underlying data processing agreement. Readers should treat the precise mechanics of authorization and notification as dependent on the applicable law and the agreement in force rather than as a single universal standard.

Who it's relevant to

Privacy and data protection officers
DPOs and privacy leads use the sub-processor concept to assess whether downstream vendors are properly authorized and whether equivalent data protection obligations flow down the processing chain. They are often responsible for reviewing sub-processor lists and ensuring notification and objection mechanisms operate as the data processing agreement requires.
Vendor risk and procurement teams
Teams evaluating vendors need to identify when a service provider will itself rely on further third parties that handle personal data, since those are sub-processors requiring controller authorization. This informs due diligence, contract terms, and ongoing monitoring of who ultimately processes data collected under the organization's responsibility.
Legal and contracts professionals
Legal teams draft and negotiate the authorization language in data processing agreements, including whether the controller grants specific or general authorization and what notice and objection rights apply. Because the ICO frames these obligations under the GDPR and UK GDPR, and terms vary by jurisdiction and agreement, precise drafting is central to allocating responsibility across the processing chain.
Compliance officers and auditors
Compliance and audit functions test whether sub-processor engagements match the authorizations on record and whether the organization maintains an accurate, current list of sub-processors. This is a practical control point for demonstrating that personal data handled by downstream vendors remains subject to appropriate obligations.

Inside Sub-Processor

Sub-Processor
An entity engaged by a processor (or service provider) to carry out specific processing activities on personal data on behalf of, and under the instructions traceable back to, the controller. In AI supply chains this often includes cloud infrastructure providers, model hosting vendors, or third-party API providers that handle data during model training, inference, or monitoring.
Chain of Accountability
The contractual and organizational linkage that flows obligations from controller to processor to sub-processor, so that data protection commitments (such as those commonly required under data processing agreements) are passed down the chain. This is a governance construct rather than a model risk measurement construct.
Authorization Mechanism
The arrangement by which a controller permits a processor to engage sub-processors, typically through general or specific written authorization, often accompanied by notice-and-objection provisions. The exact requirements depend on the applicable legal framework and the terms of the underlying agreement.
Flow-Down Obligations
The requirement, common in many data processing agreements, that a processor imposes on its sub-processors data protection terms materially equivalent to those the processor itself owes the controller.
Due Diligence and Oversight
The assessment and ongoing monitoring a processor is typically expected to perform when selecting and managing sub-processors, including evaluation of technical and organizational safeguards. This overlaps with third-party risk management but is scoped to data processing activities.

Common questions

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

Is a sub-processor the same thing as a processor?
No. In common data protection usage, a processor handles personal data on behalf of a controller, while a sub-processor is engaged by the processor to carry out some of that processing. The distinction matters because it affects the chain of contractual obligations and accountability: the processor typically remains responsible to the controller for the sub-processor's performance, even though the sub-processor sits further down the chain. Treating the two as interchangeable can obscure who owes what obligation to whom.
Does using a sub-processor transfer or reduce the original processor's responsibility?
Generally not. Engaging a sub-processor does not, by itself, relieve the processor of its obligations. In many data protection frameworks the processor remains accountable to the controller for the sub-processor's acts, and the arrangement is typically expected to flow equivalent obligations down through contract. The precise allocation depends on the governing law and the terms agreed, so this description should not be read as a statement of the requirements in any particular jurisdiction.
What contractual terms are typically expected when engaging a sub-processor?
In many arrangements the processor is expected to impose on the sub-processor obligations equivalent to those the processor owes the controller, often through a written agreement or flow-down clauses. Common elements include scope and purpose limits, confidentiality, security measures, assistance with data subject requests, and audit or oversight provisions. The specific terms required depend on the applicable legal framework and the underlying controller-processor agreement, so verify against those sources rather than assuming a fixed template.
How is controller authorization for sub-processors usually handled?
Authorization is commonly structured as either specific (approval of a named sub-processor) or general (prior authorization subject to notice of changes and a right to object). Which approach applies, and the notice and objection mechanics, depend on the governing agreement and law. Organizations typically maintain a current list of sub-processors and a defined change-notification process, but the exact obligations should be confirmed against the applicable framework rather than assumed.
How should sub-processors be tracked and documented in practice?
A common practice is to maintain an up-to-date register or list identifying each sub-processor, the processing activities it performs, its location, and the contractual basis for the engagement. This supports transparency to the controller, change notifications, and audit readiness. The register also helps map the processing chain when responding to data subject requests or incidents. Documentation expectations vary by framework and contract, so align the register's contents with those requirements.
What role does oversight of sub-processors play in ongoing risk management?
Sub-processor oversight is typically part of ongoing third-party or vendor risk management, and can include initial due diligence, contractual controls, periodic review, and audit or reporting rights. Such measures are intended to reduce and manage risk associated with the extended processing chain rather than eliminate it. The depth of oversight often reflects the sensitivity of the data and the applicable obligations, and should be scoped to those factors rather than applied uniformly.

Common misconceptions

Engaging a sub-processor transfers the processor's responsibility to that sub-processor.
In many frameworks the processor typically remains responsible to the controller for the sub-processor's performance of the relevant obligations; delegating the activity does not automatically delegate the accountability.
A sub-processor and a model vendor or AI supplier are the same thing.
A vendor becomes a sub-processor only where it processes personal data on behalf of the processor. A supplier that provides a model or tool without processing personal data on the processor's behalf may not meet the definition. The classification depends on the actual data-handling role, not the commercial label.
Sub-processor governance is part of model risk management.
Sub-processor arrangements are primarily a data protection and AI governance concern (organizational accountability, contracts, oversight) rather than a model risk management activity focused on identifying, measuring, and controlling risks arising from model outputs. The two areas can overlap in third-party AI use but should not be conflated.

Best practices

Maintain an up-to-date inventory of sub-processors involved in AI systems, identifying which processing activity each supports and what categories of data they handle.
Confirm the basis of authorization (general or specific) for each sub-processor and implement any notice-and-objection procedures required by the underlying agreement.
Ensure flow-down provisions impose data protection terms on sub-processors that are materially equivalent to those owed to the controller.
Conduct proportionate due diligence on a sub-processor's technical and organizational safeguards before engagement, and reassess on a periodic basis.
Clarify the classification of AI vendors by evaluating their actual data-handling role, rather than relying on the commercial label, to determine whether sub-processor obligations apply.
Document oversight activities so the chain of accountability from controller through processor to sub-processor remains demonstrable, recognizing that these controls reduce rather than eliminate risk.