The Breach Was at Your Vendor. The Letter Comes From You

A support summarisation tool, a review analyser, a chatbot, an email drafting assistant. Each one has some of your customer data inside it, and each one is a company you have never visited, running on infrastructure you have never seen, with suppliers of its own you have probably never been told about.

When one of them is breached, the question that decides your week is not technical. It is who owes a duty to whom, and the answer is unintuitive for most small merchants: almost all of the duty is yours.

Why does the duty land on the merchant rather than the vendor?

Because you decided what data to collect and why, and your supplier only processes it on your instructions. That distinction, controller and processor, is the hinge the whole regime turns on, and it does not soften because you are small or because the vendor is large.

The consequence is set out plainly in Article 33 of the GDPR. The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Where the notification is later than 72 hours, it must be accompanied by reasons for the delay. The processor's obligation is a single sentence by comparison: inform the controller without undue delay after becoming aware.

The ICO's guidance makes the division of labour explicit. A processor must inform you without undue delay as soon as it becomes aware, and that requirement should be detailed in your contract under Article 28. The assessment of whether the breach is reportable is not the vendor's to make. It is yours, which is why the vendor should be reporting every breach to you rather than only the ones it considers serious.

Read that twice if you have ever received a vendor security bulletin telling you no action is required on your part. That sentence describes their engineering response. It says nothing about your regulatory one.

When does the clock actually start?

When you become aware, and for a merchant that is the moment the vendor tells you. The intrusion may have happened eleven weeks earlier. Your 72 hours begin when the email lands.

This is the most useful thing a small merchant can know about breach notification, because it changes the emotional shape of the situation. You are not already late. You are at hour zero of a window that is short but workable, and what you do in the first few hours mostly determines whether the rest is manageable.

The corollary is uncomfortable. Because your clock starts on notification, a vendor that sits on an incident for a month has not consumed your deadline, but it has destroyed your ability to tell customers anything useful about what happened to them and when. That is why the notification clause in the contract matters more than the encryption paragraph everybody reads first.

Do you have to tell the customers themselves?

Only when the risk to them is high, and that is a different and higher bar than the one for telling the regulator. Two thresholds, two decisions, and the second one is the expensive one.

Article 34 requires communication to the data subject without undue delay where a breach is likely to result in a high risk to their rights and freedoms, in clear and plain language, describing the nature of the breach and the measures taken. It then provides three exceptions, and the difference between them is worth understanding because only one is available to you in advance.

The first exception is technical protection applied before the breach, such as encryption, that renders the data unintelligible to anyone not authorised to access it. That is a decision you make when you choose and configure the tool. The second is subsequent measures that ensure the high risk is no longer likely to materialise, which is a judgement made after the fact and usually requires the vendor's cooperation. The third is disproportionate effort, which permits a public communication or similar measure that informs the affected people in an equally effective manner.

Only the first can be arranged ahead of time, which is the practical argument for caring about whether your vendor encrypts data at rest with keys you control. It is not a security abstraction. It is the difference between writing four hundred letters and writing none.

The row that trips people is the third one. A merchant selling into both markets can be inside the European window and outside the Californian one at the same time, because the two count different things. Europe measures from awareness to the regulator. California measures to the consumer, in calendar days, from discovery or notification.

What does the letter to customers have to say?

More than an apology and less than a forensic report. California is the most prescriptive jurisdiction on this and its structure is worth borrowing everywhere, because a notice that satisfies it will usually satisfy the plain language requirement elsewhere.

Section 1798.82 of the California Civil Code requires the notice to be organised under set headings: What Happened, What Information Was Involved, What We Are Doing, What You Can Do and For More Information. The minimum content includes your contact details, the types of information compromised, the date of the breach where it can be determined, a description of the incident, and contact details for the credit reporting agencies. Where identity theft mitigation services are offered, they must be at no cost for at least twelve months.

Those five headings are a gift to anyone writing under pressure. They force the order of a good notice, which is what happened first and what the reader should do next, rather than the order of a bad one, which is usually how sorry you are followed by how seriously you take security.

Two sentences are worth drafting in advance, before you ever need them. The first states what categories of customer data sit in which tool. The second states what you do not hold, because in most small shops the reassuring facts are real: you probably never stored card numbers, and saying so early prevents a much worse assumption.

Why do merchants find out so late?

The subprocessor chain. Your AI tool is rarely one company. It is a product company using a model provider using a cloud region, sometimes with a vector database and an observability vendor in between, and a breach anywhere in that chain has to walk back up it before it reaches you.

Each hop adds delay and subtracts detail. By the time the notice reaches a merchant, it often reads as a generic statement about an incident at a third party service provider, with no indication of whether your tenant was in scope. That is exactly the message that makes the risk assessment impossible, and the assessment is your legal obligation rather than theirs.

