# What Are Subprocessors? Fourth-Party Risk Explained > A plain-English explainer on subprocessors: the GDPR controller-processor-subprocessor chain, fourth-party risk, subprocessor lists, flow-down obligations, and how third-party risk management programs handle the vendors behind your vendors. General information, not legal advice. Source: https://playciso.com/blog/what-are-subprocessors · Published: 2026-10-23 · Publisher: PlayCISO (https://playciso.com) --- A subprocessor is a third party that your vendor brings in to help process data on your behalf — the vendor behind your vendor. Understanding subprocessors is really about understanding fourth-party risk: the exposure that lives one layer down your supply chain, where your data travels but your contracts usually do not reach directly. This article is general information, not legal advice. ## The controller, processor, subprocessor chain The clearest way to define subprocessors is through the GDPR roles, which have become the common vocabulary even outside the EU: - A controller decides why and how personal data is processed. If you collect your customers' data to run your product, you are typically the controller. - A processor processes that data on the controller's behalf and on its documented instructions. The SaaS tools and vendors you hire to handle data are your processors. - A subprocessor is a third party the processor engages to help it carry out the processing. Your vendor's cloud host, its email-delivery service, its analytics provider and its support tooling are all subprocessors in your data chain. So when you adopt a single SaaS product, you are rarely adopting one company — you are inheriting its entire stack of subprocessors, each of which may touch your data. The obligations are meant to flow down the whole chain, which is the key to managing it. ## Why subprocessors are "fourth-party" risk Your direct vendors are your third parties: you choose them, contract with them, and assess them. Their subprocessors are your **fourth parties** — you generally have no direct contract or relationship with them, yet they can store, transmit or process your data. That indirectness is exactly the problem. A breach, outage or compliance failure at a subprocessor can expose your data and trigger your obligations, even though you never signed anything with them and may not have known they were in the chain until you looked. Fourth-party risk is harder to see, harder to assess, and easy to forget — which is precisely why attackers and auditors both pay attention to it. A particularly important flavour is **concentration risk**. When many of your vendors quietly depend on the same handful of underlying providers — a dominant cloud platform, a popular authentication service, a widely used CDN — a single failure or compromise there can ripple across several of your supposedly independent services at once. Mapping subprocessors is how you discover these hidden shared dependencies before they fail together. ## What GDPR requires about subprocessors GDPR builds the chain explicitly. A processor must not engage a subprocessor without the controller's authorization — either _specific_ authorization for named subprocessors, or _general_ authorization where the processor must inform the controller of intended additions or replacements and give the controller a chance to object. And when a processor does engage a subprocessor, it must impose **the same data-protection obligations** on that subprocessor by contract as it owes to the controller, and it remains liable to the controller for the subprocessor's performance. This is the legal backbone of flow-down: your protections are supposed to follow your data down the chain rather than stopping at your immediate vendor. ## Subprocessor lists and change notices In practice, vendors operationalise this with a **subprocessor list** — a published list of the third parties they use to process customer data, usually on a trust or legal page, often with each subprocessor's purpose and processing location. That list is your window into your own fourth-party data chain: it tells you where your data actually goes, which underlying providers you depend on indirectly, and where processing happens geographically, which matters for cross-border transfer rules. Reputable vendors also offer a way to subscribe to change notifications, so when they add or swap a subprocessor you find out and can object if you need to. If a vendor cannot produce a subprocessor list, that is a finding in itself. ## Flow-down obligations in your contracts The contract that makes all this real is the data processing agreement (DPA) with your vendor. A good DPA requires that any subprocessor be bound to **equivalent** security, confidentiality, breach-notification and audit obligations, keeps your vendor liable for its subprocessors, and gives you authorization rights and advance notice of changes. Reviewing those flow-down terms — and confirming they are not hollowed out one layer down — is a core part of vendor due diligence, and it is exactly the sort of control a structured review captures. Our [vendor security assessment checklist](/blog/vendor-security-assessment-checklist) includes subprocessor and flow-down questions, and a [vendor risk scorecard](/tools/vendor-risk-scorecard) gives you a repeatable way to compare vendors on how transparently and rigorously they manage the layer beneath them. ## How TPRM programs handle subprocessors Mature third-party risk management (TPRM) does not stop at the vendors you signed with. It extends to their material subprocessors in a few concrete ways: maintaining an inventory of key vendors _and_ their critical subprocessors; assessing concentration risk across the portfolio to spot shared single points of failure; requiring and reviewing subprocessor lists and subscribing to change notices; embedding flow-down, audit and notification rights in every DPA; and reassessing when a vendor changes its subprocessors or when a subprocessor suffers an incident. Standardised questionnaires such as the [CAIQ](/blog/what-is-caiq) ask vendors to disclose how they govern their own suppliers, which gives you a consistent basis for comparison. The goal is not to eliminate fourth parties — that is impossible in a modern cloud stack — but to make the chain visible and ensure your protections travel all the way down it. ## Frequently asked questions **What are subprocessors?** Third parties your vendor (the processor) engages to help process data on your (the controller's) behalf — for example a SaaS tool's cloud host, email service or analytics provider. **Controller vs processor vs subprocessor?** The controller decides why and how data is processed; the processor handles it on the controller's instructions; the subprocessor is a party the processor brings in to help, forming a chain down which obligations should flow. **What is fourth-party risk?** Risk from your vendors' vendors — subprocessors you have no direct contract with but whose breach or failure can still expose your data, including concentration risk from shared underlying providers. **What is a subprocessor list?** A vendor's published list of the third parties it uses to process customer data; it reveals where your data goes and is the mechanism for notice of and objection to changes. **How do protections flow down?** Through flow-down clauses: GDPR requires processors to bind subprocessors to equivalent obligations by contract and keeps the processor liable, so your negotiated protections do not vanish one layer down.