Our vendor got breached. Are we at risk?

The question

The timing made this an easy one to answer with a real example. A vendor that handles electronic document management for a long list of enterprise clients left a database sitting open on the internet — no password, fully public. Researchers found it first: 48 databases, close to 300GB, roughly 30 million records. Invoices, tax documents, employee accounts, plaintext credentials, API tokens, supplier details, spanning clients across eight countries.

What we told them

It's both. The vendor caused it, but the moment your data or credentials show up inside their exposed system, it's your incident too — not just theirs to clean up quietly.

Here's what we had them do, in order:

• Get specifics, not reassurance. "We take security seriously" is not an answer. Ask exactly which of your records were in the exposed system, and ask for it in writing — you need this for your own records and possibly for regulatory or contractual reasons.
• Rotate anything shared with that vendor. API keys, portal logins, any credentials the vendor's systems held on your behalf — treat all of it as compromised and reissue it. A leaked API token doesn't expire when the news cycle does.
• Check what the exposure enables. Invoices and tax documents in the wrong hands are raw material for invoice fraud and impersonation — a convincing fake bill from a "known" supplier is exactly the kind of thing this data supports. Flag it to whoever approves payments.
• Decide if you owe your own customers a notice. If the vendor held data on your behalf that includes your customers' information, your breach-notification obligations may kick in even though you weren't the one hacked.

The uncomfortable part: none of this shows up in most vendor contracts as "your job." Due diligence usually stops at signing — a security questionnaire, a checkbox, maybe a SOC 2 report that's a year old. Nobody goes back and checks whether the vendor is still doing what the questionnaire said.