Subprocessor Meaning: Processor vs Subprocessor and Subprocessor List Rules

A subprocessor is a third party your processor hires to help deliver the service you bought, where that third party also handles personal data you are responsible for. You never signed a contract with them. They hold data about your customers and your employees. And when someone asks what you hold about them, the answer covers that data too.

The short version: under GDPR Article 28(2) your processor cannot add one without your authorization, under Article 28(4) it stays fully liable if that party fails, and under EDPB Opinion 22/2024 you are expected to be able to name every party in the chain, not just the ones you signed with. US state laws mostly require a flow-down contract and nothing else. Colorado is the single exception.

What is a subprocessor?

A subprocessor processes personal data on behalf of a processor, which is itself processing that data on behalf of you, the controller. It sits one step further down the same chain and does the same category of work under the same instructions, which is why the GDPR does not give it a separate name. Article 28 just calls it "another processor". The word subprocessor comes from industry practice, and it stuck because it describes the shape of the relationship better than the statute does.

The examples are ordinary, which is exactly why the chain gets long without anyone deciding it should. Your support desk hosts its data with a cloud provider. Your payroll platform sends payslips through an email delivery service. Your CRM enriches contact records through a third-party data vendor. Your accounts payable automation reads supplier invoices through an OCR service it did not build. Each of those is a company holding personal data you are accountable for, reached through a contract you were not party to.

Processor vs subprocessor: what is the difference?

Position in the chain, not function. A processor is engaged directly by the controller. A subprocessor is engaged by that processor. Both are processors in the legal sense, both are bound by the same categories of obligation, and both must process only on the controller's documented instructions as those instructions pass down the chain.

The difference that matters is practical. You negotiate with your processor, you audit your processor, and you send your questions to your processor. Everything you want from a subprocessor you have to get through the party in between. That is fine when the chain is two links long and slow when it is four, which is the situation most privacy teams discover the first time a deletion request needs confirming end to end.

What is the difference between a subprocessor and a subcontractor?

Mostly vocabulary, and which body of law you are reading. The GDPR says "another processor". The industry says subprocessor. US state privacy laws say subcontractor: both C.R.S. 6-1-1305(5) in Colorado and Va. Code 59.1-579(B) in Virginia use that word for the same relationship.

Where the words genuinely diverge is scope. A subcontractor in the ordinary commercial sense is any party your vendor hires, including plenty that never touch personal data, such as a facilities company or an outside auditor. Only the ones that process personal data on your behalf pick up the privacy obligations. So the useful question when you read a vendor's subcontractor clause is not what the parties are called. It is which of them will hold data about your customers.

Subprocessor rules by regime

The table compares the four things that actually differ: whether your vendor needs your permission before adding a link to the chain, whether you have to be told, whether the flow-down contract is mandatory, and where liability lands. Privacy statutes get amended every session, so confirm a row against the current text before you build a contract template on it.

Does GDPR require a subprocessor list?

Not in those words, but the effect is close, and it landed harder in 2024 than most vendor DPAs reflect. Article 28(2) requires prior specific or general written authorization before your processor engages another, and says that under a general authorization the processor must inform you of any intended changes concerning the addition or replacement of other processors so you can object. That mechanism only functions if there is a list to compare the notice against.

EDPB Opinion 22/2024, adopted in October 2024 following a request from the Danish supervisory authority, went further. Its position is that a controller should have the identity of every processor and subprocessor in the chain readily available, including name, address and a contact person, so it can demonstrate compliance and act on data subject requests. Not just the vendors you signed with, and not only the risky ones. The Opinion also says you may generally rely on the information your processor gives you about the guarantees down the chain, but that where the processing presents a high risk to individuals you are expected to verify rather than accept.

Read as an operational instruction, that is a register: a maintained list of every party holding personal data on your behalf, with enough contact detail that you could actually reach them. And it is your obligation, not your vendor's.

Do you need consent to add a subprocessor?

You need authorization from the controller, which is a different thing from consent from the individual. Article 28(2) allows the authorization to be specific, naming the party in advance, or general, permitting additions subject to notice and an objection right.

