Your Vendor Got Breached. Now What? A Third-Party Incident Response Guide
Short answer: When a vendor gets breached, you are running an incident where you own the consequences but not the evidence, the systems, or the timeline. The playbook is different from an internal compromise: trigger the contract clauses immediately, contain on your side of the boundary, demand specific artifacts instead of general reassurance, and take control of communications to your customers and regulators — because those obligations stayed yours no matter what the vendor’s press release says.
This scenario has stopped being an edge case. Recent industry surveys put third-party incidents at the origin of over a third of breaches, with remediation costs averaging around 4.8 million dollars, and my own experience says the operational pain is worse than the number suggests. Yet most incident response plans I review are written entirely from the inside out: our SIEM, our forensics, our containment. Then a Tuesday morning email arrives from a supplier’s counsel — carefully worded, thin on facts — and the team discovers the plan assumes access it does not have.
Why your IR plan does not fit this incident
An internal incident gives you levers: isolate the host, pull the logs, image the disk, reset the credentials. A vendor incident gives you a phone number and a contract. You cannot see their network. You cannot verify their containment claims. You often cannot even get a straight answer about which of your data was in the affected system, because the vendor’s lawyers are managing their liability while you are managing your exposure. Those are different objectives, and it helps to be honest about that from the first call. The vendor is not your incident response partner. The vendor is a party whose interests overlap with yours only partially.
This is why the third-party scenario deserves its own runbook inside your incident response program rather than a footnote in the main plan. Same severity scale, same command structure, different actions at every step.
The first 24 hours: contract triggers and your side of the boundary
Two workstreams start at once. The first is legal: pull the contract and invoke, in writing, every incident clause it contains — notification obligations, cooperation duties, audit rights, evidence preservation. Do this even if the relationship is friendly, because the clauses you do not invoke early are the clauses you effectively waive. If the contract turns out to be thin, note that too; it goes on the after-action list.
The second workstream is containment on territory you actually control. Rotate every credential the vendor holds: API keys, service accounts, SSO integrations, SFTP logins. Review and restrict the network paths between their environment and yours. Pull your own logs for every authentication and data transfer involving that vendor going back further than the breach window they have admitted to — vendors’ initial timelines have a way of growing. You are not waiting for their forensics to protect yourself; their forensics will arrive in weeks, and your exposure is live now.
Evidence you cannot collect, and what to demand instead
Accept early that you will never get raw access to the vendor’s environment, and design your asks accordingly. Vague requests get vague answers, so ask for artifacts by name: the executive summary and findings of the independent forensics report when complete, the confirmed intrusion timeline, the specific systems and data sets affected with your records identified, indicators of compromise you can sweep your own environment for, and written confirmation of containment and eradication with dates. Ask for interim answers on a schedule — a thin update every 48 hours beats a polished report in six weeks.
Meanwhile, build your own evidence file: every notification received, every question asked and answered, every commitment made, with timestamps. If this ends in regulatory scrutiny or litigation, the quality of your contemporaneous record is the difference between demonstrating diligence and reconstructing it. And keep your own telemetry: your logs of what crossed the boundary are the one forensic source the vendor cannot filter for you.
The communications you still own
Here is the part that surprises executives: your notification obligations to customers, regulators, and partners did not transfer to the vendor. If your customers’ data was exposed through your supplier, the disclosure duty in most regimes sits with you as the controller of that relationship, on your clock. Waiting for the vendor to go public first is not a strategy; it is how you end up explaining to a regulator why the market knew before your notification did.
Draft early, even with incomplete facts. A holding statement that says what you know, what you are doing, and when you will update is honest and defensible. I keep pre-built versions for exactly this scenario in my data breach communication templates, and the third-party variant differs from the internal one in a specific way: it names the vendor relationship carefully, avoids adopting the vendor’s unverified claims as your own, and never says more about their environment than they have confirmed in writing. Repeating a vendor’s optimistic containment claim under your letterhead makes it your claim when it turns out to be wrong.
Running the vendor call without losing the room
Somewhere around day three, the recurring status call with the vendor begins, and how you run it determines what you get. Send the agenda in advance with your open questions numbered. Keep your own minutes and circulate them the same day, so the record of what was said is yours, not theirs. Bring the same two or three people every time — continuity is how you catch the small contradictions between week one’s story and week four’s. And separate the channels: technical staff talk to technical staff about indicators and timelines, while contractual and liability topics stay between the lawyers. The fastest way to lose the technical channel is to let it become a negotiation.
Watch for the fourth party, too. A striking number of vendor incidents turn out to originate one layer deeper — the vendor’s own supplier, a hosting provider, a support contractor with standing access. Ask directly whether a subcontractor was involved, because the answer changes both the forensics you should expect and the contract language you will want afterward. If your agreement is silent on subcontractor flow-down obligations, you have found another item for the after-action list, and you will not be the only company on that call discovering the same gap at the same time.
After the fire: fix the contract, then the portfolio
Every third-party incident is a free audit of your vendor governance, and wasting it is negligence. Start with the contract that just failed you: add notification within a defined number of hours, cooperation and evidence-sharing obligations, audit rights that survive an incident, and clear allocation of notification costs. Then look sideways across the portfolio, because the vendor that got breached is rarely unique — it is usually representative. Which other suppliers hold the same class of data, the same kind of access, the same weak clauses?
This is also the moment to upgrade how you assess vendors before signing. A questionnaire that asks whether they have a firewall tells you nothing; the assessment has to probe incident notification commitments, forensics arrangements, and subcontractor visibility. My vendor security assessment template is built around those failure modes, because the questions worth asking a vendor are the ones you wish you had asked the last one that called you on a Tuesday morning.
One closing discipline: run this scenario as a tabletop once a year, with legal and procurement in the room, using a real vendor from your own top ten. The exercise costs an afternoon. The alternative costs a quarter.
Frequently Asked Questions
What should we do first when a vendor reports a breach?
Open two workstreams immediately: invoke the contract’s incident clauses in writing, and contain on your side of the boundary by rotating every credential the vendor holds and reviewing the network paths between their environment and yours. Do not wait for their forensics to act.
Are we required to notify customers if our vendor was breached?
In most regimes, yes. If your customers’ data was exposed through your supplier, the notification obligation generally remains with you, on your regulatory clock. The vendor’s own disclosure does not discharge your duty.
What evidence can we demand from a breached vendor?
Ask by name for the forensics findings, a confirmed intrusion timeline, the specific data sets affected with your records identified, indicators of compromise you can sweep for, and written confirmation of containment with dates — on a fixed update schedule.
How do we prepare for a third-party breach before it happens?
Write a third-party runbook inside your IR plan, put notification deadlines and cooperation duties into contracts, tier your vendors by access and data, and run an annual tabletop using one of your real top-ten suppliers.
About Author
