Subprocessor List Best Practices: How SaaS Companies Should Disclose and Maintain Them

Overview

The goal of a subprocessor list is simple: give customers and internal teams a clear, current view of the third parties that help you process customer or personal data. In practice, that means more than publishing a vendor page with a few recognizable names. A strong SaaS subprocessor disclosure should reflect your actual operating environment, including hosting providers, support tooling, analytics services, communications platforms, and any other vendors that process data on your behalf in the delivery of the service.

For privacy compliance and vendor transparency, the list should be accurate enough to answer common questions without forcing every customer into a long back-and-forth. It should also be maintainable. The biggest failure mode is not bad formatting; it is drift. Procurement approves a new tool, engineering enables a new feature, support adopts a new workflow, or infrastructure expands into a new region, and the public list never catches up.

A practical list usually answers five baseline questions for each vendor:

• Who is the subprocessor?
• What service do they provide?
• What categories of data might they process?
• Where is processing or hosting likely to occur?
• How will customers learn about material changes?

That does not mean every list must expose deep architectural detail. The point is clarity, not over-disclosure. You want enough information to support privacy vendor list transparency and customer due diligence, while keeping the content stable and understandable for non-lawyers.

If your team is early stage, start lean. If your SaaS product is growing, treat the subprocessor register as part of your operational compliance system, alongside your vendor intake process, data inventory, and contract records. Teams pursuing SOC 2 readiness or working toward an ISO 27001 checklist often discover that a reliable vendor register reduces audit friction far beyond privacy reviews alone.

Step-by-step workflow

Use this workflow to create a subprocessor list that can survive real operational change.

1. Define what counts as a subprocessor for your service

Before collecting vendors, align on scope. Many SaaS teams mix together all vendors, all business tools, and all service providers. That creates noise. Start by identifying the vendors that process customer or personal data on your behalf in connection with delivering the product or supporting the service.

To make this practical, separate vendors into three buckets:

• Likely subprocessors: hosting, cloud infrastructure, support platforms, transactional email, monitoring tools with customer identifiers, CRM or customer success tools used in account support, file storage, messaging, fraud prevention, and outsourced support or operations providers.
• Maybe subprocessors: product analytics, session replay, AI-assisted support tools, logging platforms, feature flag services, and embedded third-party services. These often depend on how the implementation works and what data is sent.
• Usually out of scope for the public subprocessor list: internal HR systems, payroll tools, applicant tracking, office vendors, or finance systems that do not process customer data as part of delivering the SaaS service.

Document your internal decision rule. This helps when teams ask why one vendor appears publicly and another does not.

2. Build from your actual systems, not memory

Do not start with the privacy policy and assume it is complete. Instead, pull inputs from the places where vendors are introduced or configured:

• procurement records
• security reviews
• accounts payable or SaaS management tools
• engineering architecture docs
• customer support admin consoles
• data flow maps and records of processing activities
• DPAs and vendor contracts

This is where a subprocessor list becomes an operational workflow rather than a writing exercise. The cleanest process is to assemble an internal master register first, then publish a customer-facing version from it.

3. Create a master subprocessor register

Your internal register should contain more detail than the public page. A useful structure includes:

• vendor legal name
• service name, if different
• business owner inside your company
• function or purpose
• whether the vendor is customer-facing, backend only, or optional by feature
• data categories involved
• type of processing, such as hosting, support, messaging, analytics, storage, or monitoring
• primary processing regions
• contract status and DPA status
• security review status
• date added
• last reviewed date
• public disclosure status
• customer notice required yes or no

This internal register does two jobs. It supports your privacy compliance process, and it reduces scramble during audits and customer questionnaires. If you already use a broader vendor inventory, add subprocessor-specific fields rather than creating a disconnected spreadsheet. For teams tightening vendor controls, this should pair well with a vendor security assessment checklist.

4. Decide what the public list will show

Your public SaaS subprocessor disclosure should be simpler than the internal register. A practical public format often includes:

• subprocessor name
• service provided
• general purpose
• location or processing region, where useful
• link to vendor site or trust documentation, if appropriate
• effective date or last updated date

Some companies also include categories of data processed. That can be helpful if kept high level, such as account data, support content, usage data, or service metadata. Avoid vague labels like “various data” that add little value.

If certain vendors are optional, feature-specific, or customer-configurable, label that clearly. Customers want to know whether a listed vendor is always used or only relevant for a feature they may not enable.

5. Attach ownership before you publish

The subprocessor list usually fails because everyone thinks someone else owns it. Assign clear roles:

• Privacy or legal: scope guidance, contract review, customer notice approach
• Security or compliance: vendor review checkpoints, evidence, risk tracking
• Engineering or platform: hosting, infrastructure, observability, region changes
• Procurement or finance: new vendor visibility
• Support or operations: support tooling and workflow changes
• Web or content owner: updating the published page

Even in a small company, name one accountable owner. Shared responsibility is fine; unowned responsibility is where lists age out.

6. Link the list to onboarding and change management

This is the most important operational step. Do not rely on quarterly memory sweeps. Instead, make subprocessor review a required checkpoint in the workflows that introduce vendor change.

Add a simple yes-or-no prompt to your vendor intake form: “Will this vendor process customer data or personal data on our behalf in delivering or supporting the service?” If yes, route the request through privacy, security, and the owner of the public list.

Also trigger review when:

