When a Vendor Gets Breached: Third-Party Risk and Your Contracts

Vendor risk and breach obligations depend on your contracts, your data, and the applicable law. This post is informational. For your specific vendor relationships, consult a licensed attorney.

Most companies picture a data breach as something that happens to them: their servers, their logins, their code. In practice, the breach that does the damage is increasingly one that happens to a vendor you trusted with your data. The password manager. The analytics platform. The customer-support tool that has a copy of every ticket a customer ever filed.

When that vendor gets breached, your data is exposed, your customers look to you, and in many cases your own legal obligations trigger, even though nothing on your side was compromised. Whether that turns into a manageable incident or an expensive one usually comes down to two things you control long before anything goes wrong: the contract you signed, and the diligence you did before signing it.

The breach you don’t control

The uncomfortable part of third-party risk is that you inherit the consequences without controlling the security. You can run a tight shop internally and still end up notifying customers because a SaaS provider three steps removed from you left a database exposed.

Two exposures matter here. The first is regulatory: if the breached data includes personal information, state breach-notification laws and your privacy commitments may obligate you to notify, regardless of whose systems failed. The second is commercial: your customers’ contracts with you often make you responsible for your sub-vendors. A breach at your vendor can put you in breach of your own customer agreements.

What your contract should already say

By the time a vendor is breached, it is too late to negotiate. The protections have to be in the agreement before you hand over data. A few provisions do most of the work:

A data processing agreement (DPA). If the vendor handles personal information, a DPA should define what they can do with the data, prohibit using it for their own purposes, and require them to help you meet your own compliance obligations. This is table stakes for privacy-regulated data and increasingly expected by your customers.

A defined breach-notification window. The agreement should require the vendor to notify you of a security incident within a specific, short period, not “promptly,” which means nothing when a regulator is counting days. You cannot meet your own notification deadlines if you learn about the breach late.

Concrete security obligations. Vague “industry-standard security” language is hard to enforce. Better agreements reference a specific framework or certification (SOC 2, ISO 27001) and require the vendor to maintain it.

Audit or evidence rights. At minimum, the right to receive the vendor’s current SOC 2 or ISO report and evidence of remediation after an incident.

Indemnification and a liability cap that fits the risk. A vendor breach can cost you notification expenses, credit monitoring, regulatory response, and customer churn. If the contract caps the vendor’s liability at one month of fees, you are absorbing the rest. The cap on data-breach liability is worth negotiating separately from the general cap.

Sub-processor transparency. Your vendor has vendors. The agreement should require disclosure of sub-processors and flow the same obligations down to them.

Diligence before you sign

Contract terms protect you after the fact. Diligence reduces the odds you ever need them. Before you route sensitive data to a new tool, the basic questions are worth asking: Does the vendor hold a current SOC 2 Type II or ISO 27001 certification, and what does its scope actually cover? Where is the data stored, and who else can access it? What is the vendor’s own breach history? What sub-processors sit behind the product?

None of this requires a formal security team. It requires reading the vendor’s trust-center documentation instead of clicking through it, and treating the answers as part of the buying decision rather than a formality after the decision is made.

When a vendor breach happens

If a vendor does get breached, the early moves matter. Pin down what data was involved and whether it includes personal or regulated information. Pull the contract and check the notification and cooperation obligations you can hold the vendor to. Assess your own notification triggers under applicable law and your customer agreements. The clock may already be running. And document the timeline as you go, because you will need it for regulators, customers, and any claim against the vendor.

The companies that handle these well are not the ones that never have a vendor breached. They are the ones that decided, before signing, what a breach would cost them and put that decision in the contract.

If you are routing customer or employee data to third-party tools and are not sure your agreements and diligence hold up, talk to MB Legal before the next vendor goes live.

This post is informational and does not constitute legal advice. Vendor risk, breach-notification obligations, and contract terms vary by fact pattern and jurisdiction. For guidance specific to your situation, consult a licensed attorney.