Subprocessor list template for SaaS vendors

What is a subprocessor and why do buyers ask about them?

A subprocessor is any third-party organization that processes personal data or sensitive information on your behalf. If you use AWS for hosting, Stripe for billing, SendGrid for transactional email, or Mixpanel for product analytics, those are all subprocessors. They do not work for your company directly, but they handle data that belongs to your customers.

Buyers and procurement teams ask about subprocessors for three reasons. First, they need to understand the full chain of custody for their data. If a buyer uploads customer records into your platform, those records may flow through your primary database, a backup service, an analytics pipeline, and a customer-support tool. Each link in that chain is a risk surface the buyer must evaluate.

Second, regulatory frameworks like GDPR, the UK Data Protection Act, and various US state privacy laws require that data controllers inform data subjects about subprocessors. A published subprocessor list is the standard way to meet that obligation.

Third, enterprise buyers often run their own vendor-risk assessments. They score each subprocessor on location, compliance certifications, and contractual protections. If your list is incomplete, outdated, or poorly formatted, the buyer either rejects your assessment or sends a follow-up questionnaire that adds days to the deal cycle.

The six fields every subprocessor list needs

A useful subprocessor list is more than a column of company names. Buyers want to see context. The six fields below are the minimum viable set that satisfies most procurement questionnaires. Each field answers a specific question the buyer is trying to evaluate.

Vendor name is obvious but worth getting right. Use the legal entity name rather than the product name. Write "Amazon Web Services, Inc." instead of "AWS." Legal teams and compliance databases match on entity names, and mismatches create unnecessary confusion.

Service purpose explains what the vendor does for you. "Hosting and compute" is better than "Infrastructure." "Transactional email delivery" is better than "Email." The purpose tells the buyer which part of their data is exposed and whether the function is critical to availability.

Data category describes what kind of information the subprocessor touches. Use standard labels like personal data, financial data, authentication data, analytics events, support tickets, and marketing contacts. If a vendor handles more than one category, list them all or split the row.

Location matters because data residency laws and cross-border transfer mechanisms depend on it. List the primary region where data is processed and stored, not just the vendor headquarters. AWS US-East-1 is different from AWS Frankfurt for GDPR purposes.

Security and compliance notes capture the certifications and controls that matter to buyers. SOC 2 Type 2, ISO 27001, PCI-DSS, and HIPAA are the most commonly requested. If the vendor publishes a security page or trust center of their own, link to it here.

DPA status tracks whether a signed Data Processing Agreement is in place. "Executed" means you have a countersigned DPA on file. "Pending" means you are still negotiating. "Not required" applies to vendors that do not process personal data. Buyers want to know that downstream contractual protections exist, not just that the vendor claims to be compliant.

Copyable subprocessor list template

Use the table below as a starting point. Copy the headers into a spreadsheet, replace the example rows with your real vendors, and publish the result on your trust center. Update it quarterly or whenever you add or remove a material subprocessor.

How to populate your list the first time

If you have never built a subprocessor list before, start with your cloud bill and your SSO directory. Every service you pay for is a candidate. Every integration in your identity provider is a candidate.

Go through each service and ask three questions. Does this vendor store, process, or transmit personal data on our behalf? Is the service material to our platform, meaning a failure or breach would impact customers? Would a buyer reasonably expect to see this vendor named in a security review? If the answer to any question is yes, add the vendor to the list.

Do not include incidental tools that touch no customer data. Your internal accounting software, your HR platform, and your office wifi provider are not subprocessors for buyer purposes. Including them clutters the list and makes you look like you do not understand the distinction.

For each vendor, fill in all six fields. If you are missing a DPA, mark it pending and set a reminder to chase the vendor. If you are unsure about the exact location of data processing, open a support ticket and ask. Most cloud providers answer this within a day.

Keeping the list accurate over time

A subprocessor list is only useful if it is current. Stale lists are worse than no lists because they signal operational sloppiness. Set a simple maintenance rhythm and stick to it.

Review the list quarterly. Add new vendors you adopted since the last review. Remove vendors you churned. Update locations if a vendor opened a new region and you migrated workloads. Refresh certification dates if a vendor renewed SOC 2 or ISO 27001.

Set a trigger-based update rule as well. Whenever you sign a contract with a new vendor that processes customer data, add it to the list before the vendor goes live. Whenever you offboard a vendor, remove it within five business days.

Version the list. Add a "last updated" date at the top so buyers can see freshness at a glance. If you use a trust center platform, the publish date usually handles this automatically. If you use a spreadsheet, write the date in a header cell and update it every quarter.

Where to publish your subprocessor list

The best place for a subprocessor list is a public section on your trust center or security page. Buyers should not need to sign an NDA or send an email to see it. Transparency here builds confidence.

If you use VendorLens, add a "Subprocessors" section to your trust page and paste the table into the body. The section renders cleanly on desktop and mobile, and buyers can self-serve without creating friction for your team.

If you do not have a trust center yet, publish the list as a dedicated page on your marketing site at /subprocessors or /legal/subprocessors. Link to it from your privacy policy, your DPA, and your footer. Make it discoverable.

Avoid PDF-only distribution. PDFs are hard to search, hard to copy into procurement systems, and hard to update. A web page or a well-formatted table is almost always better. If you must provide a PDF, generate it from the same source of truth so it stays in sync with the web version.

Handling subprocessor notifications under GDPR

GDPR Article 28 requires that data controllers inform data subjects about subprocessors and obtain prior authorization for any changes. In practice, most SaaS companies satisfy this through a combination of contract language and proactive communication.

Your Data Processing Agreement should include a clause that gives you the right to use subprocessors without obtaining individual consent for each one, provided you maintain an up-to-date list and notify customers of material changes. This is standard language and most enterprise buyers expect it.

When you add a new material subprocessor, send a notification email to your customers with a thirty-day advance notice. Include the vendor name, service purpose, data category, location, and a link to the updated subprocessor list. Keep the email short. Buyers do not need a whitepaper; they need visibility.

If you remove a subprocessor, a shorter notice is fine. A brief email or a changelog entry on your trust center is usually sufficient. The goal is to maintain an audit trail that demonstrates ongoing diligence.