• a new infrastructure region is enabled
• a support workflow sends tickets or attachments to a new tool
• product analytics scope expands
• a feature introduces embedded third-party processing
• an acquisition or migration changes backend service providers
• an AI or automation tool is connected to support, chat, or customer content

If your team already maintains formal policies, it helps to embed this rule in your vendor management and security documentation. For lean teams, a lightweight approach can still work if the expectation is documented in your broader policy set, such as a security policy starter set.

7. Define your notice process for changes

Subprocessor notice requirements vary by your contracts and the commitments you make to customers, so avoid treating notice as a generic email blast. Instead, define a process that aligns with your terms, DPA language, and operational capability.

Your internal procedure should answer:

• What counts as a change that requires customer notice?
• Who approves the notice?
• How is notice delivered: email, customer portal, trust center, or subscription page?
• What lead time will you aim for before a change takes effect?
• How do you log that notice was sent?

Be careful not to promise a notice mechanism publicly that you cannot reliably operate. A simple, repeatable process is better than a detailed process that depends on manual heroics.

8. Publish in a format customers can actually use

The best public subprocessor pages are boring in a good way. They load fast, explain the purpose of the page, present the current list clearly, and include a last updated date. If you support notice subscriptions, make the sign-up process obvious and test it.

Avoid putting key disclosures in a PDF unless there is a strong reason. A normal web page is easier to update, compare, and review. It also fits better with general website compliance maintenance. If you are improving the wider trust surface of your site, review your broader website security checklist as well so the page itself is part of a well-managed environment.

Tools and handoffs

You do not need a complex platform to manage a solid privacy vendor list, but you do need dependable handoffs.

A practical tool stack

• Master register: spreadsheet, database, GRC tool, or vendor management platform
• Source inputs: procurement form, security review tracker, architecture inventory, and DPA repository
• Public publishing: website CMS, trust center, or docs site
• Notifications: shared mailbox, customer communication tool, or trust portal subscription workflow
• Evidence: changelog, approval record, and archived versions of the published list

The key is data flow, not tooling prestige. A spreadsheet can be enough if it has an owner, review cadence, and clear intake path. A fancy system with weak intake discipline will still produce stale disclosures.

Recommended handoffs

Use a simple sequence:

1. Requester proposes a new vendor or feature change.
2. Procurement or system owner flags possible customer-data processing.
3. Security reviews vendor risk and technical controls.
4. Privacy or legal reviews contractual and disclosure implications.
5. Subprocessor owner updates internal register.
6. Web or trust owner updates public page if needed.
7. Customer notice is sent if required by contract or policy.
8. Evidence of the update is stored for audit and support reference.

For small teams, one person may wear several of these hats. The point is to preserve the sequence so nothing is skipped. This same discipline helps with adjacent processes like access reviews and incident planning; see the access control policy checklist and incident response plan checklist for related operational controls.

Quality checks

Before you consider the list healthy, test it against a few concrete checks.

Coverage check

Compare the public list to your internal vendor register, major architecture components, support stack, and contracting records. If your app depends on a service category that is missing entirely, investigate.

Data flow check

For each listed vendor, confirm the description still matches reality. A tool that started as simple monitoring may now receive user identifiers, logs, attachments, or support transcripts.

Region check

If you expanded infrastructure or enabled new service regions, confirm the list reflects that change where relevant. This is especially important when regional hosting is part of customer expectations.

Contract check

Make sure the vendors on your list align with your DPAs, customer agreements, and any notice commitments you have made. If the legal documents say one thing and the public list says another, customer diligence will uncover it quickly.

Ownership check

Every listed vendor should have an internal owner who can answer basic questions. If nobody can explain why a vendor is there, whether it is still active, or what data it handles, review it.

Publication check

Verify links work, the page has a visible last updated date, and archived versions are retained internally. If you offer subscription notices, test the sign-up and delivery path periodically.

Customer usability check

Ask whether a customer security reviewer could understand the page in a few minutes. If the answer is no, simplify labels, clarify optional vendors, and reduce legal clutter.

When to revisit

Revisit your subprocessor list whenever the underlying service changes, not just on a calendar reminder. A quarterly review is useful, but event-based updates matter more.

Update or review the list when:

• you onboard a new vendor that may process customer or personal data
• you replace a hosting, support, messaging, or analytics provider
• you launch a feature that changes customer data flows
• you expand into a new region or move workloads
• you connect AI or automation tools to support or customer content
• you change your DPA, privacy notice, or customer notice commitments
• customers repeatedly ask about a vendor that is not clearly disclosed
• your audit, SOC 2 readiness, or ISO review exposes inventory gaps

A practical cadence for most SaaS teams is:

• At change time: review whenever a new vendor or feature is introduced
• Monthly: scan procurement and engineering changes for missed updates
• Quarterly: reconcile the public list against the internal register
• Annually: review scope rules, notice process, and page design for clarity

If you want a simple action plan, start here this week:

1. Create or clean up your internal subprocessor register.
2. Assign one accountable owner.
3. Add a subprocessor question to vendor intake and change management.
4. Publish a clear customer-facing page from the register.
5. Set a recurring reconciliation review.
6. Archive each public update and keep evidence of approvals and notices.

A good subprocessor list does not need to be elaborate. It needs to be trusted, current, and connected to the way your SaaS product actually changes. When managed as a living operational asset, it supports privacy compliance, reduces customer friction, and makes vendor transparency part of normal team workflow instead of a last-minute scramble.