Managing GDPR Subprocessors as a SaaS: A 2026 Playbook

Every SaaS has subprocessors. You use a cloud provider, a payment gateway, an email service, a logging stack. Each of those companies touches your customers' personal data, and under Article 28 of the GDPR you owe your customers a clear, current, auditable record of who those subprocessors are. In 2026, that obligation has not gotten any softer. Regulators want a paper trail, customers want notice before changes happen, and procurement teams want a link they can put in their vendor file. This playbook walks through what counts as a subprocessor, how authorization actually works, why the "duty of transparency" is the part most teams skip, and how to run a subprocessor list that survives audit.

What counts as a subprocessor under GDPR

A subprocessor is any third party that your company hires to process personal data on behalf of one of your customers. Your customer is the controller. You are the processor. The third parties you engage to deliver the service are the subprocessors. AWS for hosting, Stripe for payments, Postmark for transactional email, Datadog for logging, Mixpanel for product analytics — if personal data flows through them, they are subprocessors under GDPR Article 28(4).

What does not count: tools that only ever see your own employees' data (an internal HR system), tools you use as a controller in your own right (a CRM for your sales team), or independent controllers your customer chose themselves. The line that matters is "is this third party processing my customer's data on my customer's behalf, through me." If yes, it is a subprocessor and it belongs on the list.

The two authorization models you can choose from

Article 28(2) is explicit: the processor cannot engage another processor without prior written authorization from the controller. The Regulation offers two ways to satisfy this.

Specific authorization

The controller signs off on each subprocessor individually, by name, before that subprocessor starts. This model is rare in SaaS because it scales poorly. A 200-customer SaaS that adds a new subprocessor would need 200 individual sign-offs before flipping the feature on. It is still common in enterprise contracts where one customer represents a sizable share of revenue and demands custom terms.

General authorization

The controller agrees in the DPA that the processor may engage subprocessors of certain categories (hosting, email, analytics, etc.), provided that:

• The processor maintains a complete list of subprocessors and makes it accessible
• The processor informs the controller of intended additions or replacements before they happen
• The controller has the right to object within a defined window

This is the model the overwhelming majority of SaaS DPAs use. It is the model your DPA almost certainly uses, even if you have not read it carefully.

The transparency duty is the part most teams skip

General authorization is not a free pass. It is a substantive ongoing obligation: tell your customers before you bring in a new subprocessor. In practice, that breaks down into three things.

1. Maintain a current public list. Most major SaaS publish theirs at predictable URLs. trust.salesforce.com/en/subprocessors, slack.com/trust/compliance/subprocessors, legal.hubspot.com/subprocessors, explore.zoom.us/en/subprocessors, www.atlassian.com/legal/sub-processors. The pattern is consistent: a table with name, role, location, and link to the subprocessor's own DPA.
2. Notify before changes. Email is the dominant method but it is fragile. Stale recipient addresses, spam filtering, and inbox overload mean a fraction of your notifications actually land. The robust pattern combines email with a public diff page so a customer's compliance team can subscribe to changes via RSS or a webhook.
3. Honor the objection window. Your DPA states the window. It is often 14 or 30 days, sometimes unspecified. If a customer objects, you either find an alternative or, in the worst case, the customer can terminate. The objection right is what makes the authorization meaningful.

How to set up a public subprocessor list that actually works

The technical pattern is boring on purpose. Boring scales.

1. One dedicated page. Title it Subprocessors. Link it from the footer of your marketing site and from the DPA itself.
2. A table with five columns. Name, role (what they do for you), location (or "global"), data categories, and a link to the subprocessor's own privacy/security page.
3. A "Last updated" date. Visible at the top, with the exact date. Customers will look for this first.
4. A "Recent changes" section. Even if it is just the last three updates with dates. This is what an auditor wants to see.
5. A subscription mechanism. An RSS feed of changes, an email list, or both. This is how compliance teams want to consume updates.
6. A versioned archive. Old versions remain accessible at permanent URLs so a customer who signed in 2024 can prove what was disclosed at that time.

When a customer objects: a workflow that does not break trust

Most objections never happen. When they do, they tend to fall into three patterns and each has a clean response.

• Data residency objection. "This subprocessor stores in the US and we are EU-only." Response: confirm the data flow, document the legal basis (SCCs, adequacy decision, supplementary measures), and offer to walk the customer through your transfer impact assessment.
• Sectoral objection. "This subprocessor has had recent enforcement action against them." Response: share your due diligence file, your monitoring plan, and your timeline for re-evaluation. Sometimes the answer is to find an alternative.
• Categorical objection. "We do not allow any subprocessor we have not contracted with directly." Response: this is an enterprise-only conversation and usually requires a custom addendum.

The common thread: respond fast, document the decision, and update the subprocessor's row in the table with the date of the objection and the resolution. The audit trail is what protects you when the next customer asks why.

Where Termerly fits in the subprocessor workflow

Termerly is a free generator and host for legal pages. It is not a vendor monitoring service and it does not crawl your subprocessor list to detect changes for you. It does, however, handle the part of the job that breaks most often, which is the durable record.

• You write your Subprocessors page in the editor, using a table for the columns. The editor renders cleanly on the public legal center, so the page is readable on mobile and indexable for search.
• Every time you publish, the version history captures an immutable snapshot. A customer who needs to prove what your subprocessor list said in March 2025 can open the permalink for version 7 and see exactly that.
• The diff viewer highlights additions and removals between any two versions. Send a customer the URL of the comparison page and they have everything they need to evaluate the change.
• If you run several SaaS products from one account, each project keeps its own subprocessor page. The lists do not bleed into each other.

Conclusion

GDPR Article 28 has not gotten more lenient with time and the 2026 landscape (AI subprocessors, more cross-border transfers, sharper enforcement on transfer language) makes the table you publish more important, not less. The core work is the same as it was in 2018: list everyone, notify before changes, keep a record. The teams that fail at it almost always fail at the second part — silent updates to a webpage, no email, no diff, no archive. Fix the record-keeping and the rest follows.

If you do not have a Subprocessors page yet, the fastest way to ship one is to draft it in a tool that handles versioning and public URLs out of the box. Open a free Termerly project and create the page today. Send the link to your three biggest customers as a goodwill move. It is the kind of thing that turns into a procurement advantage the next time they renew.