Skip to main content
DataRidge
Category: Compliance and Monitoring

Subprocessor Register

Also known as: Sub-processor Register, Sub-processor List, List of Data Subprocessors
Simply put

A subprocessor register is a maintained list of the third-party companies that a data processor engages to help handle personal data on behalf of its customers, who are typically the data controllers. It is commonly published or shared so that those customers can see which additional parties are involved in processing their data. The register supports the requirement that a processor generally must not bring in another processor (a subprocessor) without the controller's prior written authorisation.

Formal definition

A subprocessor register is a governance artefact maintained by a data processor that identifies the third-party entities (subprocessors) it engages to process personal data on behalf of, and under the instructions of, the controller. Under the UK GDPR, a processor must not engage a subprocessor without the controller's prior specific or general written authorisation; where general authorisation is used, the register typically functions as the mechanism through which the controller is informed of intended additions or replacements so it may exercise any right to object. The register generally records each subprocessor's identity and the nature or purpose of the processing (for example hosting, email, support, or localisation services). This entry describes the register as an accountability and transparency tool and does not address the specifics of subprocessor contractual flow-down clauses, cross-border transfer mechanisms, retention obligations, or enforcement consequences, and treatment may differ under the EU GDPR and other regimes such as the CCPA/CPRA. Maintaining a register does not by itself establish valid authorisation; demonstrable evidence of the controller's authorisation and of appropriate contractual arrangements is generally required.

Why it matters

A subprocessor register addresses a structural feature of modern data processing: a processor rarely handles personal data entirely on its own infrastructure. It typically relies on a chain of further third parties for hosting, email, customer support, localisation, and similar services. Under the UK GDPR, a processor generally must not engage another processor without the controller's prior specific or general written authorisation, and the register is the practical mechanism through which many processors surface those onward engagements to their controller customers. Without such visibility, a controller cannot meaningfully assess or object to who else is involved in processing data for which it remains accountable.

The register also serves an accountability function. Controllers under governance frameworks generally need demonstrable evidence, not merely stated intent, that onward processing is authorised and appropriately governed. A published or shared register helps a controller track additions and replacements of subprocessors and, where general authorisation is used, exercise any right to object. It is worth stressing that maintaining a register does not by itself establish valid authorisation or compliant contractual arrangements; it is a transparency and record-keeping artefact that supports those obligations rather than substituting for them.

Who it's relevant to

Data processors (vendors and SaaS providers)
Organisations acting as processors that engage further third parties to help handle customer personal data typically maintain and publish a subprocessor register. It supports the requirement that a processor generally must not engage a subprocessor without the controller's prior written authorisation, and it provides a structured way to notify controllers of intended additions or replacements.
Data controllers procuring processing services
Controllers who remain accountable for personal data they entrust to a processor rely on the register to see which additional parties are involved. It helps them assess onward engagements and, under a general authorisation model, exercise any right to object to new or replacement subprocessors.
Data protection officers and privacy governance leads
Those responsible for accountability and record-keeping use the register as evidence that onward processing arrangements are known and, where required, authorised. They should note that the register itself is not proof of valid authorisation; demonstrable evidence of the controller's authorisation and appropriate contractual arrangements is generally required.
Procurement and vendor management teams
Teams evaluating processors can review a supplier's subprocessor register during due diligence to understand the vendor's own supply chain and the nature of processing performed by each subprocessor, informing risk assessment and contract negotiation.

Inside Subprocessor Register

Subprocessor identity and details
A record of each subprocessor engaged, typically including legal entity name, and often the location or country in which processing occurs. This supports transparency toward the controller but does not by itself address the mechanics of cross-border transfers, which are out of scope for the register itself.
Processing activity and purpose
A description of what the subprocessor does and for which processing operation it is engaged. This helps a processor demonstrate accountability by showing that each downstream engagement maps to a defined purpose, though the register is not a substitute for a full records of processing activities obligation.
Contractual and authorization status
An indication that the required contractual terms are in place and that the controller's authorization (whether specific or general) has been obtained. The register tracks status but does not replace the underlying contracts or the flow-down of obligations.
Change tracking and notification history
A log of additions, replacements, or removals of subprocessors over time, often used to support notification of the controller when general authorization is relied upon. The register documents intended changes; it does not itself constitute the notice.

Common questions

Answers to the questions practitioners most commonly ask about Subprocessor Register.

