Registora

Guide / How-to

Updated 25 May 2026

How to build a subprocessor page

A subprocessor page is a public list of the third parties your company uses to process customer data. To build one, inventory every vendor that touches personal data, list each with its purpose and processing location, publish it at a stable public URL, and keep it current as your stack and your upstream providers change.

Key facts

  • 01A subprocessor page lists every third party that processes personal data on your behalf, with the purpose and the location of processing for each.
  • 02There is no mandated layout, but a clear table of name, purpose, and location is the de-facto standard buyers and auditors expect.
  • 03Host it at a stable, public URL (commonly /subprocessors or a subdomain) so it can be referenced in your DPA and found in a security review.
  • 04The page only satisfies GDPR Article 28(2) if it stays current - a stale list is worse than none because it misrepresents who actually handles the data.
  • 05Your own list is only as fresh as the last time you checked your upstream providers, who change their own subprocessors without telling you.
§ I

What a subprocessor page is for

A subprocessor page is a public document that lists the third parties your company relies on to process personal data on behalf of your customers. If you run a SaaS product, those third parties are everywhere in your stack: the cloud provider that hosts your database, the service that sends your transactional email, the payment processor, the analytics tool, the AI API that receives user content. Each of those is a subprocessor.

The page exists for two audiences. The first is your customers - the data controllers - who have a right under GDPR Article 28 to know who you engage with their data. The second is enterprise procurement and security teams, who will ask for a current subprocessor list during any serious purchasing review and will treat a missing or outdated one as a red flag.

A good page turns a recurring compliance question into a one-line answer: “our subprocessors are listed here, kept current, and you will be notified before they change.” That is the whole job.

§ II

Inventory every vendor that touches personal data

Start by listing every external service that processes personal data under your instructions. The test is simple: does this vendor receive, store, or otherwise handle data about your users or your customers' users, in order to deliver a service to you? If yes, it belongs on the list. Walk through your stack category by category:

  • -Infrastructure and hosting - your cloud provider, CDN, managed database, object storage.
  • -Communications - transactional email, SMS, push notifications, in-app messaging.
  • -Payments and billing - your payment processor, invoicing, tax and subscription tooling.
  • -Product and analytics - product analytics, error monitoring, session tooling, feature-flag services.
  • -Support and AI - help-desk platforms, live chat, and any AI or LLM API that processes user content.

Pure internal tools that never receive customer personal data - a code repository with no user data in it, for example - do not belong on the list. When in doubt, ask whether a data subject's information could reach that vendor; if it can, list it.

§ III

List each one with purpose and location

There is no legally mandated format, but the convention buyers and auditors expect is a simple table with three columns: the subprocessor, what it does for you, and where it processes the data. Many companies add the legal entity name and the categories of personal data involved. A workable row looks like this:

Subprocessor        Purpose                         Location
-----------------------------------------------------------------
Stripe, Inc.        Payment processing              United States
Amazon Web Services Cloud hosting and storage       Ireland, USA
Resend, Inc.        Transactional email delivery    United States

Keep the purpose specific and the location honest - the location signals whether an international transfer is involved, which has its own GDPR consequences. Resist the urge to be vague to look smaller; an auditor reads “various infrastructure providers” as something to hide. Precision reads as competence.

§ IV

Publish it, then keep it current

Host the list at a stable public URL - a path like /subprocessors on your main site, or a dedicated subdomain such as trust.yourcompany.com. You will reference this URL from your DPA and hand it to procurement teams, so it must not move or 404. Avoid hosting the canonical list inside a PDF or a Notion page that quietly falls behind; it should be a real, indexable web page.

The genuinely hard part is staying current. Your own additions are easy to remember - you control them. What catches companies out is that their upstream providers change their own subprocessors on their own schedules, and your list silently goes stale the moment they do. Stripe adds a new vendor, AWS opens a region, your email provider switches a downstream service: none of them tell you, and your page now misrepresents who actually touches the data. See the upstream providers Registora tracks and how often they change.

Manually re-reading a dozen provider pages every month is the failure mode almost everyone falls into - it works for a quarter, then quietly stops. And remember that adding or replacing a subprocessor is not just a page edit: under general written authorisation you owe your customers prior notice and a chance to object before the change takes effect.

FAQ

Frequently asked questions

Is a subprocessor page legally required?
GDPR does not name a "subprocessor page" as such, but Article 28(2) requires a processor operating under general written authorisation to maintain a list of its subprocessors and to give the controller prior notice of changes. A public page is the standard, practical way to meet that obligation: it is the list, it is discoverable, and it can be referenced directly from your Data Processing Agreement. Without it, you have to circulate and re-circulate the list privately every time it changes, which does not scale.
What should each entry on the page include?
At minimum: the subprocessor name, what it is used for (the processing purpose), and where it processes data (the country or region). Many companies also include the legal entity name, the categories of personal data involved, and a link to that subprocessor's own DPA or privacy page. The location matters because it signals whether an international transfer is involved, which carries its own GDPR requirements. Keep entries factual and specific - "AWS - cloud hosting and storage - United States and Ireland" is more useful than "infrastructure provider".
Where should I host the page?
At a stable, public URL that will not move. The two common conventions are a path on your main site (yourcompany.com/subprocessors) or a dedicated subdomain (trust.yourcompany.com or privacy.yourcompany.com). The exact URL matters less than its stability: you will cite it in your DPA and in security questionnaires, and broken links to a subprocessor list read as neglected compliance. Avoid burying it inside a PDF or a Notion page that rots - it should be a real web page that search engines and procurement teams can reach.
How do I keep the page current without it becoming a chore?
The hard part is not your own changes - it is your upstream providers changing theirs. Stripe, AWS, Vercel, and the rest update their own subprocessor lists on their own schedules, and your list silently goes stale when they do. Manually re-reading a dozen provider pages every month is the failure mode most companies fall into. The durable answer is to monitor those upstream lists automatically and amend your page when they change, which is exactly what Registora is built to do.
Do I need to notify customers when the page changes?
Yes, when you add or replace a subprocessor. Under general written authorisation, the prior-notice and right-to-object mechanism is what makes the arrangement lawful, so a silent edit to the page is not enough on its own. The page is the living record; the notification is the active step that gives controllers the chance to object before the change takes effect. See our guide on notifying customers of a subprocessor change for how to do that well.

This guide is general information only and does not constitute legal advice. For advice on your specific situation, consult a qualified legal professional.

Your turn

Keep your subprocessor register current - automatically.

Registora hosts your register on your own domain, monitors every upstream provider for changes daily, and drafts the customer notification when one updates.

Start your register →Audit your site