Who is responsible when a vendor causes a data breach?

You retain the obligation to your customers and usually to your regulator, because they entrusted the data to you. The vendor may be liable contractually and may have its own reporting duties, but that does not transfer your notification responsibility or reduce the reputational consequence.

What is fourth-party risk?

Exposure through your vendor's own suppliers. Your data may reach a subprocessor you never assessed or knew about. It matters because the chain determines where your data actually sits, which is why contracts should require disclosure of subprocessors and notice when they change.

How do you scope a breach in someone else's systems?

You largely cannot, which is the core difficulty. You depend on the vendor's statement and cannot pull logs or verify claims. The preparation that helps most is a maintained record of exactly which fields each vendor holds, so their disclosure can be translated into your exposure immediately.

Should you repeat the attacker's claims about data volume?

No. Figures published on leak sites are promotional and frequently inflated, and repeating them as fact both misleads customers and overstates your incident. Attribute such claims explicitly to the group making them, and distinguish them from what the vendor or reporting has established.

Can third-party scripts in your product expose customer data?

Yes. Code that runs in your customers' sessions can read what those sessions contain, regardless of how well your infrastructure is secured. Knowing what scripts and apps load, restricting them with a content security policy, and pinning integrity hashes are the practical limits on that path.

When Your Vendor Is Breached, Not You

A vendor breach exposes your customers' data through a supplier's systems rather than your own. You retain the notification obligation and the reputational cost while holding none of the forensic evidence, which is why the decisive preparation is knowing in advance which suppliers hold what data.

Two reported examples

A screening vendor. MyBroadband reported that SA Home Loans, a South African mortgage lender, was affected by a breach at RelyComply, a compliance screening provider it used for verification checks. According to that reporting, unauthorised access to RelyComply's environment occurred in early September 2026 and was identified about a week later. SA Home Loans said the accessed files contained personal information from customer records, that RelyComply had never received banking details, balances, or identity document copies, that its own systems showed no compromise, and that it could not rule out exfiltration of its customer data. Moneyweb separately reported other financial firms affected through the same vendor. A group calling itself Dire Wolf listed RelyComply on its leak site and claimed a large volume of data; that claim is an attacker assertion and was not verified.

A third-party storefront app. BleepingComputer reported on 21 September 2026 that BigCommerce notified merchants of a breach linked to the third-party Ribon apps, in which compromised app credentials were used to inject malicious scripts into a small number of merchant storefronts and to access customer data. Master of Malt, a UK drinks retailer named as an affected merchant, notified customers and reported the matter to the Information Commissioner's Office. Per that reporting, exposed fields included names, email addresses, phone numbers, and shipping addresses, while passwords and payment card data were stored separately and not exposed.

Neither company's own systems were the point of compromise. Both carried the consequences.

Why this is the hardest shape to respond to

In your own incident you control the timeline: you can pull logs, image hosts, and determine scope. In a vendor incident you have a supplier's statement and nothing else. You cannot verify what was accessed, you often cannot get per-customer detail, and the disclosure timeline is set by someone whose incentives differ from yours. Meanwhile your regulator's clock is running against your obligation, and your customers will contact you rather than the vendor they have never heard of.

Preparation that actually helps

Maintain a record of what each vendor holds. Not a questionnaire response, a factual list: which fields, for which population, retained how long. This is the single artefact that converts a vendor breach from a week of guessing into a scoped assessment on day one. Most organisations discover they do not have it at exactly the wrong moment.

Push for data minimisation at integration time. The most valuable sentence in the SA Home Loans reporting is the statement about what the vendor never received. Fields you never send cannot be exposed, and integration is the only point where that is cheap to decide.

Get notification terms into contracts, with a number. Notify promptly is unenforceable. A defined window, a named contact, and an obligation to provide enough detail for your own notification duty are what make the clause useful. Also require notice of the vendor's own subprocessors, because their vendors are in your chain whether or not you acknowledge it.

Inventory third-party code in your product. Scripts, apps, and integrations that execute in your customers' sessions are an exposure path independent of your infrastructure. A content security policy and subresource integrity limit what an injected script can do, and knowing what is loaded is the precondition for both.

Write the vendor-breach playbook in advance. It is a different plan: questions to ask, who decides on notification, what you tell customers while facts are incomplete, and how you handle the vendor's disclosure timeline not matching your obligation.

Do not repeat attacker volume claims. Leak-site figures are promotional. Reporting them as fact inflates your own incident and misleads your customers, and it is a habit worth avoiding even when convenient.

Communicating without overclaiming

Say what you know, what you do not, and when you will update. A statement that says the vendor has reported unauthorised access, that you have not identified compromise of your own systems, and that you cannot yet confirm whether specific customer data was taken is accurate and holds up. Certainty stated early and withdrawn later costs more than acknowledged uncertainty.

Do not use the vendor as a shield. Customers gave their data to you. Naming the supplier is useful for accuracy and useless as a defence, and framing it as a defence reads that way.

Be precise about which fields. Names and addresses imply a different response from identity numbers or credentials. Vague categories drive both unnecessary alarm and insufficient action, and specificity is what makes advice actionable.

Tell people what to do, proportionate to the data. Where contact details were exposed, the realistic follow-on risk is targeted phishing referencing a real relationship, and saying so is more useful than a generic instruction to remain vigilant.

Log your own decisions as you go. Regulators ask when you knew and what you did. In a vendor incident, when you knew is when the vendor told you, and having that documented, including what the vendor did not provide, is what makes your own timeline defensible.

Frequently asked questions

Who is responsible when a vendor causes a data breach?: You retain the obligation to your customers and usually to your regulator, because they entrusted the data to you. The vendor may be liable contractually and may have its own reporting duties, but that does not transfer your notification responsibility or reduce the reputational consequence.
What is fourth-party risk?: Exposure through your vendor's own suppliers. Your data may reach a subprocessor you never assessed or knew about. It matters because the chain determines where your data actually sits, which is why contracts should require disclosure of subprocessors and notice when they change.
How do you scope a breach in someone else's systems?: You largely cannot, which is the core difficulty. You depend on the vendor's statement and cannot pull logs or verify claims. The preparation that helps most is a maintained record of exactly which fields each vendor holds, so their disclosure can be translated into your exposure immediately.
Should you repeat the attacker's claims about data volume?: No. Figures published on leak sites are promotional and frequently inflated, and repeating them as fact both misleads customers and overstates your incident. Attribute such claims explicitly to the group making them, and distinguish them from what the vendor or reporting has established.
Can third-party scripts in your product expose customer data?: Yes. Code that runs in your customers' sessions can read what those sessions contain, regardless of how well your infrastructure is secured. Knowing what scripts and apps load, restricting them with a content security policy, and pinning integrity hashes are the practical limits on that path.