What is a sub-processor? The subprocessor list for a small SaaS: who belongs on it, the agreement each one needs, and how to publish it

The day a business customer’s security questionnaire lands, one row asks for your sub-processor list, and you may not have one yet. What is a sub-processor? Under Article 28 of the EU and UK GDPR it is any vendor your SaaS passes customer personal data to while acting as the customer’s processor: the host, the database, the email sender, the error tracker, the model API.

What is a sub-processor, and what a subprocessor list is

A sub-processor is another processor that a processor engages to help handle personal data on a controller’s behalf. For a B2B SaaS that means most infrastructure vendors. GDPR Article 28 requires the controller’s written authorization, a contract passing the same obligations down, and, under a general authorization, notice of changes. The first processor stays fully liable.

Keeping the vendor list is one part of how to manage SaaS data compliance, and the part a questionnaire row asks for by name. The chain behind it has three roles, and a B2B SaaS sits in the middle.

The rule itself is short. EU GDPR Article 28(2) opens: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” It goes on: “In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.” EU GDPR Article 28(4) adds that the same data protection obligations “shall be imposed on that other processor by way of a contract or other legal act”, and that if it fails, “the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations”. The whole of Article 28 of the EU GDPR fits on one screen.

For the UK, the current UK GDPR text on legislation.gov.uk, read on 3 October 2026, keeps Article 28(2) word for word and reads “domestic law” in 28(4) where the EU text has “Union or Member State law”. The Data (Use and Access) Act amendments of 2025 and 2026 changed paragraphs 28(5) and 28(8), not these two.

No subprocessor definition appears in the regulation itself. Article 4(8) defines a “processor”, Article 28 speaks only of “another processor”, and the ICO glosses that phrase on the ICO’s page for processors as “another processor (ie a sub-processor)”. The word is used throughout the EDPB’s guidelines on controllers and processors, which give sub-processors their own section, and in the European Commission’s standard contractual clauses, whose Clause 9 is headed “Use of sub-processors”. Contracts and questionnaires often drop the hyphen and write subprocessors; the vendors are the same.

A subprocessor list is the published table that makes a general authorization workable. The EDPB says that, for the controller to decide whether to authorize subcontracting, the processor will have to provide a list of intended sub-processors “including per each: their locations, what they will be doing and proof of what safeguards have been implemented”. On a small SaaS that becomes five columns: the vendor’s name, what it does for you, what personal data it touches, where it processes that data, and the date the list last changed. A questionnaire row asking you to name your data subprocessors wants exactly that table.

Keep required and good practice apart. Where the GDPR applies, three things are required by Article 28: the authorization, the flow-down contract, and the change notice under a general authorization. Nothing in the GDPR says the subprocessor list must be public. Publishing it on your site is the common way to give every customer the same list and the same notice, and it is what reviewers expect to find, but that is my reading of practice, not a rule in the text.

You are also a controller in your own right, for your account, billing and marketing data. Vendors used only for that, such as a newsletter tool that never sees the product, are your processors, not sub-processors. I’d still list everything on one page and mark which is which, because one page is easier to keep current than two. This page explains the rule and the usual practice; it is not legal advice, and it cannot tell you whether a given contract meets the law.

A worked subprocessor list for an AI-built SaaS stack

A subprocessor list for an AI-built SaaS usually names the host, the database, the auth service, the email sender, the error tracker, product analytics, the support desk and the model API. The model API counts whenever prompts carry customer data. Your code host and accounting tool stay off.

The test is whether a vendor processes personal data on your behalf, under your instructions, as part of what you provide to your customer, and the article on signing a customer’s DPA explains how to tell whether a vendor belongs on the list on the ICO’s wording. This section only applies it, row by row. The cells saying whether a vendor touches customer personal data and whether it goes on the list are my reading of typical use, and the vendor names illustrate a category; they are not recommendations.

The model API row is what people mean by an AI subprocessor: a model provider that receives customer data inside prompts. What leaves the app, and how to send less of it, is the subject of how to redact personal data before LLM calls; each model vendor’s retention terms are compared in zero data retention for AI features.

Payments need their note. Stripe’s DPA says that when it processes personal data as a processor “it is acting as a Data Processor on behalf of User, the Data Controller”, and that when it acts as a controller it “has the sole and exclusive authority to determine the purposes and means” of that processing, for purposes such as fraud detection. Stripe’s data processing agreement names both roles, so your row can say which applies to what.

