Subprocessor list template: what small SaaS teams usually miss
A public subprocessor page should do more than name vendors. It should help customers understand what changed, what data may be involved, when the list was updated, and where to send questions.
This article helps organize a subprocessor list for customer communication and internal review. Your agreements, DPA, and counsel determine the exact disclosures and notice duties that apply.
Why the list matters
For a small SaaS team, the subprocessor page often becomes the evidence customers check before security review, renewal, or procurement approval. A vague page creates follow-up work because customers cannot tell whether a vendor affects their data or whether a recent change triggered notice rights.
The goal is not to publish sensitive internal architecture. The goal is to give customers a stable, understandable record of the vendors that may process their personal data.
Minimum public fields
Use consistent fields for every vendor so the page can be reviewed quickly and converted into a customer notice when needed.
- Vendor legal or public name.
- Plain-language service purpose.
- Data categories that may be processed.
- Processing region or transfer context.
- Status: active, planned, replacing, removed, or under review.
- Effective date for new or changed vendors.
- Page last updated date.
- Contact method for questions or objections.
Template table
| Vendor | Purpose | Data categories | Region | Status |
|---|---|---|---|---|
| Acme Email Cloud | Transactional email delivery | Customer names; email addresses | United States; European Union | Planned for 2026-05-20 |
| Northstar Analytics | Product usage analytics | User IDs; event metadata | United States | Active |
Keep the public table simple. Put internal approvers, reviewer notes, and evidence links in a private tracker instead of the customer-facing page.
Common gaps
No updated date
Customers cannot tell whether the page is current. Add a visible last updated date and preserve screenshots or page versions internally.
Only vendor names
A list of names does not answer why a vendor is used or what customer data may be involved.
No notice method
If a customer has questions or objection rights, the page should make the correct contact channel obvious.
No internal evidence trail
The public page should match a private record showing who approved the change, when notice was sent, and where proof is stored.
Private tracker fields
The internal tracker can hold more operational detail than the public page. Use it to prepare notices, answer procurement questions, and support attorney review.
- Change type: add, replace, remove, or update.
- Customer segment affected by the change.
- Notice date and objection deadline.
- Notice status: draft, approved, sent, closed, or blocked.
- Internal owner and reviewer.
- Evidence URL for the notice, page screenshot, approval note, or ticket.
- Review notes for legal, security, or procurement questions.
Before publishing an update
Run a short review before the page changes. This catches the mistakes that usually turn into customer follow-up later.
- Confirm the vendor purpose is written for customers, not engineers.
- Confirm data categories match the product use case.
- Check whether the effective date is after the objection deadline.
- Save the old page state before publishing the new one.
- Save the new page URL, timestamp, and screenshot after publishing.
Want the spreadsheet version?
NoticeKit includes a subprocessor list sheet, CSV format, notice copy, objection-window tracker, and evidence workflow for one vendor change.