A subprocessor is an organization that a data processor engages to carry out processing of personal data on its behalf — and therefore, ultimately, on behalf of the controller whose data is involved. The General Data Protection Regulation (GDPR) governs the arrangement through Article 28: a processor may engage another processor only with the controller's prior written authorization, and it must pass its own data protection obligations down to that other processor by contract.
The role is easiest to see in a software-as-a-service (SaaS) relationship. When your organization adopts a SaaS product to manage customer records, the vendor acts as a processor under your instructions. That vendor almost never works alone: it hosts data with a cloud infrastructure provider, sends notifications through an email delivery service, and handles support conversations in a ticketing tool. Each of those companies processes personal data that you answer for as controller. Each one is a subprocessor.
This guide explains the definition in plain language, shows where the concept sits in the GDPR text and where the word itself does not, walks through the controller-processor-subprocessor chain, and covers the obligations that follow in practice: authorization, flow-down contracts, public subprocessor lists, and what happens when those lists change.
The definition in plain language
Three roles anchor every processing relationship under the GDPR. The controller determines the purposes and means of processing — why personal data is used and, in essence, how. The processor processes personal data on the controller's behalf, bound by the controller's documented instructions. A subprocessor is a processor engaged by another processor: it performs part of the processing that the first processor has promised to the controller.
The defining feature of a subprocessor is that it normally has no direct contract with the controller. Its obligations arrive second-hand, through the chain of contracts that Article 28 requires. The controller instructs the processor, the processor instructs the subprocessor, and data protection duties must travel down that chain intact. That is why the GDPR requires the processor to impose the same data protection obligations on any other processor it brings in.
Whether a company is a subprocessor is a question of function, not labels. The European Data Protection Board (EDPB) makes this point throughout its Guidelines 07/2020 on the concepts of controller and processor: roles follow the factual circumstances of the processing, not the names the parties chose in a contract. A company that processes personal data for a processor, in service of the controller's purposes, is a subprocessor even if the paperwork never uses the word. A company whose service never touches personal data — a pure software licensor, for example — is not.
Subprocessor, sub-processor, and other names
Spelling varies. Vendor transparency pages tend to write "subprocessor" without a hyphen, while the European Commission's standard contractual clauses for controller-processor relationships and much regulator guidance write "sub-processor." You will also occasionally meet "downstream processor" or, in vendor-risk circles, "fourth party." All of these describe the same role, and the choice of term changes nothing in the legal analysis.
Where the term appears in the GDPR
Precision pays off here, because this is a persistent source of confusion. The GDPR never uses the word "subprocessor." The regulation speaks of a processor engaging "another processor." Article 28(2) provides that a processor shall not engage another processor without the controller's prior specific or general written authorization. Article 28(4) adds that where a processor engages another processor to carry out specific processing activities on the controller's behalf, the same data protection obligations set out in the controller-processor contract must be imposed on that other processor by way of a contract.
"Subprocessor" is industry shorthand for the "another processor" of those two provisions. The shorthand earned its place — processing chains can run several layers deep, and describing the other processor engaged by the other processor gets unwieldy fast — and it has become semi-official: the Commission's optional standard clauses adopted under Article 28(7) and EDPB guidance both use "sub-processor." When you need to cite the law, though, the operative text is Article 28 of the GDPR and the operative phrase is "another processor."
The vocabulary point has a practical consequence. Because the GDPR attaches obligations to roles rather than labels, everything the regulation demands of a processor applies to a subprocessor for the processing it actually performs. A subprocessor must keep its own records of processing under Article 30(2), implement appropriate security measures under Article 32, and inform the processor that engaged it about personal data breaches. Sitting lower in the chain does not thin out the obligations.
Common examples of subprocessors
Nearly every SaaS product is assembled from specialized services. Wherever those services process personal data belonging to the vendor's customers, they act as subprocessors of that vendor. Typical categories include:
- Cloud infrastructure and hosting providers that run the databases, storage, and compute behind the product.
- Content delivery and edge networks that carry application traffic and may log IP addresses.
- Email and messaging delivery services that send transactional mail containing names, addresses, and message content.
- Analytics and product telemetry services that receive usage events tied to user identifiers.
- Customer support and ticketing platforms that store support conversations, which routinely contain personal data.
- Backup, logging, and error-monitoring services that replicate or ingest production data.
- Billing and invoicing services, to the extent they handle customer personal data on the vendor's behalf.
Two caveats keep a list like this honest. First, category membership proves nothing by itself: a provider is a subprocessor only if it actually processes personal data on the vendor's behalf. A logging service that only ever receives scrubbed, non-personal telemetry sits outside the chain. Second, some providers are controllers in their own right for parts of what they do — payment institutions are the classic example, because financial-sector law imposes purposes of their own on the data they handle. Role analysis has to be run per data flow, not per company name. Our guide to controller, processor, and sub-processor roles under the GDPR works through that analysis step by step.
The controller-processor-subprocessor chain
The GDPR builds the chain out of contracts. At the top, Article 28(3) requires a binding agreement between controller and processor — in practice called a Data Processing Agreement (DPA) — that sets out the subject matter and duration of the processing, its nature and purpose, the types of personal data, and the categories of data subjects, together with a list of mandatory commitments: processing only on documented instructions, confidentiality, security measures under Article 32, conditions for engaging further processors, assistance with data subject rights and breach duties, deletion or return of data, and audit rights. We cover each element in our guide to GDPR Article 28 DPA requirements.
Flow-down obligations under Article 28(4)
The chain continues downward by repetition. When the processor engages a subprocessor, Article 28(4) requires it to impose the same data protection obligations it accepted toward the controller onto the subprocessor, again by contract, and in particular the obligation to provide sufficient guarantees that appropriate technical and organizational measures will be implemented. Each link of the chain must mirror the protections of the link above it. If the controller's DPA restricts storage locations or promises breach notice within a defined window, those commitments have to reappear in the processor's contracts with its subprocessors — otherwise the processor cannot honestly keep its own promises.
Liability stays with the initial processor
Article 28(4) closes with an allocation of risk that shapes commercial behavior: where a subprocessor fails to fulfill its data protection obligations, the initial processor remains fully liable to the controller for the performance of that subprocessor's obligations. The controller does not need to chase a company three links down the chain with which it has no contract; it holds its own processor responsible, and the processor carries the exposure for the vendors it chose. This is one reason careful vendors are selective about their subprocessors: the chain is a liability statement as much as a transparency exercise.
General versus specific authorization
Article 28(2) gives controllers two ways to authorize sub-processing, and the difference drives most of the operational work that subprocessor management involves.
Specific authorization
Under specific authorization, the processor must obtain the controller's approval for each subprocessor individually before engaging it. This model gives the controller the most control and appears in high-sensitivity outsourcing, where the controller wants a veto over every party in the chain. It scales poorly for multi-tenant SaaS, where one vendor serves thousands of customers on shared infrastructure: collecting individual approvals from every customer for every change would stall the platform.
General authorization and the duty to inform
Under general written authorization, the controller approves sub-processing up front, typically by accepting the vendor's current subprocessor list as part of the DPA. The authorization is not a blank check. Article 28(2) requires the processor to inform the controller of any intended changes concerning the addition or replacement of other processors, and to give the controller the opportunity to object to those changes. The mechanics — how notice is given, how long the objection window runs, what happens if the controller objects — are left to the contract, which is why DPA notice clauses deserve careful reading. Most SaaS agreements work this way, and the practical consequence is a stream of change notifications that someone on the controller side has to receive, assess, and answer.
Hybrid arrangements exist as well. Some controllers negotiate general authorization for infrastructure-level subprocessors while reserving specific approval for any provider that would touch particularly sensitive categories of data. The regulation accommodates either model — Article 28(2) simply requires that one of them be agreed in writing — so the split between them is a matter of negotiating position and risk appetite rather than law.
Why subprocessor lists exist
Public subprocessor lists are how vendors operationalize general authorization at scale. A page that names each subprocessor, describes what it does, and states where it processes data serves several audiences at once. It gives prospective customers the information they need for due diligence under Article 28(1), which allows controllers to use only processors providing sufficient guarantees. It gives existing customers a reference point for what they authorized. And paired with a notification mechanism, it helps the vendor meet its duty to inform customers of intended changes.
Formats vary widely: some vendors maintain a simple web page, some publish a PDF, some fold the list into a trust portal, and some offer an email subscription for updates. No format is mandated, and the variation matters operationally — a list that changes without any announcement shifts the burden of noticing onto the controller. Our article on why subprocessor lists change looks at what drives the churn.
Obligations when the list changes
A subprocessor change is a compliance event for the controller, not just news. Under general authorization the sequence usually runs like this: the vendor announces an addition or replacement, a contractual objection window opens, and the change takes effect if no objection lands. Within that window, a controller has real work to do.
- Confirm the change against the DPA: does the notice match the mechanism and timing the contract promises?
- Assess the new subprocessor: what personal data will it touch, in what role, and with what safeguards?
- Check international transfers: a new processing location can change the transfer analysis for the whole service.
- Update internal records: the categories of recipients recorded in your Records of Processing Activities (RoPA) under Article 30 may need revision.
- Decide and document: accept the change or raise an objection through the contractual path, and keep evidence of the decision either way.
The uncomfortable truth is that this workflow only starts if the controller learns about the change. Notifications go to unmonitored mailboxes, subscription links are tied to employees who have left, and some pages simply change without any announcement. A change nobody saw still happened — and the objection clock still ran. Controllers that discover a change late are not relieved of the assessment; they simply perform it after the fact, with fewer options and a weaker record to show for it.
What SMEs should do in practice
Small and mid-sized enterprises (SMEs) rarely have a dedicated vendor-risk function, but the obligations do not scale down: a ten-person company using twenty SaaS tools sits on top of the same kind of chain as an enterprise. A proportionate program looks like this.
- Inventory your processors: list every vendor that processes personal data for you, with a link to its subprocessor page and its DPA.
- Capture the notice terms: for each vendor, record how changes are announced and how long you have to object.
- Subscribe where possible: join every notification list your vendors offer, using a shared team mailbox rather than a personal one.
- Assign ownership: name the person who reviews changes, even if it is a part-time responsibility.
- Review on a schedule: check the pages of vendors that offer no notifications at a recurring cadence, and record each review.
- Document decisions: keep a dated trail of what changed, what you assessed, and what you decided.
Prioritize by exposure rather than by spend. The vendor holding your customer database matters more than the most expensive tool in your stack, and a tiered approach — a handful of vendors reviewed closely, the rest on a lighter cadence — outlasts a uniform process that is too heavy to sustain.
None of this requires specialized tooling to start — a spreadsheet and a shared mailbox are a legitimate first version. The failure mode is not the absence of software; it is the absence of an owner and a cadence. Our subprocessor monitoring guide covers how to build the workflow in more detail.
Frequently asked questions
Is a subprocessor the same as a third party?
In everyday vendor-management language, broadly yes: a subprocessor is an external company in your supply chain, sometimes called a fourth party because it sits behind your direct vendor. Under the GDPR's defined terms the picture is narrower — Article 4(10) defines "third party" in a way that excludes the controller, the processor, and persons authorized to process under their direct authority — so privacy lawyers use the phrase with care. For practical purposes, treat a subprocessor as part of your processing chain that you authorize through your processor rather than contract with directly.
Does the GDPR use the word "subprocessor"?
No. The regulation refers to "another processor" in Articles 28(2) and 28(4). "Subprocessor" — or "sub-processor" — is shorthand adopted by industry and later used in official documents such as the European Commission's standard contractual clauses for controller-processor relationships, but the binding obligations are written in terms of a processor engaging another processor.
Do controllers have to approve every subprocessor individually?
Only under the specific-authorization model in Article 28(2). Most SaaS agreements use general written authorization instead: the controller approves the vendor's list up front, and the vendor must inform the controller of intended additions or replacements and allow an opportunity to object. Which model applies, and how much notice you get, is set by your DPA.
Are my vendor's subprocessors my responsibility?
You remain accountable as controller for processing done in your name, and Article 28(1) requires you to use only processors that provide sufficient guarantees — a duty that, on the EDPB's reading of the processor's role, extends to how your processor manages its own chain. But the GDPR routes liability sensibly: under Article 28(4), your processor is fully liable to you if its subprocessor fails. Your job is due diligence, authorization decisions, and documentation — not direct oversight of every company in the chain.
How do organizations find out when a subprocessor list changes?
Through whatever mechanism the DPA promises: an email notification list, an updates section on the vendor's site, a trust-portal announcement — or, in the weakest case, a page that simply changes. Because those mechanisms fail quietly when subscriptions lapse or mailboxes go unwatched, many teams also review the list pages themselves on a recurring schedule so that a missed email does not mean a missed change.
Where DPAFlow fits in
Running this workflow by hand across dozens of vendors is exactly the kind of recurring, detail-heavy work that slips when a quarter gets busy. DPAFlow monitors your vendors' subprocessor lists, DPA pages, and trust-center pages on a scheduled, recurring basis, detects changes, and records them with dated evidence — captured page text, change diffs, and screenshots where available. Detected changes trigger email alerts and enter a review workflow where your team can assess the change and document its decision.
If you are formalizing subprocessor oversight, you can see how the product approaches the problem on the DPAFlow product page.