Whether the builder platform your app was made on counts is a question the article on signing a customer’s DPA answers in its FAQ. The tools that never touch the product stay off: your code host, your design tools, your accounting software, and an analytics tag on the marketing site that never sees a logged-in customer.

Then come the vendors beneath your vendors. Supabase says choosing an EU region “pins these services to that exact AWS region”, and Vercel’s own sub-processor list names Amazon Web Services for “Hosting, storage and generative AI services”. AWS in turn publishes AWS’s sub-processor list, which it says depends on “the AWS Region the customer selects and the particular AWS services that the customer uses”. Your list names the companies you contract with and links each one’s own list rather than copying it, so AWS, and the AWS subprocessors beneath it, stay on their own pages. The platforms’ own lists are read in detail in who is on Supabase’s subprocessor list, where Lovable’s subprocessor list is and the Replit subprocessor list your customer will ask for.

What goes wrong without it

A security questionnaire asking for subprocessors is where a missing list tends to surface. There are four ways it goes wrong; the reviewer and cost columns are my reading of how each one lands.

Row three breaks the Article 28(2) duty quoted above: no notice went out, so no customer had the chance to object. Reading those rows starts with security questionnaire examples, and how to respond to security questionnaires deals with answering them without overclaiming.

Regulators do look at the paper behind the list. In a final decision dated 28 December 2021, summarized in the EDPB’s register of final decisions, the French supervisory authority found that a payment service provider “had acted as data processor hiring sub-processors” for its merchant customers, and that it “had failed to provide a formal legal framework for the processing carried out by the sub-processors and had merely sent them a questionnaire with no binding force”. It fined the company EUR 180,000 for infringing EU GDPR Articles 28(3), 28(4), 32 and 34, the last two over a data breach in the same case. The lesson I take from it: the list is the written form of a promise already in every DPA you have signed, and a vendor added without it breaks the promise before anyone reads the list.

In the apps I audited, the data at stake was real: at least 5 of the 21 third-party apps exposed PII or PHI. Those 21 are the apps I audited in June and July 2026, 11 public apps audited in depth and 10 more held out and audited blind; they are a selected set, not a random sample or a rate for AI-built apps in general. A vendor you cannot name is one you cannot check. The agreement that asks for all of this is covered in the article on signing a customer’s DPA.

How to do it: build the list, paper each vendor, publish it

Four steps, in the order I’d work through them: build the list, get the agreement behind each name, answer the security questions the list raises, and publish it.

Build the list from the provider inventory

A subprocessor list is built from the app’s data map, not from memory. Beyond the keys the app runs on, vendors hide in the dependency manifest, outbound domains, the card statement, DNS records and the builder’s integrations panel. Each candidate gets the same test and five columns.

The data map GDPR reviewers ask for traces one user through storage, logs and providers, and every provider on that trace is a candidate. The evidence route in the article on signing a customer’s DPA comes first: the platform’s own list, the runtime keys, the builder’s agreement. These five places, as my working rule, catch what that route misses.

1. 01 The dependency manifest (package.json, requirements.txt): every SDK for analytics, email, error tracking or a model API.
2. 02 Outbound domains: the browser network tab on the live site, and the connect-src list in your Content-Security-Policy.
3. 03 The company card statement: every software charge, including the free tier someone upgraded once.
4. 04 DNS records: the mail senders named in your email records, and any CDN in front of the domain.
5. 05 The builder platform's integrations panel: connectors switched on months ago and forgotten.

For each candidate, apply the test, then fill the five columns: name, what it does, what data it touches, where it processes it, and the date. Put a date on the list as a whole, too, so a reader can tell how current it is.

GDPR third party requirements: what you owe each vendor in writing

GDPR Article 28(4) requires a contract or other legal act with every sub-processor that passes down the same data protection obligations as your customer’s DPA. In practice that means finding each vendor’s published DPA, confirming it covers your plan, and recording 3 things: the URL, the transfer mechanism, and the date you checked.

Article 28(9) adds that the contract “shall be in writing, including in electronic form”. What Article 28(3) puts in that agreement, point by point, and whether every vendor needs a separate one, are covered in the article on signing a customer’s DPA, in its section on what Article 28 puts in the agreement and in its FAQ. The question of what is a DPA agreement, and which of its clauses matter, comes before this table. Vendors on this kind of list usually publish a DPA that is accepted by click, by plan, or folded into their terms, so the work is finding it, confirming it applies to your account, and writing down where it lives.

