What Is a Sub-Processor?

How does the chain work?

Three roles, each with different obligations.

Controller. Determines the purposes and means of processing. This is you, for the personal data in your CRM. You are accountable to data subjects and to the supervisory authority.

Processor. Processes personal data on the controller's behalf and on their documented instructions. A SaaS vendor handling your customer data is typically a processor.

Sub-processor. A processor engaged by the processor. The cloud infrastructure under your SaaS vendor, an offshore support team, an analytics provider embedded in the product.

The essential point: responsibility flows down but accountability does not. You remain accountable for personal data processed anywhere in that chain. A breach at a sub-processor four links down is still your breach to notify.

What does Article 28 require?

Three obligations matter most.

Written authorisation before engagement. Under Article 28(2) a processor must not engage a sub-processor without the controller's prior specific or general written authorisation. Most contracts use general authorisation, in which case the processor must inform you of intended additions or replacements and give you an opportunity to object.

That opportunity to object is real and frequently ignored. A vendor emailing a sub-processor list update is starting a clock, not sending a newsletter.

Flow-down of obligations. Article 28(4) requires the same data protection obligations set out in your contract with the processor to be imposed on the sub-processor, in particular the guarantee of appropriate technical and organisational measures.

Continuing liability. Where the sub-processor fails to fulfil its obligations, the initial processor remains fully liable to the controller. Subcontracting does not transfer the exposure.

Why does the chain length matter?

Because each link adds compliance work that is separate from the licence cost.

A DPA to negotiate and keep current. Article 28(3) sets out what the contract must contain.

A transfer assessment, if it sits outside your region. A sub-processor in a third country brings Chapter V into play: transfer mechanism, safeguards, and a transfer impact assessment.

A row in your Record of Processing Activities. Article 30(1) requires categories of recipients, including recipients in third countries.

A party to reach on a data subject request. If someone requests erasure and the data has been copied down the chain, the request has to reach every copy.

A link in your breach clock. Article 33 gives you 72 hours from becoming aware of a breach to notify your supervisory authority. Every link that has to detect, escalate and tell you consumes part of that window before you know anything.

A monitoring obligation. You are expected to satisfy yourself the guarantees are real, not merely contracted.

None of this makes sub-processors bad. It makes them a cost, and one that is usually invisible at the point of purchase.

Where do sub-processors appear in a Salesforce estate?

More often than a vendor list suggests.

Salesforce itself is a processor for the personal data you hold in your org, with its own published sub-processor list, including infrastructure providers.

Connected apps and integrations that receive personal data are typically processors in their own right, each with their own sub-processors.

Managed packages differ from each other, and this is the distinction most often collapsed. A managed package that runs entirely as Apex inside your org, with no external endpoint, does not receive personal data anywhere else. Nothing leaves the Salesforce boundary, so the package vendor is not receiving your data to process. A managed package that calls out to a vendor-hosted service does transmit personal data outside the org, and that vendor is a processor with its own chain behind it.

Both architectures are legitimate. They differ in the paperwork they generate, and the difference is easy to miss because both appear in AppExchange the same way.

Data warehouses, backup tools, analytics and support platforms that pull CRM data are each processors, and each brings a chain.

What should you actually do about it?

Five things, in order of neglect.

Ask for the sub-processor list before signing, not after. It is a standard request and a vendor that cannot produce one quickly is telling you something.

Read the change-notification clause. Specifically: how much notice, through what channel, and what happens if you object. A clause that lets a vendor add sub-processors with no notice is worth negotiating.

Subscribe to the notifications. They usually go to one named contact who leaves the company two years later.

Record it. Your RoPA needs categories of recipients including third-country recipients, and that is where the chain becomes visible to a regulator.

Ask where the data physically is. Not where the vendor is headquartered. Those differ more often than not.

Where Cloud Compliance sits in this

Our products are Salesforce-native managed packages. Processing runs as Apex inside your own org and no customer data leaves the Salesforce boundary, so we do not receive your personal data to process on your behalf. The practical effect is that using our tooling does not add a link to your chain, does not create a new cross-border transfer to assess for the tool itself, and does not add a row to your Article 30 record.

That is a genuine architectural difference, and it is worth being precise about how much it buys you: it removes the paperwork for the privacy tool, not for Salesforce, not for your integrations, and not for anything else in the estate. It is a smaller claim than "reduces your compliance burden", and it is the accurate one.

Where an external privacy platform is the right architecture for your organisation, and for estates with personal data spread across many systems it often is, then it being a processor is entirely normal. Assess it, contract it, record it, and move on.