The fix is boring and it happens before you buy anything. Ask for the current subprocessor list and ask how you will be told when it changes, because a new subprocessor is new exposure you did not agree to. Ask whether their notification commitment to you is a fixed number of hours or the phrase without undue delay. Ask whether they will tell you when your specific tenant is affected rather than issuing a general statement. Ask what they will give you for your own notice: affected record counts, data categories, and the dates.

Those four questions do more than any security questionnaire, and they are answerable. We went through the wider version of this in the piece on the security form your AI vendor passes without trying, which is about why the standard questionnaire fails to distinguish good suppliers from confident ones.

What should a small shop do in the first day?

Work in a fixed order, because the natural order is wrong. The instinct is to find out what happened. The obligation is to decide whether it is reportable, and those are different tasks with different deadlines.

Start by recording the moment you were told, in writing, with the vendor's message attached. That timestamp is the start of your clock and the thing a regulator will ask about first. Then establish scope from your own side rather than the vendor's: which of your data classes were in that tool, for which customers, over what period. You know this better than they do because you configured what you sent.

Next make the risk assessment and write it down whichever way it goes. If the conclusion is that a risk to rights and freedoms is unlikely, that reasoning is the thing that protects you, and the documentation requirement applies to every breach regardless of whether you report it. Then report or do not report, and only after that turn to the question of telling customers.

Stop your own bleeding in parallel. Rotate the API keys for that vendor, revoke the integration's access to anything it does not need today, and export whatever log of your usage you can get before the vendor's own retention window closes on it. Knowing what you sent is the whole basis of your assessment, and that record lives in a place you may lose access to, which is one reason to understand what AI vendors actually keep and for how long before rather than during an incident.

Does it matter if the data was only prompts?

It matters less than people hope. A prompt containing a customer's name, their order and their complaint is personal data, and the fact that it was typed into a chat box rather than stored in a database changes nothing about its status.

This catches people because prompts feel ephemeral. They are not. They are usually retained, often logged for abuse monitoring, and in many products they are visible to the vendor's staff under defined conditions. If your support team has been pasting order details into an assistant to draft replies, then that assistant holds customer data, and a breach there is a breach of yours.

The practical defence is upstream of any incident, which is deciding what may be pasted and what may not, and making that decision concrete enough to follow on a busy Friday. We wrote the working version of that rule in the piece on what you may paste into an AI tool.

Does cyber insurance change the calculation?

It changes who pays for the response, not who owes the duty. A policy can fund the forensics, the legal review and the printing of letters. It cannot notify anybody on your behalf, and it will not accept the regulatory consequence of a late filing.

Two conditions are worth checking on the policy you already hold, because both bite in exactly this scenario. The first is whether cover extends to a breach at a third party service provider rather than only to your own systems, since an AI vendor incident is by definition somebody else's network. The second is the notification condition on the policy itself, which often requires you to tell the insurer within a short window and to use their appointed responders. Calling your own lawyer first can void the cover you were relying on.

There is also a sequencing trap. Insurers and their panel firms work to a careful timetable designed to preserve legal privilege, and that timetable is longer than 72 hours. Your regulatory deadline does not pause while an investigation establishes the facts, which is precisely why Article 33 allows the information to be provided in phases. Report what you know, say what you do not yet know, and supplement it later. A first filing that is honest about its own gaps is compliant. A complete filing on day nine is not.

What if the vendor says no personal data was affected?

Treat it as an input, not a conclusion. The vendor knows what was taken from their systems. They do not know what you put into them.

A model provider genuinely may not know that the free text field it holds contains a delivery address, because from their side it is a string. The mapping between their exposed records and your customers exists only in your head and in your configuration. That is why the assessment is assigned to the controller in the first place, and why a vendor's reassurance cannot discharge it.

Ask them for the record identifiers or the account scope affected, then check that against your own logs. If they cannot tell you whether your tenant was in scope, the honest position is that you cannot rule it out, and your risk assessment has to say so.

The part to do this week

None of the above requires a lawyer to prepare. It requires a list. Write down every AI tool that touches customer data, what data class each one receives, who at your business can turn its access off, and what the contract says about how quickly they must tell you. Four columns, one page.

Then draft the notice template with the five California headings and leave the specifics blank. A merchant who has that page and that template will handle a vendor breach as an unpleasant two days. A merchant who does not will spend the first of those two days finding out which tools exist, and that is the day the clock was for.

The wider point is that using AI tools moves some of your customer data into other people's systems without moving any of the responsibility. That trade is often worth making. It is only safe when you know exactly what you handed over, which is the same reason we publish what our own platform holds and where rather than asking anyone to assume.