The transfer column matters when a vendor processes data outside the EU or UK. Its DPA names the mechanism: the European Commission’s standard contractual clauses, the UK’s International Data Transfer Agreement (IDTA) or Addendum, or the EU-U.S. Data Privacy Framework where the vendor is certified. The ICO says the EU clauses “are not valid on their own for restricted transfers under the UK GDPR”, which is why UK transfers add the Addendum. Certification is checked against the Data Privacy Framework List on the Data Privacy Framework site, and the ICO’s checklist for the UK Extension asks you to confirm the US business is “signed up to the UK Extension” and that “the certification is active”. The rest is in the ICO’s international transfers guidance and the European Commission’s standard contractual clauses. On your published list, the location column is what a reviewer reads to judge all of this.

The right to audit clause comes from EU GDPR Article 28(3)(h), which the article on signing a customer’s DPA quotes, so this is only the vendor side of it. Sentry’s DPA says the parties intend “to rely ordinarily on the provision of the above audit reports”, allows an independent auditor the customer selects, says “You will be responsible for any costs associated with the audit”, and limits audits to once in any twelve-month period unless a data protection authority requires one or a data incident makes one necessary. Resend’s DPA offers “copies of certifications or reports” first, and an audit by the customer’s independent representative only if those are “not reasonably sufficient”. Your own customers’ DPAs will ask the same of you, so offer the same shape: documents first, an on-site audit only on cause, at the customer’s cost, with notice. That is common contract wording and good practice, not the text of the law.

Third-party security: the question behind the subprocessor list

Third-party security is the reviewer’s question about your vendors: who they are, how you checked them, what contract binds them, and what happens when one changes. For a two-person SaaS the answer is a five-line vendor management policy plus the published list it keeps current.

From your customer’s side, your vendors are their fourth parties. The third-party section of a questionnaire, in my reading of the pattern, asks four things: do you know who they are, did you check them before use, is there a contract, and what happens when one changes or has a breach. The questionnaire as a whole, and the vendor due diligence checklist read from the side that answers it, belong to the article on how to respond to security questionnaires.

A vendor management policy at two-person size fits in five lines, and the block below works as a template to adapt. This is my working rule, not a standard.

1. A vendor that will touch customer data is approved by a named owner before it is wired in.
2. Approval needs a published DPA, a current security attestation or security page,
   a known data location, and two-factor login on the company's account with the vendor.
3. The vendor goes on the subprocessor list and the data map the same day.
4. The list is reviewed every quarter, and whenever a dependency with network access is added.
5. A vendor's breach notice starts the company's own incident steps.

Quarterly is my working rule for line four, one common choice rather than a requirement; pick a cadence you will actually keep. On what is required: EU GDPR Article 28(1) says the controller “shall use only processors providing sufficient guarantees”, and the article prescribes no policy document. Security reviews often ask for one anyway, so I’d keep it next to the other controls in the MVSP baseline.

What is a trust center, and how to publish a subprocessor page

A trust center is the public page where a software vendor keeps its security and privacy documents for reviewers. By my working rule, a small SaaS needs 3 plain pages: a security overview, the subprocessor list with a last-updated date and a change-notice promise, and the privacy policy. Software for it can come later.

A large vendor’s trust center typically gathers the security overview, the sub-processor list, the DPA, the privacy policy, uptime history and a way to request reports under NDA. Smaller companies often call the same thing a trust page, and a UK buyer may write trust centre. The Trust Center inside Microsoft Office apps is something else: a settings panel with the same name. For the buyer’s side, what a trust page settles for a buyer is the part to read.

Link the three pages from the footer: /security, /subprocessors (or /legal/subprocessors) and /privacy.

To publish a subprocessor page, put the five-column table on it with a last-updated date, a line saying how customers are told of changes and how long they have to object, and an email address or form to subscribe to updates. AWS runs its own page this way: “if you subscribe for updates, AWS will notify you by email of changes to this page”.

The page is not the notice. The EDPB says it is “not sufficient for the processor to merely provide the controller with a generalized access to a list of the sub-processors which might be updated from time to time”, and that “the processor must actively inform the controller of any change to the list”. Neither Article 28 nor the ICO’s processor page sets a notice period. The EDPB asks that the contract fix a timeframe and that it be “reasonable”, and the European Commission’s clauses leave the gap as “[Specify time period]” for the parties to fill. Vendors pick their own: Resend’s DPA promises notice “at least fourteen (14) days in advance”, Sentry’s “thirty (30) days’ prior written notice”. Pick a period you can keep that matches the DPAs you have signed, send the notice before the new vendor receives any data, and keep the sent email. What two hosts put in writing is read in the Supabase article above and in how Vercel tells customers its subprocessor list changed.

