When a Vendor Calls With Bad News: The Customer's First-Day Playbook

The email arrives at 4:40 on a Thursday: your scheduling vendor, your payroll provider, your file-sharing service has detected unauthorized access, and an investigation is underway. Your data 'may have been affected.' More information will follow.

This is now your incident too, and the first day's decisions shape everything after: what you learn, what you preserve, what you tell your own customers, and how much of the response is controlled by you rather than discovered by them.

Most companies improvise this day. The ones that handle it well run a short, pre-agreed playbook that fits on one page. Here is that page.

Key takeaways

• A vendor's incident is your incident; the clock starts when you learn of it, not when they finish investigating.

• First calls: your IT lead and your vendor's contact, in that order - establish facts before interpretation.

• Map what data of yours they hold before deciding how worried to be.

• Draft your customer communication before you need it; silence reads as ignorance.

• Log every decision and timestamp from hour one.

Step 1: Establish facts before interpretations

The vendor's first notice is always vague by design; their lawyers are writing it. Your job is to get past it to operational facts: what systems of theirs were affected, what categories of your data live there, when the access started, and whether it is ongoing.

Get a named contact at the vendor and a commitment to update on a schedule - daily at first. Vendors go quiet precisely when their customers most need signal, and a promised cadence is easier to hold them to than an implied one.

Write down what you know, what you do not know, and when you learned each piece. That log becomes the backbone of every later conversation with customers, insurers, and your own board.

Step 2: Map your exposure from your own records

Do not wait for the vendor to tell you what they hold; you already know most of it. Which of your data lives in their system: customer records, employee records, credentials, files? Which of your systems connect to theirs, and with what access?

This fictional example shows the one-hour exposure map for a fictional vendor incident. It is an illustration, not a prescription.

Data at vendor	Volume	Sensitivity	Action
Customer contact records	~8,000	Moderate	Prepare notification draft
API key into our file storage	1	High	Rotate today
Employee SSO logins	140	Moderate	Force re-authentication

The rotation line is the one companies miss. If the vendor held keys, tokens, or passwords that reach into your systems, those change on day one, before the investigation tells you whether you needed to. The same discipline governs any vendor's standing access to your environment.

Step 3: Decide what your customers hear, and when

The instinct is to wait for certainty. The better instinct is to separate two questions: what must we tell them, and what should we tell them? The first is answered by your commitments to them; the second is a trust decision, and it usually favors a short, early note over a late, complete one.

A holding line works: we are aware of an incident at a vendor, we are assessing whether any of your data is involved, and we will update you by a specific date. It buys credibility that a month of silence spends.

The sequence in the incident communication matrix applies unchanged: decide the audiences and the order before composing the messages, not during.

Step 4: Capture the lessons while they are fresh

When the dust settles, two reviews matter. First, the vendor review: what did their response tell you about their maturity, and does the relationship change? Second, the internal one: how fast were your exposure map, your key rotations, and your customer note?

Feed both into the register. The vendor's entry should now carry a real incident history, and your own playbook should carry the improvements this run exposed. The vendor-offboarding checklist belongs in the same drawer, because sometimes the lesson is that the relationship ends.

The related discussion of vendor's standing access is worth your time alongside this one. The related discussion of vendor-offboarding checklist is worth your time alongside this one.

Frequently asked questions

Should we tell our customers before the vendor confirms our data was affected?

Usually a short holding note beats silence: it says you are on it without speculating. The exception is when you have verified quickly that your data was not involved - then a brief all-clear is even better.

The vendor says the investigation will take weeks. What do we do in the meantime?

Run your own response on your own clock: rotate shared credentials, map exposure, prepare communications, and monitor your own systems for odd access through their connection. Their timeline is theirs; your customers' trust is yours.

When does a vendor incident end the relationship?

When the pattern says it should: a second incident, a response that hid more than it shared, or an exposure map showing they held more of your data than the relationship justified. Decide on the evidence, not the apology.

A Defensible Next Step

Today, before any bad news arrives, pick your three most data-holding vendors and write down what they hold and who you would call. That fifteen-minute list is most of day one, done in advance. Book a Decision-Clarity Call if you want the playbook drafted for your vendor list.