Sub-processor change notice · checked

How to notify customers of a new sub-processor

Before the new vendor processes their data, send every customer whose DPA gives you a general written authorisation a notice that names the vendor, what it will do, which personal data it gets and where, and the day their window to object closes: usually 30 days, sometimes 14, as your DPA says. Then keep a record of who was told when. GDPR Art. 28(2) requires the notice; the window comes from your contract.

Five steps

  1. Find the change before it ships. A new SDK, API call or hosting provider in a pull request is the moment the duty starts, not the deploy and not the invoice.
  2. Check your DPA's window. Usually 30 days, sometimes 14 or 10; some DPAs ask for 'prior notice' with no number. Count from the day the notice is sent.
  3. Send the notice to every customer under a general written authorisation. By email, and on the page your DPA names; a subscribe form on your list page is how most vendors reach the people who asked.
  4. Keep the record. Who was told, on which day, by which channel, and any objection and its outcome. It is what you show an auditor or a customer who says they were not told.
  5. Update the list on the start date, with the vendor's 'since' date, and move a vendor you stopped using out of it, with that date too.

The notice

Subject: New sub-processor: <Vendor> (objections by <date>)

We plan to engage <Vendor legal entity> as a sub-processor from <start date>.

- What it will do for us: <purpose>
- Personal data it will process: <categories>
- Where: <location>; transfer mechanism: <SCCs / Data Privacy Framework / not applicable>
- Its DPA: <link>; its own sub-processors: <link>

Under our DPA you may object by <date: start date minus the window> by replying to this email.
Our current list, with its history: <link>.

Since EDPB Opinion 22/2024, a one-line "we added X" is thin: the notice should carry enough for the customer to decide whether to object, including where the data goes.

What vendors give their own customers

Your own window is what your DPA with your customers says, whatever your vendors give you.

Catch it at the pull request

Before a branch merges, read the dependencies it adds. A line that names a vendor in the catalog is a new sub-processor to announce:

$ git diff origin/main -- '*package.json' | grep '^+ '

A committed list, subprocessors.json, makes the check exact: anything the code uses that is not on it is new.

Not legal advice. Whether a vendor is your sub-processor depends on the personal data you send it and on your contracts; a list drafted from code is a draft for you to confirm, row by row. It also misses vendors outside the code (your workspace, support desk, CRM, payroll): add those by hand.

A hosted, dated sub-processor page that emails your customers each change is not built.

It would publish the list you approved at a public URL, keep every change with its date, email your subscribers the notice with the day their objection window closes, and record who was told when. agentcheck runs scheduled checks of endpoints today; this is not one of them. If you would pay for it, say so with one click. The click is counted; nothing else is sent or stored.

Sources

subprocessors is a free tool from agentcheck, which runs scheduled checks of your endpoints and alerts you when an answer changes. Vendor links come from each vendor's own pages, read on the day shown.