Trust center software, sold by Vanta, Drata (which now owns SafeBase) and Conveyor among others, adds gated document requests and questionnaire automation. A security trust center of that kind earns its cost when reviews arrive weekly, not before; that is my reading. The trust pages that Base44 and Lovable host are covered in what Base44’s trust center claims and in the Lovable compliance article above.

How to verify it

A subprocessor list is verified with 5 checks: it matches the data map’s provider trace, it matches the privacy policy’s sharing section, every row has a working agreement link and a date, production traffic shows no unlisted vendor, and a test change notice reaches the subscriber address.

Each check can fail, and each leaves evidence you can keep.

1. 01 Three-way match: every provider on the data map's trace is on the list, or marked as your own processor with the reason, and nothing on the list is a vendor the app no longer uses.
2. 02 Policy match: every sub-processor category on the list appears in the privacy policy's section on who you share data with, and nothing in that section is missing from the list.
3. 03 Agreements: every row has an agreement URL and a date checked, and each link still opens the DPA.
4. 04 Traffic: on the production site, the network tab shows no domain that belongs to an unlisted vendor, and the host's environment variable names show no key for one.
5. 05 Notice: a test change notice sent to the subscriber address arrives.

To match the vendor list to the privacy policy, read the two side by side; the sharing section is part of writing a privacy policy for SaaS. The browser shows only the calls the browser makes. Server-side calls never appear in the network tab, so for those the environment variable names and the dependency manifest are the check. Keep the dated list, the agreement table, the policy diff, the network capture and the test notice, and run the checks again whenever a dependency with network access is added.

In the Production Hardening Sprint, deliverable 12.8 is verified the same way: we confirm the list matches the provider inventory and the privacy policy.

Where the sprint does this

Deliverable 12.8, Subprocessor list, is where we publish the list of vendors that process customer data, with the agreement in place for each, because every business customer’s security questionnaire asks for it and reviewers cross-check it against the privacy policy. The production readiness report then accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. Every item is listed in the published scope.

Common questions about sub-processors

Is Google Analytics a subprocessor?

It depends where the tag runs: on your marketing site Google Analytics is your own processor, and inside the product, recording your customers’ users, it is a sub-processor that goes on the list. Google says it “operates as a data processor for Google Analytics”, under Google’s data processing terms, which point to a published list of Google’s own subprocessors. The split between the two cases is my reading.

On the marketing site, the visitors are yours and you are the controller, so the tag belongs in your privacy policy rather than on the customer-facing list. Google’s help page also says it “prohibits customers from sending Personally Identifiable Information to Google Analytics”, so what it holds should be identifiers, not names.

Is AWS considered a subprocessor?

Yes, when your app runs on AWS directly and AWS hosts customer data, it goes on your list. If you use a host that runs on AWS, such as Vercel or Supabase, AWS is your vendor’s sub-processor: it appears on that vendor’s list, and AWS publishes its own list of the sub-processors it engages “on behalf of customers”. That reading of the chain is mine.

Is CloudFlare a subprocessor?

Yes, when it fronts the product. Cloudflare’s DPA says it processes personal data “as a Processor (or sub-Processor as applicable) on behalf of Customer”, including content “routed to, passed through, processed and/or cached on or within, Cloudflare’s network”. A CDN or firewall that terminates TLS for your app can see every request, so it belongs on the list, and Cloudflare keeps its own on Cloudflare’s sub-processor page.

What is the difference between a subprocessor and a subcontractor?

A subcontractor is anyone you pay to do part of your work; a sub-processor is a subcontractor that handles personal data on the controller’s behalf, which brings in Article 28. A freelance developer with production access is both, in my reading. The ICO frames it the same way, asking whether a processor can “sub-contract to another processor”.

Is a sub-processor defined in the GDPR?

No, the regulation has no definition of the word. Article 4(8) defines a “processor”, Article 28 speaks of “another processor”, and the ICO’s processor guidance reads that phrase as “another processor (ie a sub-processor)”. The working definition is therefore a processor that another processor engages to handle personal data for the controller.

Is a subprocessor a third party?

In everyday speech yes; in the GDPR’s own terms, no. EU GDPR Article 4(10) defines a “third party” as “a natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data”. A sub-processor is another processor, so it falls inside that exclusion; that is my reading of the two articles together.