TL;DR. Under GDPR Article 28(2) and almost every standard DPA, adding a new sub-processor that will process customer personal data triggers a notification obligation. The market-standard window is 15 days' advance notice, during which the customer may object on reasonable data-protection grounds. The template below is ready to send.

Where the obligation comes from

The legal basis is GDPR Article 28(2), which permits processors to engage sub-processors only with the controller's prior specific or general written authorisation. Where general authorisation is used (the practical default in SaaS), the processor must "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."

The regulation doesn't specify a notice period, but the market has settled on 15 days as the standard objection window. This figure appears in the Data Privacy Framework Principles, most major SaaS DPAs (AWS, Google Cloud, Microsoft, Salesforce, Twilio, Stripe), and in our own DPA Section 4.3. Below 15 days is contractually risky; above 30 days is uncommon outside of regulated sectors.

When the notification obligation triggers

Notification is owed when you (the processor) are about to engage a new sub-processor that will process customer personal data. In practice, this means:

  • Adding a new sub-processor — e.g., moving from one email-delivery vendor to another.
  • Replacing an existing sub-processor — even if the function is unchanged.
  • Moving a sub-processor's data-residency region — arguably triggers notification because it changes the transfer mechanism analysis.

Notification is not owed for:

  • Internal personnel changes within an existing sub-processor.
  • Vendors that don't process customer personal data (your internal accounting platform, e.g.).
  • Vendors that fall under controller-to-controller relationships rather than processor-to-sub-processor (Stripe, Google as a calendar host for your sales team's bookings).

What goes in the notification

A defensible notification covers:

  1. Identity of the new sub-processor — legal name and primary place of business.
  2. What the sub-processor will process — categories of personal data, categories of data subjects, processing purpose, frequency.
  3. Where the data will be processed — country / region. This is essential for the customer's transfer mechanism analysis.
  4. The 15-day objection window stated explicitly, with the cutoff date.
  5. How to object — the email address and the format you'll accept.
  6. The intended effective date after which the new sub-processor will be live.
  7. Optional but recommended: a link to your updated sub-processor list (e.g., privacyautomated.ai/subprocessors) so the customer can verify the change in context.

The template

Ready-to-send email
Subject: [Privacy notice] We're adding a new sub-processor — 15 days to object

Hi {{Customer name}},

We're writing to give you advance notice of a new sub-processor that
will process personal data on your behalf as part of the Privacy
Automated platform.

  Sub-processor:       {{Vendor legal name}}
  Purpose:             {{What they do — e.g., "outbound transactional
                       email delivery for escalation notifications"}}
  Data processed:      {{Categories — e.g., "recipient email addresses,
                       email content, delivery metadata"}}
  Region:              {{Country / data-residency region}}
  Intended start date: {{Date 15+ days from this email}}

Why we're adding them
{{One short paragraph: what problem this solves or what capability
this adds. Customers appreciate context.}}

Your right to object
You may object to this change on reasonable data-protection grounds
within 15 days of this notice — by {{Date 15 days from this email}}.
Send objections to info@privacyautomated.ai with "Sub-processor
objection" in the subject line.

If we cannot reasonably accommodate your objection, you may terminate
the affected portion of the Services per Section 4.4 of our DPA and
receive a pro-rata refund of prepaid Fees for the unused portion.

What happens after the window
If we don't hear from you by {{Date}}, the sub-processor will be added
to our authorised list effective {{Date 15+ days from this email}}.
Our current sub-processor list is always live at
https://privacyautomated.ai/subprocessors.

Questions, written confirmation, or DPA matters — just reply.

— The Privacy Automated Team
Privacy Automated LLC · Florida, USA

Handling customer objections

Most notifications get zero objections. When you do get one, the response depends on the basis:

Reasonable data-protection grounds — e.g., the new sub-processor is in a country the customer can't lawfully transfer data to, or the sub-processor's security posture is weaker than the one being replaced. Engage in good-faith dialogue. Common resolutions: choose a different sub-processor for that customer (rare but possible for enterprise contracts), defer the change until a remedy is in place, or accept the customer's termination right under the DPA.

Commercial or preference grounds — e.g., "we just don't like Vendor X." Not a "reasonable data-protection ground." Respond politely, explain the basis is contractually narrow, proceed with the change.

Late objection (after the 15-day window) — The change is already effective. You can still consider the concern but the DPA's termination remedy no longer applies. Document the timing.

Process pitfalls that show up in audits

No proof of delivery. Send notifications from an address that produces a deliverable receipt (transactional-email provider with bounce tracking). "I emailed you" is a weak audit trail without evidence the email landed.

Notifying after the change has already happened. Defeats the entire point of the 15-day window. Set up the change request as "approved pending notice period" so the deployment can't happen before the objection window closes.

Notifying only some customers. Maintain a single notification list of every customer entitled to the notice. If a customer signs up between when you sent the notice and the effective date, send them the notice individually before they go live.

Not updating the published sub-processor list. Customers who didn't get the email may check the live list. Update it on the same day the change takes effect — our list lives at privacyautomated.ai/subprocessors and is updated in lockstep.

How Privacy Automated handles this

We're building a sub-processor change notification generator that produces a fully-formed email from your sub-processor inventory — pre-filled with the vendor name, region, purpose, data categories, and the 15-day cutoff. See it on the free tools section of our home page. The product itself maintains your live sub-processor list, tracks customer notification subscriptions, and produces the audit trail of who was notified when.

Maintain your sub-processor list in one place.

Live published list, notification audit trail, integrated with your DPA workflow. Free 14-day trial, no credit card.

Start free trial →