VND-003 Sub-Processor Management
Description
A current register of all sub-processors (vendors who process personal data on behalf of the organisation as a processor) is maintained. Customers are notified of intended sub-processor changes with sufficient notice to object. Sub-processors are bound by data processing obligations equivalent to those owed to the controller. Sub-processors are subject to due diligence before engagement.
Rationale
Uncontrolled sub-processing chains are a material GDPR risk and a customer trust issue. A provider acting as a processor discloses and controls its sub-processor chain. The register here is the GDPR Art. 28 chain: the sub-processors that touch personal data, the notice a customer receives and the objection it can raise. The ICT subcontractors behind a customer-facing service, the hold on a subcontracting change until the customer has had its say and the contractual flow-down to every party in the chain are VND-015, which a customer under DORA, NIS2 or HIPAA reads alongside this control rather than instead of it.
Applicability (9 profiles)
The deployer is the controller: it obtains the provider's sub-processor register and objection route under VND-002. Where the deployer is itself a processor for its own customers, the register is its own.
The deployer is the controller: it obtains the provider's sub-processor register and objection route under VND-002. Where the deployer is itself a processor for its own customers, the register is its own.
This row keeps only the GDPR Art. 28 register of personal-data sub-processors. Since S8 wave B the chain DORA actually reaches, every subcontractor underpinning a critical or important function, the RTS 2025/532 Art. 5 hold on a change until the customer approves or the notice period lapses and the ITS 2024/2956 Art. 3(6) legal entity identifier per subcontractor, are VND-015.
164.308(b)(2) runs the flow-down down the whole chain: a subcontractor of a subcontractor is itself a business associate and owes the same duty onward. The sub-processor register has to reach that far.
Framework Mappings (14)
| DSP-13 | Personal Data Sub-processing | full |
| DSP-14 | Disclosure of Data Sub-processors | full |
| DSP-13 | Personal Data Sub-processing | full |
| DSP-14 | Disclosure of Data Sub-processors | full |
| DORA-Art.30.2.a | Description of functions and ICT services, and subcontracting permission | partial |
| DORA-ITS-2024/2956-Art.3 | Register of information templates and data quality | informative |
| GDPR-Art.28.2 | Sub-processor Authorisation and Control | full |
| GDPR-Art.29 | Processing Under Controller Authority | partial |
| HIPAA-164.308.b.2 | Subcontractor Assurances | full |
| HIPAA-164.308.b.3 | Written Contract or Other Arrangement | informative |
| HIPAA-164.314.a.2.i.B | Business Associate Contract Subcontractor Term | full |
| HIPAA-164.314.a.2.iii | Business Associate Contracts with Subcontractors | full |
| A.10.2 | Allocating responsibilities | partial |
| NIS2-CIR-5.2 | Directory of Suppliers and Service Providers | informative |
Evidence (2)
Current sub-processor register listing all third parties who process personal data on behalf of the organisation in its role as a data processor.
Example: Published sub-processor list (company trust page or customer-facing documentation) and internal sub-processor register, listing each sub-processor with: name, role, data categories processed, processing location, DPA status, and notification sent date for any additions in the last 12 months
Test: Request the sub-processor register. Verify: (1) a complete and current list exists covering all vendors who handle personal data in a processing capacity, (2) processing location and data categories are documented for each, (3) a DPA is in place with every listed sub-processor, (4) the list is published or made available to customers, (5) addition notifications to customers are evidenced for any sub-processors added in the last 12 months.
Sub-processor agreements or DPA flow-down documentation confirming that sub-processors are bound by equivalent data protection obligations.
Example: Executed DPAs between the organisation and its sub-processors (e.g. AWS DPA, Stripe DPA), demonstrating that processing obligations from the controller's DPA are flowed down, including: processing instructions, data subject rights assistance, deletion obligations, security requirements, and prohibition on further sub-processing without approval
Test: Request DPAs for the top 5 sub-processors. Verify: (1) DPA obligations are materially equivalent to those imposed on the organisation by its customers, (2) sub-processors are prohibited from further sub-processing without the organisation's written consent, (3) deletion/return of data obligations are included, (4) DPAs are signed and current.
Questions (3)
Does your organisation maintain a current register of all sub-processors?
The sub-processor register should be publicly accessible or available to customers on request. Customer notification of sub-processor changes must occur with sufficient notice for the customer to object.
How does your organisation manage changes to the sub-processor list?
Advance notification with a right to object is the standard expected by enterprise customers and is required under GDPR Art.28.2. A published list without proactive notification is a weaker but common approach. The customer should confirm whether this satisfies their contractual requirements.
Are sub-processors bound by data protection obligations equivalent to those you owe the controller?
Answer yes only where the flow-down is in the executed agreement with each sub-processor rather than asserted in your own privacy documentation. A sub-processor engaged on its own standard terms usually is not so bound.