Your vendor gets breached. Your company's data is in scope. You are not the one with the incident to remediate, but you still have work — legal, communications, technical, and contractual — that is on you, not on them. The organizations that handle these well have thought about the roles before the call comes. The ones that handle them poorly learn on the job, usually badly.

The First Call Is to Counsel

Before you do anything else — before you engage the vendor's "incident hotline," before you draft a customer note — your GC is in the room. A supply chain breach is a legal event for you. Data subjects may sue you, not the vendor. Regulators may hold you accountable as the controller even when the processor is at fault. Counsel drives.

Pull the Contract Immediately

Your Master Services Agreement and Data Processing Addendum answer most of the early questions:

  • Notification timeline — what does the vendor owe you and when? Is "without undue delay" or a specific number of hours specified?
  • Information rights — can you demand a forensic report, an audit, or direct access to evidence?
  • Cooperation obligations — are they required to assist with your downstream notifications?
  • Liability caps and carve-outs — is security and data protection carved out from the general cap?
  • Indemnification — are you covered for third-party claims arising from the vendor's breach?
  • Data return/deletion — does the contract let you pull your data out for a quick migration?

If the contract is thin in any of these areas, you have a capability gap today and a contract-remediation project after.

The Shared-Responsibility Reality

Every major cloud and SaaS vendor publishes a "shared responsibility model" that describes what they secure and what you secure. The pattern is consistent: they secure the platform; you secure your data, your users, and your configurations.

In a supply chain breach, walk that model deliberately:

  • Was the compromise in the vendor's layer? (Their infrastructure, their code.) Then liability largely sits with them — subject to your contract.
  • Was the compromise in your layer inside their platform? (Your misconfigured bucket, your leaked API key, your user's compromised credential.) Then liability largely sits with you, even if the platform is what got touched.
  • Was it a shared failure? (Their default was insecure, you did not change it.) Expect the contract to be the battleground.

Your Customer Notification Chain

Here is the part that surprises a lot of organizations: your customers (or your employees, if employee data is involved) generally want to hear from you, not from your vendor. You are their counterparty. You chose the vendor. You own the relationship.

Steps:

  1. Determine what data of yours — and by extension, your customers' — was affected.
  2. Assess your notification obligations under state law, GDPR, HIPAA, or sector rules.
  3. Coordinate with the vendor on messaging so your notice and their notice do not contradict each other.
  4. Draft your customer notice with counsel. Reference the vendor by name only after careful consideration; blaming publicly can backfire legally and commercially.
  5. Provide a dedicated response channel for customer questions.
  6. Track notification completion state per customer, per jurisdiction.

Technical Response on Your Side

Even when the incident is the vendor's, you have technical work:

  • Rotate any credentials, API keys, OAuth tokens, and secrets shared with the vendor. Even if the vendor says "only X system was affected," rotate broadly.
  • Review recent data exchanges with the vendor — did anything unusual flow in or out in the affected window?
  • Review your own logs for any sign of pivoting from the vendor's compromised environment into yours.
  • Assess whether vendor-provided software or libraries embedded in your products need to be updated or replaced.
  • Evaluate fallback vendors and migration cost if you decide to move.

Regulatory Exposure

Under GDPR, you as controller remain on the hook for processor failures. Under many state laws, you as the business that "owns" the data set notify residents regardless of where the compromise happened. Under HIPAA, a business associate breach is your business associate's duty to report to you; yours to assess and notify downstream. Under SEC Reg S-K Item 106, your material-cybersecurity incident disclosure clock is tied to your determination of materiality, not your vendor's.

None of these regimes allow you to point at the vendor and say "not our problem." The contract may reallocate economic liability between you and the vendor; it does not move regulatory liability.

Contract Language to Add for Next Time

Take this breach as tuition and update your standard contract template. Language that pays for itself:

  • Short notification windows. "Vendor shall notify Customer within 24 hours of discovery of any Security Incident."
  • Right to forensics. "Customer shall have the right to review the final forensic report and, at Customer's expense, to engage an independent forensic firm subject to reasonable confidentiality protections."
  • Cooperation with notifications. "Vendor shall provide all information reasonably necessary for Customer to fulfill notification obligations to its customers, data subjects, and regulators."
  • Security incident carve-out from liability cap — or a super-cap (e.g., 3x annual fees) specifically for data protection failures.
  • Audit rights with reasonable notice.
  • Subprocessor transparency — a current list, change notice, right to object.
  • Termination for material breach with data return and deletion obligations.

Posture Going Forward

Supply chain incidents are now the modal enterprise breach. Your vendor risk program should assume that every vendor will, at some point during the relationship, be breached. Build the response muscle for that — tabletop a vendor breach annually, keep a template response, and know which of your vendors hold which of your data. When it happens, you work the plan instead of writing it.