Subprocessors, Explained (and Why Your DPA Lists Them)
A subprocessor is any third party your vendor hands your data to — and GDPR Article 28 puts that list in your contract by design.
A notification email arrives with a subject line like "Notice: Addition of New Subprocessor." You have 14 days to raise an objection. The name in the body means nothing to you, the purpose is described in three lines of legal prose, and the countdown is already running.
This happens to any company that signs GDPR-compliant vendor contracts. The email isn't a mistake or an overzealous vendor. It's Article 28 doing exactly what the regulation intended. Here's what's actually going on and what the notice requires you to do about it.
The three-tier chain behind your data
GDPR assigns three distinct roles to the parties who touch personal data, and subprocessors don't make sense without the first two.
A controller decides why data is collected and what it's used for. If you run a SaaS product that stores customer records, you're the controller for that data.
A processor is the vendor you hire to handle that data on your behalf, under your instructions. Your CRM, your email platform, your cloud infrastructure provider — each is a processor. They sign a Data Processing Agreement (DPA) with you, which is the contract that binds them to your compliance obligations.
A subprocessor is anyone the processor then brings in to help deliver their service. When you sign up for a SaaS platform, you're contracting with the processor. But the processor runs on something: AWS or GCP for compute, Twilio for notifications, Stripe for payment handling, Elastic for search. Each of those is a subprocessor — a company you've never contracted with directly, but whose infrastructure is processing the personal data you're responsible for as controller.
Most companies have a surprisingly long subprocessor chain. A mid-sized SaaS vendor might list fifteen to twenty subprocessors once you count infrastructure, communications, monitoring, and support tooling. That's not unusual, and it isn't automatically a problem. The issue is transparency and accountability, which is exactly what Article 28 is designed to enforce.
Why Article 28 puts them in your contract
Article 28(2) of the GDPR is the operative clause. It says a processor may not engage a subprocessor without "prior specific or general written authorisation" from the controller. That requirement is why the subprocessor annex exists in your DPA — not as nice-to-have disclosure, but a legal prerequisite.
In practice, almost no commercial SaaS vendor asks for specific authorization for each subprocessor. Renegotiating the contract every time an infrastructure component changes would be unworkable. Instead, most DPAs provide general authorization: you agree at signing that the vendor can use subprocessors, on the condition that they notify you of changes and give you a window to object.
General authorization has a mandatory counterpart. When a processor wants to add or replace a subprocessor, they must tell you in advance and give you a reasonable opportunity to object before the change takes effect. GDPR doesn't fix the notice period; your DPA does. Fourteen to thirty days is common in commercial contracts; enterprise customers sometimes negotiate sixty days or more. That notification email you received? That's the mechanism running as designed.
The obligations also flow downstream. When a processor engages a subprocessor, they must contractually impose the same data protection requirements on that subprocessor. The chain of accountability doesn't terminate at the vendor you signed with. It runs all the way down to the companies doing the actual compute, which is why processors reference their infrastructure partners by name in their DPAs and why those partners publish their own compliance documentation to support the chain.
Reading a subprocessor notice in practice
When the notification email lands, here's what to actually evaluate.
What data the new subprocessor will touch. A new cloud infrastructure provider handling encrypted data at rest is a different risk profile than a new analytics vendor with read access to customer PII. The notice should specify the category of data and the purpose of processing. If it doesn't, ask.
Where processing happens. Transfers of personal data from the EEA to countries outside it require a valid transfer mechanism under GDPR Article 46 — typically Standard Contractual Clauses (SCCs). If a US-based subprocessor is being added to process EU personal data, that transfer needs to be covered. Well-structured DPAs address this explicitly; if yours is silent on transfer mechanisms for subprocessors, that's a gap worth raising at renewal.
Whether the change warrants an objection. You have the right to object, but GDPR doesn't give you an automatic veto. Article 28 requires the processor to give you advance notice and an opportunity to object, not to seek your permission for every infrastructure decision. If you do object, the parties are supposed to discuss your concerns in good faith to find a resolution. If they can't, either party may terminate the relevant processing. In practice, routine infrastructure changes don't trigger that path. The mechanism exists for genuine conflicts — a vendor adding a subprocessor that violates data residency commitments you've made to your own customers, for instance.
The practical step: calendar the deadline the moment the email arrives. The window runs whether you're paying attention or not. Evaluate, decide, document your reasoning, and close it out.
If you're the processor
If you're the vendor in this relationship — the one your customers sign DPAs with — the subprocessor obligations run the other direction.
Your subprocessor list needs to be current. Not approximately current, not updated when someone remembers — maintained as a live document with a process for updating it before changes go live. The most common failure pattern I've seen: a team ships a new infrastructure component to production and realizes three months later they never sent the Article 28 notification. That's a compliance gap and a trust problem if a customer asks.
Build the notification step into your vendor onboarding workflow. Any tool that will touch personal data needs a DPA in place before access is granted, and customer notification needs to happen before that tool goes live. Work backwards from the planned go-live date: draft the notice when you sign the new vendor contract, schedule it according to the shortest notice period in any of your customer DPAs, and send it with enough lead time to absorb any objections before your deadline.
Flowing the obligation downstream is not optional. You need a DPA with each of your subprocessors that imposes the same requirements your customers impose on you — appropriate security measures, breach notification timelines, audit rights. If your vendor intake process doesn't treat a DPA as a blocking step before access is granted, that's worth fixing. The vendor risk assessment checklist covers what that intake review should include.
One thing teams underestimate: the accountability doesn't stop with your direct subprocessors either. Your cloud provider uses sub-subprocessors of its own — data center operators, hardware vendors, network providers. You generally can't audit that layer directly, but you can make sure your critical subprocessors are themselves running credible risk programs and publishing their own subprocessor disclosures. For a fuller look at how far vendor accountability chains extend and what you can realistically manage, the fourth-party risk guide maps it out.
Subprocessor management isn't a parallel compliance track — it's vendor risk, one layer deeper. Run it with the same rigor: a defined process, documented decisions, and someone who owns the list.