AI Vendor Data Breach: Your First 72 Hours
Your first move is not finding out what happened. It is working out whether your own notification clock has started, because it runs shorter than the vendor's.
An AI vendor you use has emailed to say they had a security incident. Your instinct is to find out what happened. That is the wrong first move. Your first move is to work out whether the clock has started on your own notification obligations, because if your customers' data was in that vendor's system, the incident is now partly yours and you have less time than the vendor does.
Here is the sequence, on the timeline it actually runs on.
Hour zero to four: establish whether this is yours
Three questions, answered in this order. Do not proceed to the second until you have an answer to the first.
1. Did any of your data live in the affected system? Not "do we use this vendor." Which specific data, in which specific product or region. Vendors run multiple systems and breach notices are often scoped to one. If your integration only ever sent anonymised identifiers, your exposure is very different from a team that sent full support transcripts.
2. Was any of it personal data belonging to your customers? If yes, and you are subject to GDPR or an equivalent regime, you are the controller and the vendor is your processor. Their breach becomes your notifiable incident, and the regulatory clock is 72 hours from when you became aware, not from when they did.
3. Do you have a data processing agreement with them? Find it now, not later. It defines what they owe you, how fast, and in what form. If you discover you never signed one, that is a separate problem, and it is one you should note down and fix rather than dwell on during the incident.
If the answer to question one is genuinely no, document that you checked and how, then move to the monitoring posture at the end of this piece. If it is yes, keep going.
Hour four to twenty-four: the three questions to ask the vendor
Vendor breach notices are written by lawyers and are frequently vague in ways that are convenient for the vendor. Ask these three, in writing, and ask for written answers:
What is the exact window of compromise, and what is the confidence on both ends? "We believe unauthorised access occurred between X and Y" tells you which of your data was in scope. A vendor who cannot bound the window is telling you something important.
Was data exfiltrated, or only accessible? These are wildly different, and vendors often lead with the softer framing. Access without evidence of exfiltration is still notifiable in many regimes, and the distinction shapes what you tell your own customers.
What specific data categories were involved, at the field level? Not "customer data." Which fields. Email addresses and support ticket bodies carry different consequences, and prompt logs may contain anything your users pasted.
Ask for these in writing because you will need to show your regulator, and because a written answer is harder to soften later. If the vendor's answers change materially over the following days, which is common and not always sinister, keep both versions.
Hour twenty-four to seventy-two: your own notification
If personal data you control was involved, you have a decision to make and a short window to make it. GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals' rights and freedoms. Miss the window and you have to explain the delay. Separately, notify affected individuals if the risk is high.
Two practical points that catch people out.
You can notify with incomplete information. The regulation anticipates this. A notification that describes what you know, what you do not yet know, and when you expect to know it is normal and expected. Waiting for a complete picture past 72 hours is worse than an incomplete notification on time.
"Awareness" starts earlier than you would like. It starts when you have a reasonable degree of certainty that a breach occurred, not when your investigation concludes. The vendor's notice usually starts it.
This is not legal advice and the thresholds vary by jurisdiction and by the nature of the data. Get counsel involved on day one if personal data was in scope; the cost of an hour of advice here is trivial against the cost of a late notification.
What to tell your own customers
If you are notifying customers, the note that works is short, specific, and does not attempt to distribute blame. Something close to this shape:
What happened: our vendor [Name], which we use for [specific
function], had a security incident affecting [system] between
[dates]. They notified us on [date].
What was involved for you: [specific data categories]. We have
confirmed that [categories not involved] were not affected.
What we have done: [suspended the integration / rotated
credentials / etc], and we are [ongoing action].
What you should do: [specific action, or "no action is needed
and here is why"].
We will update you by [date] whether or not there is more to
report.The last line is the one that buys you goodwill. A committed update date, honoured even when the update is "nothing new," is the difference between a customer who trusts your process and one who chases you.
What to do on your own side, immediately
Regardless of the regulatory picture, these are worth doing within the first day:
Rotate every credential shared with that vendor. API keys, webhook secrets, service accounts. Do this even if the vendor says credentials were not affected.
Suspend or scope down the integration until you have answers. A pause is reversible; continued data flow into a compromised system is not.
Pull your own logs for the compromise window. What did you send, when. You will need this for the notification and it gets harder to reconstruct as retention windows roll.
Check what else that vendor touches. Single sign-on, shared credentials, or a second product from the same company all extend the blast radius. This is exactly the mapping that an AI incident response plan should already contain.
Afterwards: the part that reduces the next one
Once it has settled, two changes are worth making while the memory is fresh.
First, tighten what you send. Most teams discover during a vendor breach that they were sending more than the integration needed, usually because the default payload was easier than a filtered one. Trim it.
Second, add the questions above to your vendor intake. Asking a prospective vendor about their breach notification timeline, their subprocessor list, and their data retention before you sign is far easier than after, and their answers are informative in themselves. That belongs in how to vet an AI vendor, alongside the GDPR compliance questions that cover the same ground from the contractual side.
If the incident turned out to be a leak from a tool rather than a full breach, the containment steps overlap heavily with what to do if an AI tool leaks your data. It sits inside the broader landscape of AI risk that every vendor decision touches.
FAQ
Do I have to notify if the vendor already notified regulators?
Usually yes. The vendor notifies as processor for their own obligations. As controller, your obligation is your own and is not discharged by theirs.
What if the vendor will not answer my questions?
Escalate in writing, cite the data processing agreement, and set a deadline. A processor's obligation to assist the controller with breach notification is standard in a DPA. Persistent non-response is itself something to document and, in serious cases, to raise with your supervisory authority.
How long should I keep records of this?
Keep the full incident file, including your decision not to notify if that was the decision, and the reasoning behind it. Regulators ask to see the reasoning, and "we assessed it as low risk" without a written assessment is a weak position.
Should I stop using the vendor?
Not automatically. A vendor that discloses promptly, answers specifically, and fixes the root cause may be a better risk afterwards than an untested alternative. Judge them on the response, not on the fact that an incident occurred.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
