Sub-processor lists

A sub-processor list is the public (or customer-facing) register of every third party a vendor uses to process its customers' personal data. It's how a processor meets its GDPR duty to get authorization for, and give notice of, the companies it brings into the chain.

What a sub-processor is

When you (the controller) use a vendor (the processor) to handle personal data, and that vendor uses its own vendors to do the work (cloud hosting, email delivery, support tooling, an AI model provider), those are sub-processors. They process your data on your vendor's behalf, under instructions that come from you.

Not every vendor of your vendor is a sub-processor. The test is whether the company processes the customer's personal data. A processor's payroll provider handles the processor's own employee data, which makes it the processor's processor, not yours. A ticketing tool where support staff read customer records is a sub-processor.

Why GDPR makes processors publish and notify

Two parts of Article 28 drive this:

• Article 28(2): a processor may not engage another processor without the controller's prior written authorization, which can be specific (approval for each named sub-processor) or general (approval in advance, subject to notice). Under general authorization, the processor must inform the controller of any intended addition or replacement, giving the controller the chance to object.
• Article 28(4): the processor must impose the same data protection obligations on each sub-processor by contract, with sufficient guarantees about security. If a sub-processor fails, the original processor remains fully liable to the controller.

Specific authorization doesn't work for a SaaS vendor with thousands of customers, so almost every vendor DPA uses general authorization. A published list plus a change notice process is the practical way to meet 28(2): the list is the baseline the customer authorized, and notices cover changes. Article 28(3)(d) also makes respecting these conditions a required clause in the DPA itself (see Data processing agreements).

The European Data Protection Board went further in its Opinion 22/2024 (adopted on 7 October 2024). It said controllers should have the identity of all processors and sub-processors in the chain readily available at all times, whatever the risk of the processing, and that processors should provide and update that information proactively. In practice, that means listing sub-sub-processors where they touch customer data, or at least being able to produce them on request.

US state laws point the same way. The CCPA regulations require a service provider's subcontractors to be bound by a contract with the same terms (11 CCR §7051(b)). Other state laws require written flow-down contracts with subcontractors, and some go further. Colorado's, for example, says a processor may engage a subcontractor only after giving the controller an opportunity to object (C.R.S. §6-1-1305).

What fields to include

A useful list answers the questions a customer's privacy team will ask in a vendor review. At minimum:

Also publish a "last updated" date and a changelog or version history, and link the list from the DPA so its legal status is clear.

Notification mechanics

A web page that changes silently isn't notice. Customers can't be expected to check it daily. Working setups look like this:

1. Subscription. Customers sign up (often a simple form or a setting in the admin console) to receive change notices by email. Some vendors notify all account admins automatically.
2. Advance notice. The DPA states a notice period before a new sub-processor starts processing. Thirty days is common in vendor DPAs. The 2021 EU SCCs (Module 2 and 3, Option 2, general written authorization) ask the parties to fill in a specified time period, so the number is negotiated rather than fixed by law.
3. Content of the notice. The same fields as the list (entity, purpose, data, location, transfer mechanism), plus the date processing will start and any sub-processor being replaced.
4. Emergency replacements. Many DPAs allow a shorter or after-the-fact notice when a sub-processor must be replaced urgently (for example, it has failed or been breached). Check the DPA limits this to real emergencies.
5. Record keeping. Keep a dated record of every notice sent. It's evidence you met Article 28(2).

Objection rights

Article 28(2) gives the controller a right to object, but doesn't say what happens next. That's left to the contract. Common structures, from most to least customer-friendly:

• The vendor doesn't use the new sub-processor for the objecting customer's data.
• The parties discuss in good faith, and the vendor offers an alternative configuration (another region, or the feature switched off).
• If no solution is found, the customer can terminate the affected service without penalty and get a pro-rata refund of prepaid fees.
• The customer's only remedy is to stop using the service, with no refund. That's weak, and worth pushing back on.

An objection usually has to be in writing within the notice period, and many DPAs require "reasonable grounds relating to data protection". Make sure the objection window is at least as long as the time your team realistically needs to review a notice. As a buyer, check the vendor's list and notice process before you sign. The privacy software buyer's checklist includes it as a must-have.

If you're the one publishing a list

• Build it from your data map, not from memory. Every system that touches customer data should appear, or be documented as out of scope.
• Assign an owner in procurement or privacy, and add a "does this vendor touch customer data?" step to vendor onboarding, so the list is updated before the contract is signed, not after.
• Keep signed DPAs with each sub-processor on file, flowing down the same obligations as your customer DPA (Article 28(4)).
• Review the list at least once a year against actual systems and invoices. Shadow tools bought on a credit card are the usual gap.
• Watch AI providers in particular. Adding a model provider to a product feature is a sub-processor change if customer data reaches it.

For how sub-processor lists fit into the wider vendor and contract picture, see Data processing agreements. For the security side, see Security controls for personal data.

This site's own processors

This site doesn't process anyone's personal data on behalf of customers, so it doesn't have sub-processors in the Article 28 sense. In the interest of practicing what the page preaches, here are the third parties involved in serving it to you:

That's the full list. The site has no analytics, no advertising or tracking tags, no forms, no comments and no accounts, and we don't set any cookies. The interactive checklists run entirely in your browser and send nothing anywhere. For more, see the privacy policy.

Need this built?

If you would rather have this implemented than read about it, tell us about your project and we will reply with questions or a rough plan.