Does maintaining a subprocessor register mean the processor has transferred its obligations to the subprocessors it lists?
No. Listing a subprocessor does not shift the processor's accountability. Under the EU and UK GDPR, a processor that engages another processor generally remains liable to the controller for that subprocessor's performance of its obligations. The register documents the chain of engagement; it does not dilute or reassign responsibility. The processor is typically required to impose the same data protection obligations on its subprocessors by contract, and to demonstrate it has done so, since accountability requires evidence rather than stated intent. This entry does not cover the specific contractual clauses required or how liability is apportioned in any given jurisdiction.
Is a subprocessor register the same thing as a records of processing activities obligation?
No, they are distinct even where their contents overlap. A records of processing activities obligation is a specific documentation duty placed on controllers and processors under the EU and UK GDPR, describing processing operations. A subprocessor register is a narrower artifact focused on the identity, role, and location of downstream processors engaged in the processing chain, generally maintained to support authorization and notification duties toward the controller. One is not a substitute for the other, and neither is inherently satisfied by adopting a particular software tool. This entry does not address the full contents required of any records of processing activities.
What information is typically captured in a subprocessor register?
A subprocessor register generally records the identity of each subprocessor, the processing activity or service it performs, the categories of data involved, the location or region where processing occurs, and the status of the controller's authorization. Many organizations also note the date of engagement and links to the governing contract. The exact fields depend on internal governance decisions and the requirements agreed with controllers; there is no single mandated schema. This entry does not prescribe cross-border transfer mechanics or the safeguards that may apply when a subprocessor operates outside a given jurisdiction.
How should changes to subprocessors be handled once a register exists?
Change handling typically depends on whether the controller granted specific or general authorization for subprocessing. Under a general authorization arrangement, the processor is generally expected to inform the controller of intended additions or replacements of subprocessors and to give the controller an opportunity to object, within the terms agreed in the contract. The register should be updated to reflect additions, removals, and changes in scope, with dated entries to preserve an auditable history. This entry does not specify notification periods or objection procedures, which are set by the applicable agreement and regime.
Who is responsible for keeping the subprocessor register accurate and current?
Ownership sits within the processor organization's governance function, and accuracy is a demonstrable accountability rather than a one-time exercise. In practice, responsibility is often assigned to a data protection or vendor-management role, with input from procurement, legal, and the service teams that engage subprocessors. Effective upkeep requires a defined trigger so that new engagements or changes flow into the register rather than relying on ad hoc updates. This entry does not cover the internal control design or the segregation of duties an organization should adopt to enforce that process.
Does listing a subprocessor in the register satisfy the requirement to authorize it?
Not on its own. The register is a documentation artifact; authorization is a separate substantive step that generally derives from the controller-processor contract, whether through specific approval of a named subprocessor or a general authorization with a notification and objection mechanism. Recording an entry evidences that a subprocessor is engaged, but it does not by itself constitute the controller's consent to that engagement. The register supports, rather than replaces, the authorization process. This entry does not detail the contractual mechanisms by which authorization is obtained in any specific regime.

Common misconceptions

A subprocessor register is the same thing as a records of processing activities obligation.
These are distinct. A records of processing activities obligation, where it applies, covers a party's own processing operations under the applicable regime and follows its own requirements. A subprocessor register is a narrower operational record of downstream engagements. Maintaining one does not automatically satisfy the other, and neither should be equated with any particular data inventory tool.
Maintaining a subprocessor register makes the processor compliant with its downstream obligations.
The register is evidence supporting accountability, not a guarantee of compliance. Under governance and data protection frameworks generally, accountability requires demonstrable evidence such as contracts, authorizations, and controls, not merely a maintained list. Compliance depends on context, jurisdiction, and implementation.
The register itself handles controller authorization and change approvals.
A register documents status and history but does not create authorization. Whether specific or general authorization is required, and how objections or notifications are handled, is typically governed by the controller-processor contract and the applicable regime, which differ across the EU GDPR, the UK GDPR, and other frameworks.

Best practices

Keep the register current by updating it whenever a subprocessor is added, replaced, or removed, and treat these updates as triggers to check contractual and authorization requirements rather than as the notification itself.
Record enough detail per entry (entity, processing activity, location, and authorization status) to demonstrate accountability, while recognizing that the register does not address cross-border transfer mechanics, retention rules, or enforcement matters.
Align the register with the underlying controller-processor contracts so that each listed subprocessor is backed by appropriate flow-down of obligations and a documented authorization basis.
Do not treat the register as a substitute for any applicable records of processing activities obligation or for a full data inventory; maintain those separately according to the relevant regime.
Retain change history so the processor can evidence when and how the controller was informed of subprocessor changes under general authorization arrangements.
Periodically review entries against actual engagements to confirm the register reflects reality, since accountability requires demonstrable evidence rather than stated intent.