Swapping a vendor that touches customer data? Notify your customers before it goes live.

Take a pull request that changes four lines. Out goes the Mailgun SDK, in comes Resend. Transactional email had been dropping messages, Resend is cheaper, and the diff is small enough to approve from a phone. It merges that afternoon and ships with the next deploy. Some version of that goes through most teams every quarter.

Every password reset, invite and receipt your customers' users receive now runs through a company none of those customers have agreed to. If you sell software that holds your customers' data, you owed each of those customers something in writing before that deploy went out, and skipping it puts you in breach of GDPR Article 28(2) and of a term in your own contract. What you owed, and how far in advance, is not written in the regulation. It is written in the agreement you signed with each customer, and the number in it is one your company chose.

Which vendor changes need notice?

The ones where the new vendor handles personal data on your behalf, as part of the service you sell.

Whether you are processor or controller for the data in question decides whether any of this binds you. Article 28(2) reaches you where you are your customers' processor, holding their users' data on their instructions. It does not reach the data you are controller of, your own signups and marketing list, where nobody is owed a vendor notice. Most companies are both, in different parts of the same product, and only the processor half is in scope here.

Inside that half, Resend is a sub-processor. So is your hosting provider, your error tracker, your support inbox, and the model API behind your summarise button. Guidance from the European Data Protection Board, the body where the EU's national privacy regulators agree common positions, puts the trigger at the moment a processor "intends to engage another player, thereby adding another link to the chain" 2.

Sorting a vendor list gets you three groups, and only the first carries a notice duty:

• A sub-processor. Hosting, email, storage, logging, analytics, transcription, LLM APIs, anything your backend calls with a user record attached.
• Not a sub-processor. It never sees customer personal data: your CI runner building public code, your design tool, the accounting system holding only your own invoices.
• An independent controller. Some vendors decide their own purposes for the data rather than following your instructions. A card processor running its own fraud checks is the usual example. Article 28(2) does not reach that arrangement. Your own duty to tell users who receives their data still does.

That sorting is mine rather than a regulator's, and plenty of vendors sit in two groups at once. A payment provider follows your instructions to charge a customer and decides its own fraud purposes on the same transaction. Where a vendor does both, the instructed part is in scope and the rest is not, so sort the work rather than the company.

What does Article 28(2) require, and when?

Written authorisation from the customer, before the new vendor processes anything.

Article 28(2) names replacement alongside addition 1, so swapping Mailgun for Resend is covered exactly as bolting Resend on alongside it would be. It leaves two regimes, and your contract picked one of them:

• General authorisation. The customer approved a list up front and agreed that you may change it, provided you tell them in advance and give them a real chance to object.
• Specific authorisation. The customer names each sub-processor in writing. Any subsequent change has to be authorised again before it is put in place 2.

The two regimes differ in what your customer's silence means, and that decides whether your deploy went out authorised. EDPB guidance puts it plainly: under general authorisation, "the controller's failure to object within the set timeframe can be interpreted as authorisation", while under specific authorisation, an unanswered request "should be held as denied" 2. So if your agreement is a specific-authorisation one, the customer who never replied has not quietly agreed. They have refused, and your deploy went out without the authorisation Article 28(2) requires. If I could check only one thing in a DPA, it would be this one, because the working assumption in most teams runs the other way: nobody complained, so it was fine.

One more thing that trips teams up: quietly editing your sub-processor page is not informing anybody. The processor's duty to inform "implies that the processor actively indicates or flags such changes toward the controller" 2. A page that changed while nobody was looking at it does not meet that.

Where does the notice period come from?

From your own contract. The GDPR gives you no number at all.

The EDPB says the contract "should include details as to the timeframe for the controller's approval or objection", that the timeframe has to be "reasonable in light of the type of processing", and that the contract should also set out what happens after an objection, such as how long the parties then have to decide whether the processing stops 2. So the regulation delegates the number, and the guidance tells you to write one down. Whether anybody at your company did is a question about a document, not about the law.

