Every SaaS company leans on other vendors. You host on someone's infrastructure, send email through a provider, run analytics on a third-party tool, and route support tickets through yet another service. Each vendor that handles personal data on your behalf is a sub-processor, and your customers have every right to know who's in that chain.
Most teams keep this information in a stale spreadsheet or a web page someone refreshes once a year. Then a prospect's security team asks for your current sub-processor list, and the scramble starts: which vendors are still in use, which agreements are actually signed, and who approved the new one that slipped in last quarter? Sub-processor management is a program, not a document. This guide covers what GDPR asks of you and how OptiTech keeps the chain accurate and public.
What a sub-processor actually is
Start with the roles. When a customer trusts you with personal data, you act as their processor: you handle that data on their instructions. The moment you bring in another vendor to help you deliver the service, and that vendor touches the same data, they become your sub-processor. Your cloud host, your email delivery service, your analytics tool, and your support platform are all common examples.
The chain matters because your customer, the controller, stays responsible for the data no matter how many hands it passes through. They authorized you. They didn't automatically authorize everyone you hire. That's why GDPR builds specific duties around the vendors behind you, and why buyers scrutinize your list before they sign.
What GDPR asks of you
Article 28 is the heart of it. You can't hand personal data to a sub-processor unless your customer has authorized it, either specifically or generally. Most companies use general authorization: the customer agrees up front that you may use sub-processors, on the condition that you keep them informed and give them a chance to object when the list changes.
That condition comes with real obligations:
- Authorization. You need documented permission to use each sub-processor, and you need to know which contract term grants it.
- Equivalent protection. Every sub-processor must be bound by data protection terms at least as strict as the ones you promised your customer. You can't offer weaker safeguards downstream than you offer upstream.
- Transparency. Customers must be able to see who your sub-processors are, not just trust that you have some.
- Accountability. If a sub-processor mishandles data, you remain liable to your customer for the failure. Their mistake is your problem.
None of this is optional, and none of it works if your list is out of date.
The public sub-processor list buyers ask for
The single most requested artifact in this area is a current, public sub-processor list. Enterprise buyers expect to find it without emailing anyone. A good list names each sub-processor, what they do for you, and where they process data.
Publishing it does two things at once. It satisfies your transparency duty under GDPR, and it removes a step from every security review. When the list lives on a trust center that reads from your live program, it's never a snapshot that drifts out of date. The page buyers see reflects the vendors you actually use today.
Change notifications and the right to object
General authorization comes with a catch: when you add or replace a sub-processor, you have to tell your customers before the new vendor starts processing their data. That notice period, often 30 days, gives customers a window to object if the change genuinely worries them.
Handled manually, notifications are easy to forget and hard to prove you sent. Handled as a workflow, they're routine. You record the planned change, notify the affected customers, log the date, and track the objection window. If someone objects, you have a documented conversation instead of a surprise dispute after the fact.
Give customers real notice
The point of a notification period is to give customers a genuine chance to react before a new sub-processor handles their data. Record when you sent each notice and when the objection window closes, so you can prove you gave fair warning rather than a rushed heads-up.
Flow-down terms in your contracts
Your promise to your customer is only as strong as the contract behind each sub-processor. GDPR requires you to flow down equivalent data protection terms, so the obligations you accepted upstream reach every vendor downstream.
In practice that means a signed data processing agreement with each sub-processor, covering confidentiality, security measures, breach notification, deletion on termination, and any restrictions on their own sub-processors. If personal data leaves the EU, that agreement also needs a valid transfer mechanism, and you need to be able to name it. Missing or unsigned agreements are the gap auditors find first, because they turn a compliant-looking list into an unenforceable one.
Monitoring their compliance
Signing an agreement is the start, not the finish. Sub-processors drift: certifications lapse, security posture changes, and vendors sometimes get acquired or move data to new regions. Your duty of oversight doesn't end when the ink dries.
Sensible monitoring means tracking each sub-processor's certifications and renewal dates, reviewing their compliance reports on a schedule, and reassessing when something material changes. The goal isn't to audit every vendor yourself. It's to notice, early, when one of them stops meeting the bar you promised your customers.
How OptiTech tracks it all
This is where a connected program beats a spreadsheet. In OptiTech, each sub-processor is a record, not a row. You link it to the agreement that governs it, the transfer mechanism it relies on, the region where it processes data, and the certifications it holds. When a certificate is about to expire, you see it before your customer does.
The change workflow runs in the OptiTech Console. When you plan to add or replace a sub-processor, you record the change, trigger notifications to affected customers, and track the objection window in one place. Every notice and every response is logged, so proving you followed the process is a matter of pulling a record rather than reconstructing a timeline.
Best of all, your trust center reads from the same program. The public sub-processor list buyers ask for is generated from your live records, so it's accurate the moment you make a change. You maintain one source of truth, and both your customers and your auditors see the same current picture.
Getting started
You don't need to rebuild everything at once. A realistic first pass looks like this:
- Inventory your sub-processors. List every vendor that touches customer personal data, and what they do.
- Attach the agreements. Confirm each one has a signed data processing agreement, and flag any transfers outside the EU.
- Stand up the change workflow so notifications and objection windows stop living in someone's memory.
- Publish the list to your trust center so the work answers buyer questions on its own.
Sub-processor transparency used to be a chore you dreaded during security reviews. Built as a living program, it turns into a page you're happy to point buyers at. Track the chain once, keep it current, and the same records that keep you compliant start closing deals.
Ready to bring your vendor chain into one program? Book a demo and see how OptiTech tracks your sub-processors, their agreements, and your transfers.
