Primer

What is a subprocessor notice?

A subprocessor notice is the customer-facing update you send when a SaaS vendor changes. It explains who the vendor is, what it does, what data may be involved, and when the change takes effect.

Operational guidance, not legal advice.

This page explains the workflow in plain language. Your DPA, privacy policy, procurement terms, and counsel decide the actual notice obligation.

Plain-English definition

In practice, a subprocessor notice is a record that tells affected customers, "We are adding, replacing, or changing a vendor that may process customer data." Teams use it to stay aligned with DPA notice obligations and to avoid scrambling after the vendor is already live.

The notice usually works best when it is tied to one specific vendor change instead of a generic vendor list update. That makes the timing, the recipients, and the evidence trail much easier to manage.

When it matters

New vendor added

You bring in a subprocessor for support, email delivery, analytics, infrastructure, or other customer-data work.

Vendor replacement

You swap one provider for another and need to explain what changed and whether the customer-facing risk profile changed too.

Processing region changes

You move some processing to a different country or region and need to keep the customer update consistent with the agreement.

Different customers, different terms

Enterprise customers may have different DPA versions or notice windows, so segmentation matters before you send anything.

What to include

  • Vendor name and public URL.
  • What the vendor does in customer-facing language.
  • The types of customer data that may be processed.
  • The processing region or transfer context.
  • The notice date and planned effective date.
  • The objection window or response deadline.
  • A link to the current subprocessor page.
  • The internal owner and review path.

Simple examples

Example

Email delivery vendor

You add a transactional email provider that processes customer email addresses and message metadata. The notice should explain the service purpose, date, and objection path.

Example

Infrastructure swap

You replace one cloud or database provider with another. The notice should state what changed, whether the region changed, and who owns the approval record.

Example

Support tooling update

You add a support or ticketing vendor that can see customer contact data. The notice should be routed only to the affected customer segment.

Fast checklist before sending

1. Confirm the agreement

Check the DPA or customer contract for the notice period, recipient rules, and any objection language.

2. Segment the audience

Separate customers by DPA version, region, or special procurement terms before drafting the message.

3. Draft the notice

Write a short, plain-language notice with the vendor facts, timing, and objection process.

4. Save proof

Keep the final copy, send timestamp, recipient list, page screenshot, and any objection responses.

Need the workflow, not just the definition?

Run the self-audit to see whether your current packet is ready, then use Pricing to pick the kit that fits the amount of cleanup you still need.