You can see that blank in the European Commission's standard contractual clauses, the template contract that makes it lawful to send personal data outside Europe. They are annexed to your DPA if your customers' data leaves the EEA, which for most SaaS it does. Clause 9, Option 2, says the data importer, meaning the side receiving the data, which is you, "shall specifically inform the data exporter in writing of any intended changes to that list through the addition or replacement of sub-processors at least [Specify time period] in advance" 4. That bracket is a literal blank in the official text. Somebody at your company filled it in, possibly years ago, possibly by accepting a template's default. Your annex will show one of two options, and you can tell them apart by what they ask of your customer: Option 1 makes every new sub-processor wait for a written yes, Option 2 is the general list plus the notice period above. Whichever is not in use is normally struck out.

What companies commit to varies enormously. Stripe's data processing agreement promises notice at least 30 days before a change takes effect, then gives customers 30 days from that notice to object. Vercel's data processing addendum states no advance notice period at all and gives customers five calendar days from notice to object. Read against the EDPB's reasonableness test those are not equivalent commitments, and I would not want to defend the five-day version as leaving a genuine opportunity to object. I am not aware of a regulator having ruled on it either way, so treat that as my reading rather than settled law. What is not arguable is the practical difference: the engineer merging the vendor swap has no idea which of those two shapes your agreement is.

Both agreements also deliver notice only to customers who have opted in: Stripe notifies you if you subscribe on its sub-processor list, and Vercel asks you to email its privacy address. You are somebody's customer too, and nobody subscribes you by default.

What else changes when the vendor changes?

Four other things, beyond the notice itself.

The list itself. Where sub-processors are approved in the contract or an annex, that list "should then be kept up to date" 2. The EDPB went further in Opinion 22/2024, saying controllers should have the identity of every processor and sub-processor in the chain "readily available at all times", regardless of how risky the processing is, and that the processor should provide this proactively and keep it current 3. A list that is accurate at signature and never revisited is the exact failure that provision describes.

The contract with the new vendor. Article 28(4) requires you to impose the same data protection obligations on the sub-processor by contract, and you remain fully liable to your customer for how it performs 1. Clicking through Resend's standard terms may satisfy that. Reading them is how you find out.

Your own privacy policy, sometimes. For your own signups and visitors you are the controller, and Article 13(1)(e) asks for "the recipients or categories of recipients of the personal data" 1. That "or" decides it: if your policy names vendors, swapping one makes the page wrong today; if it discloses categories, a like-for-like swap changes nothing there, and the entry to check instead is Article 13(1)(f) on transfers outside the EEA.

Your records of processing. Two entries move: the vendor's name and contact details, and whether the data now leaves the EEA. That is Article 30(2), the processor's version of the record 1.

None of these is difficult on the day. They get difficult eighteen months later, when four vendors have changed, the person who made two of the swaps has left, and a procurement questionnaire asks for a current list. It is the same slow gap that opens between a privacy policy and the product it describes. It also tends to surface in the same place, which is across the table from an enterprise buyer.

What should you do before the next swap ships?

Open your own data processing agreement and read three things out of it. Whether it grants general or specific authorisation. The number in the notice clause, the one that used to be a blank. And what the contract says happens when a customer objects. Those three answers turn an abstract duty into a date and a decision, and almost nobody keeps them written down anywhere an engineer can reach.

Then write the notice you owe. It is an email to each customer's contract notice address, naming the outgoing vendor, the incoming one, what it will process and where, and the date it starts. Not a page edit. If a swap already went live without one, send it now and say the change has happened, which is a worse email than the one you should have sent and a much better position than saying nothing.

Then do the reverse pass. List the vendors that hold your customers' data, open each one's sub-processor page, and subscribe. You are entitled to those notices and you are probably not getting them.

Neither of those tells you when the next swap happens, and that is the harder problem. The change that starts all of this is a pull request, and nothing about a four-line diff announces itself as a legal event. Lawcel is a compliance tool for exactly that: it reads the changes moving through your GitHub, Linear or Jira against a record of what your company does with personal data and which vendors it relies on, and it tells you when a change has made one of your published documents wrong, while the change is still a pull request rather than a discovery in somebody's procurement review. A vendor swap is among the clearest cases it catches, because the diff is small, the obligation is real, and the only thing linking them is a person remembering.

It will not write the notice to your customers, and I would not trust software that claimed to. It puts the question in front of you on the pull request that raises it, while there is still time to send that email before the deploy. If that is the gap in your process, connect the repository your product ships from and judge it on the next vendor swap your team makes.