How do GDPR sub-processor rules apply when a customer requires a sub-processor list?
When an enterprise customer asks for your sub-processor list and authorisation terms, the rule behind the request is Article 28(2): a processor may not engage a sub-processor without the controller's prior specific or general written authorisation. The controller must also be able to name every processor and sub-processor at all times, including the name, address and contact person for each. Your contract and your list therefore have to answer the same questions the customer will ask, before the first sub-processor is added, not after the customer discovers one.
Your organization owns the processor contracts, the sub-processor list and the decision about what to disclose and how to offer authorisation. DeployOpen can help prepare the technical side, such as documenting where each hosted component runs, which accounts and regions hold data, and what evidence shows each sub-processor was bound by the same obligations. DeployOpen does not draft legal terms as a substitute for your counsel, and only an independent auditor or certification body issues any report on these controls. Confirm the exact notice and objection mechanics with your legal team and the wording in your own customer agreements.
Three factors change the answer. The first is the number of sub-processors, since a long list raises the cost of keeping per-customer notices accurate and the chance of a stale entry. The second is whether the customer has agreed to specific or general authorisation: under general authorisation you must give advance notice of changes so the controller can object, and the objection process itself needs an owner and a timeline. The third is location. If a sub-processor is outside the EEA, or if support staff in a third country can view data remotely, the EDPB treats that access as a transfer, so the transfer checks under Chapter V must be recorded alongside the list.
Who is paid for sub-processor management and what recurs
This table compares the cost components of keeping a GDPR sub-processor list and its contracts current, showing who is paid for each, whether the cost is one-time or recurring, and what pushes it up. Read it to decide which parts to keep in-house and which to scope into an outside engagement with a written quote. No fees or durations are stated because none are supplied for this topic.
| Cost component | Who is paid | One-time or recurring | What drives it up |
|---|---|---|---|
| Contract terms for sub-processors | Internal legal and procurement staff, or outside counsel | One-time per sub-processor, then recurring when terms change | Number of sub-processors and how many need custom transfer or flow-down terms |
| Flow-down of Article 28 obligations | Internal legal, with counsel review if terms are negotiated | One-time per sub-processor, recurring on renewal | Gaps between your processor terms and each vendor's standard terms |
| Maintaining the sub-processor list | Engineering or operations staff who keep the inventory of name, address and contact person current | Recurring | Frequency of vendor changes, number of hosting regions and tools that touch customer data |
| Change notice and objection handling | Privacy lead or DPO, plus account and sales staff who answer customer objections | Recurring, spikes at each change notice | Number of customers on specific authorisation and notice periods that differ by contract |
| Privacy lead or DPO review | Internal DPO, or an outsourced DPO if the role is contracted | Recurring review, plus one-time review of new vendors | Volume of new vendors, sensitivity of data each one receives, and transfer questions |
| Transfer checks for third-country sub-processors | Privacy lead, legal, and sometimes engineering for remote access mapping | One-time per sub-processor, recurring when transfer mechanisms or vendor locations change | Remote support access from outside the EEA and cloud storage outside the EEA |
| Outside implementation partner or counsel | External partner or law firm, under a written scope | Usually one-time for setup, optional recurring for upkeep | Size of the initial inventory, backlog of contracts to review, and whether systems need technical changes to track sub-processors |
What makes sub-processor management harder for your organization
Sub-processor work gets harder as the chain grows, vendors change, and customers ask for more control. Each driver below changes how much work your team carries and how quickly you can answer a customer or regulator, so each one needs a deliberate control rather than an ad hoc process.
Size of the sub-processor chain
Every hosting provider, support tool, monitoring service and analytics vendor that touches customer personal data is a sub-processor under Article 28. Count them by data flow, not by contract, because a single platform often hides several downstream providers. Ask each supplier to disclose its own sub-processors and record them in one register with a named owner. Check the chain at least once a year, since a long chain multiplies the number of notices you must send and objections you must handle.
Frequency of vendor changes
Each time a sub-processor is added or replaced, you may need to inform customers in time for them to object, under general authorisation. A fast release cycle or a vendor that reorganises its hosting can create several changes a quarter. Set a change workflow that triggers the notice, starts the objection window, and records the decision. Ask vendors for advance notice of their own changes so the window is not shortened by surprise.
Customer requirement for specific authorisation
Some customers insist on specific prior written authorisation for each sub-processor, which gives them a veto before any engagement. Under general authorisation, you only give notice and allow objection. Identify which contracts carry each model before you change a vendor, because a single change may need a separate sign-off for each customer. Keep a per-customer view of the authorisation model so you do not breach a contract by mistake.
Sub-processors outside the EEA
A sub-processor located in a third country, or storing data in a cloud region outside the EEA, makes the flow a transfer that needs its own analysis. Check the transfer mechanism, such as an adequacy decision or the standard contractual clauses in Decision (EU) 2021/914, before onboarding. Record the country of each storage location and processing location separately, since they can differ. Confirm the current status of any adequacy decision with the Commission before relying on it.
Support access from third countries
Remote access from outside the EEA counts as a transfer even when a support engineer only views data to troubleshoot. This often surprises teams because no copy of the data leaves the EEA. List every vendor support desk, follow-the-sun rota and administrator location, and ask each sub-processor to confirm where its staff access production systems. Restrict privileged access to named roles and log each session so you can answer a customer's question about who saw their data.
Maturity of the inventory
A sub-processor list is only useful if it names each processor and sub-processor with a name, address and contact person, and you can produce it at short notice. EDPB Opinion 22/2024 says controllers should have this identity information available at all times. Test the inventory by asking someone outside the compliance team to produce it for one customer within a set time. Gaps in the register, stale contacts and missing country data are the first things a customer audit will find.
When a sub-processor outside the EEA triggers a transfer check
A sub-processor located outside the European Economic Area can turn an ordinary vendor addition into a transfer that needs its own check. According to EDPB Opinion 22/2024, remote access from a third country counts as a transfer even when the sub-processor only views data for support or administration, and so does storage in a cloud region outside the EEA offered by a service provider. Your sub-processor list should therefore record not just the entity name and contact person but also where each sub-processor stores data and where its support staff can reach it from. An engineer in another country opening a production database for troubleshooting is a data flow you need to document, not a detail to leave to the support contract.
Once a third-country location is confirmed, the transfer rules in Chapter V apply in addition to Article 28. Where the processor sits in a third country, the controller-to-processor and processor-to-processor modules of the standard contractual clauses in Commission Implementing Decision (EU) 2021/914 set out the Article 28(3) and (4) rights and obligations, so they can serve as the contractual layer for the chain. Confirm with your processor which module applies to each link, whether the sub-processor agreement reproduces the flow-down terms, and whether a transfer impact assessment has been completed for the destination. The controller remains responsible for these choices when it contracts, so the decision should be recorded before the new sub-processor receives any personal data.
The EU-US Data Privacy Framework, set out in Commission Implementing Decision (EU) 2023/1795, may cover transfers to certified US organizations, but it is not a permanent answer. Case C-703/25 P, *Latombe v Commission*, is an appeal against the General Court's ruling on that adequacy decision, and it is still pending. Treat the Framework as a route to check, not a settled basis: confirm the recipient's current certification status, track the appeal, and have counsel confirm whether the Framework or the standard contractual clauses should be the documented mechanism. Ask your processor to state the transfer basis for every third-country sub-processor in writing, and to notify you if that basis changes.
What the sub-processor list must show before a customer asks
A controller can be held to account for sub-processors it cannot name, so the list is a working record, not a marketing page. Each card below covers one item the processor should hold for every sub-processor and the check that proves it is current.
Legal identity and contact details
EDPB Opinion 22/2024 says the controller should have the name, address and contact person of every processor and sub-processor available at all times. Keep the registered legal name, the registered address and a named contact who can answer a customer question within the working day. Check each entry against the sub-processor's current company register record and confirm the contact still works, because stale contacts are the most common gap found when a customer asks.
Processing activities performed
For each sub-processor, state the specific processing it carries out, such as hosting database backups, sending transactional email or running support ticketing. A bare vendor name does not let a controller judge whether the sub-processor should see the data at all. Check that each description matches the sub-processor's actual role in your data flows, and that the categories of personal data it handles are stated alongside it.
Processing locations and access points
Record where data is stored and where it is processed, and separately where staff or support tools can view it. Remote access from a third country, even only to view data for support or administration, counts as a transfer under the EDPB guidance, so a record that shows only the storage region is incomplete. Confirm the location with the sub-processor's data residency documentation and ask for every country from which support access can occur.
Contract status and flow-down
Article 28(4) requires the processor to impose the same data protection obligations on each sub-processor. Record whether a written sub-processing contract is in place and when it was last reviewed. The EDPB notes controllers need not routinely request these contracts, but they should be able to show the flow-down exists if challenged. Ask the processor to confirm in writing that the obligations match the controller's agreement, and keep that confirmation with the list.
Transfer basis where relevant
Where a sub-processor is outside the EEA, or its access points are, record the transfer mechanism: an adequacy decision, the EU-US Data Privacy Framework, or standard contractual clauses under Decision (EU) 2021/914 with supplementary measures where needed. The clauses' controller-to-processor and processor-to-processor modules also carry the Article 28 duties down the chain. Check that the mechanism is valid on the date you review it, not only when the vendor was first added.
Version history and change notices
Keep a dated history of additions, removals and changes to each entry, because Article 28(2) requires notice of intended changes under general authorisation so the controller can object. Record the notice date, the objection window offered and the decision taken. Check that each change in the live list has a matching notice on file, so you can show when a sub-processor was engaged and what the controller knew at that time.
Why the controller keeps the final decision on each sub-processor
The final decision on engaging a sub-processor stays with the controller. EDPB Opinion 22/2024, adopted in October 2024, says controllers should have the identity of every processor and sub-processor available at all times, meaning the name, address and contact person. That makes the processor's sub-processor list an input to the controller's decision, not a notice the controller can ignore. A processor that adds a sub-processor without giving the controller a real chance to object, or that presents a list the controller cannot act on, leaves the controller unable to show it made the decision itself.
The same guidance makes the controller responsible for data protection by design and by default across the processing chain, including by its processors and sub-processors, and says this should be taken into account when contracting. In practice, a controller reviewing a new sub-processor will ask what that party can see, where data is stored, and whether remote support from outside the EEA is possible. The processor should give those answers in the list itself. Confirm with each processor whether its list shows the sub-processor's role, data categories and hosting location, not only a company name.
Article 30(2) requires each processor to keep a record of the categories of processing carried out for each controller, any third-country transfers and, where possible, a general description of its security measures. This record is the internal source behind the list. Before you sign, ask the processor to show the record, or a summary of it, for your account and to confirm that the list is generated from the same source. Ask how the list is versioned, how changes are sent to you, and how long you have to object under the contract. Those answers tell you whether the controller can name every party handling its data at any time.
Questions processors ask about sub-processor management
Is a sub-processor list alone enough to meet GDPR Article 28?
No. A list of names is a starting point, not the whole obligation. Under Article 28, you need the controller's prior written authorisation before you engage a sub-processor, you must flow the same data protection obligations down by contract, and you must keep records of your processing. The EDPB's Opinion 22/2024 says controllers should be able to see the name, address and contact person of every processor and sub-processor at all times, and that the final decision on engaging a sub-processor stays with the controller. So the list supports the contract and the authorisation process rather than replacing them.
Do I need specific or general authorisation for sub-processors?
Either can be lawful, but the choice is the controller's to make in the contract. Under specific authorisation, the controller approves each named sub-processor before it is used. Under general authorisation, the controller agrees in advance that you may add sub-processors, provided you inform it of intended changes so it has the chance to object. Most enterprise customers accept general authorisation with a notice mechanism, but they expect the mechanism to work in practice. Confirm the customer's preference during contracting and record it in the processing agreement.
How long should the notice and objection period be for new sub-processors?
The GDPR does not set a number of days, so the period must be agreed in the contract with each controller. Article 28(2) requires you to inform the controller of intended changes so it can object, which means the period has to be long enough for a real objection and for the controller to decide what to do if it objects. Agree the period, the channel used for notices, what happens if the controller objects, and whether it may terminate the affected services. Ask each customer to confirm its period in writing, because enterprise buyers often negotiate it and a single standard term may not fit every contract.
Does a US cloud host used as a sub-processor need a transfer check?
Usually yes, if personal data is accessible from or stored outside the EEA. The EDPB's guidelines treat remote access from a third country, even just viewing data for support or administration, and storage in a cloud outside the EEA as transfers. For a US provider, check whether the provider is covered by the EU-US Data Privacy Framework under Commission Implementing Decision (EU) 2023/1795. Where it is not, or where you rely on the fallback, the standard contractual clauses in Decision (EU) 2021/914 set out the processor-to-processor terms and supplementary measures may be needed. Note that the Data Privacy Framework is subject to a pending court appeal, so confirm its status when you assess the transfer.
How much internal effort does maintaining a sub-processor list take?
The one-time effort is mapping every service, hosting location, support access path and downstream provider that touches customer data, then agreeing each entry's name, address and contact. The recurring effort is keeping that map current: every new vendor, region change, support tool or remote access route triggers a notice cycle and a list update. The main cost drivers are the number of providers, how often they change, how many customers have specific authorisation, and whether the list is generated from systems of record or maintained by hand. Ask for the effort in writing during scoping, split into mapping, list maintenance and notice handling.
Can we manage sub-processor obligations ourselves?
Yes, many processors do. It is most manageable when the service is small, the provider count is low and the team owns the contracts, the data flows and the notice process. It becomes harder when many customers negotiate different authorisation terms, when infrastructure changes often, or when remote administration crosses borders. Whichever route you take, the decisions and the accountability stay with your organization. Confirm that someone owns the list, the notice workflow and the transfer assessments, and that the list can be produced for any customer on request.
What can outside help cover for sub-processor management?
An implementation partner such as DeployOpen can prepare the technical side for an engagement that is fixed in scope and agreed in writing. This can include mapping the data flows of self-hosted open-source platforms running in your own cloud accounts or data centers, documenting where each component stores and accesses data, and preparing the records and evidence customers ask for. It does not cover the legal decisions. Your counsel and your organization still set the contract terms, choose the authorisation model and decide on transfer mechanisms. Only an independent auditor or certification body issues assessment reports or certificates. Ask any partner to state in the scope what it will and will not produce.
What to confirm with counsel, customers and your environment
Start with the items that can change under you. The GDPR text has not been amended as of October 2026, but the Omnibus IV proposal (procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 that still awaits Parliament's first-reading vote, and the Digital Omnibus proposal (procedure 2025/0360(COD)) is awaiting committee decision. Ask your counsel to confirm the status of both on the European Parliament Legislative Observatory) before you fix your sub-processor notice periods or objection rights in a contract template. Record the date of that check, because the status may move between your review and your next customer renewal.
Next, confirm the transfer position for every vendor on the list that sits outside the EEA. The EU-US Data Privacy Framework rests on Commission Implementing Decision (EU) 2023/1795, and an appeal in Case C-703/25 P *Latombe v Commission* is pending. Ask counsel whether any vendor relying on the Framework needs a standard contractual clauses fallback in place now, and whether the vendor's own transfer documentation names the same mechanism you have recorded. Do not assume a vendor's marketing page reflects its current certification status. Check the Commission's adequacy pages and the appeal record, and note which vendors depend on the outcome.
Then confirm what your own contracts and your environment actually say. Read the controller's processing agreement with each processor and check the sub-processor clause: whether authorisation is specific or general, how much notice a change requires, the length of the objection window and what happens if you object. Confirm in your own systems where each vendor's support staff can reach personal data, including remote administration from a third country, because that access counts as a transfer even when no data is stored there. Ask each vendor, in writing, for the name, address and contact person of every sub-processor and for the location and access path of each one, and keep that answer with a date and a named owner.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the sub-processor records, flow-down terms and transfer checks that your controllers ask for can be produced from your systems. We prepare the evidence. Your organization remains responsible for its sub-processor decisions and contracts, and only an independent auditor or assessor issues reports.
How we scope
- We agree in writing which processing activities, platforms and sub-processors fall inside the engagement before work starts.
- We list every hosting, support, backup and monitoring service that touches customer personal data, including remote access from outside the EEA.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- We set up a maintained register recording each sub-processor's name, address and contact person, kept current for customer requests.
- We map each sub-processor to its processing purpose, data categories and location, so transfer checks can be run per service.
- We document the data protection terms your sub-processors must accept, aligned with the flow-down duties in Article 28(4).
How we hand over
- We deliver the sub-processor register, change-notice and objection procedure, and transfer assessment records as versioned documents.
- We provide the configuration and access records for self-hosted platforms that show which systems and locations hold customer data.
- We walk your compliance and engineering teams through the evidence so they can answer controller questions without us present.
How we support
- We help you run the notice and objection cycle when you add or replace a sub-processor, including updating the register.
- We support evidence requests from your customers and from the auditor or assessor you engage, within the agreed scope.
- Retainers cover periodic register reviews, platform upgrades and re-checks of transfer risk when a sub-processor's location or access model changes.