Almost every SaaS vendor uses the general form, and the standard pattern looks the same everywhere: a published subprocessor page, a commitment to give notice some number of days before a change, and a window in which the customer may object. What varies, and what is worth reading closely before you rely on it, is what happens after you object. Many agreements say only that you may terminate the affected service. That is a real remedy for a business deciding whether to renew and no remedy at all for a privacy team trying to keep one vendor out of the chain.

Does the CCPA have subprocessor requirements?

Yes, under different vocabulary and with a sharper consequence. California has no controllers or processors, so nothing in the regulations is called a subprocessor. What 11 CCR 7051(b) requires is that a service provider or contractor engaging another entity to help perform its services enters a contract that complies with the same rules the top-level contract has to meet.

The consequence is the part that catches people out. Under 7051, a person that does not have a contract complying with subsection (a) is not a service provider or contractor, and the business's disclosure of personal information to that person may be considered a sale or sharing of personal information, for which the consumer must be given the right to opt out. A missing link in the chain is not a paperwork gap in California. It can change the legal character of the data flow, which means your privacy notice, your opt-out signals, and your Do Not Sell or Share link are all affected by a contract two parties away from you. The contract terms each state requires are worth reading side by side for that reason.

Who is liable if a subprocessor causes a data breach?

Article 28(4) is unusually direct: where the other processor fails to fulfil its data protection obligations, the initial processor remains fully liable to the controller for the performance of that other processor's obligations. So your contractual recourse runs to the party you actually signed with, which is the right answer commercially, because chasing a company you have no agreement with is not a plan.

It does not make you a bystander. As controller you are still responsible under Article 28(1) for having used only processors providing sufficient guarantees, for your own Article 33 notification duties, and for the security of the processing overall. The Colorado Privacy Act states the same principle plainly: a contract may not relieve a controller or a processor of the liabilities imposed on it by its role in the processing relationship. Liability allocation between vendors is not a transfer of accountability to the regulator.

How subprocessors change the way you answer a request

This is where the paperwork turns into work. A data subject access request asks what you hold about a person, and data held by a subprocessor on your behalf is data you hold. The scope of an honest answer therefore covers systems you do not operate and, in some cases, companies you have never spoken to, while the statutory clock runs against you: one month under the GDPR, 45 days in most US states.

Three things follow. First, your maintained chain is a search scope, not a compliance artifact, so its accuracy has an operational cost rather than an administrative one. Second, the parts of the answer you can produce yourself are worth far more than the parts you have to request, because a vendor that takes eleven days to reply has spent a quarter of your deadline. Third, the list drifts, and it drifts quietly: a trial that became production, a departmental card, an integration switched on for one project, a vendor that changed its own hosting provider and told you in a notice nobody read.

The reconciliation that actually works is evidence-based rather than memory-based. When a search reports the source system behind every record it surfaces, you find out which systems hold data about real people, and you can compare that against the register you keep. Gaps in either direction are informative: a system holding data that is not on your list is a governance problem, and a listed vendor that never returns anything is usually a contract you are still paying for.

A short checklist for the chain

• Keep a register of every processor and subprocessor with name, address and a contact person, per EDPB Opinion 22/2024, rather than a list of the vendors you happen to have invoices from.
• Check what your vendor agreements say happens when you object to a new subprocessor. If the only remedy is termination, you have notice rights rather than control.
• Confirm the flow-down contract exists at each link. Every US state privacy law requires it, and in California a link without one may reclassify the whole disclosure.
• Ask for the delete-or-return confirmation at offboarding while someone still remembers the relationship, and file it where the next request can find it.
• Reconcile the register against what your systems actually return at least as often as you re-certify vendors. The two lists diverge between reviews, not during them.

Obtainer handles the operational half of this: it finds where a person's data lives across your systems, reports the source system behind every record, compiles one reviewable manifest, and tracks the deadline while you chase the parts only a vendor can answer. See how it fits subprocessor management and what a data processing agreement commits you to in the first place. Obtainer helps you comply; it is not legal advice, and authorizing, objecting to, or assessing a subprocessor stays with your team.