Your Vendor Says They Were Breached. What Do You Actually Do?

The email arrives from a software company you use, or a contractor, or a platform you half-remember signing up for. It says they have experienced a security incident. It says they take your security very seriously. It does not say, in plain terms, what of yours was in there.

Your job over the next few days is to convert that vague notice into three specific answers: what of mine did they hold, what of mine was actually exposed, and does that trigger anything I have to do. None of that comes from the notice itself. It comes from a call, from your own records, and from a short list of checks on your own systems.

This is written for the owner or office manager who just got the email. Not a technician.

First, decide which kind of notice this is

There are two very different versions of "we had an incident," and the notice usually does not tell you which one you got.

The first is a general announcement - sent to every customer because the company is disclosing publicly. Your data may or may not be involved at all.

The second is a notification directed at you because your data, or your users' data, is believed to be involved. Sometimes this arrives as its own email or letter. Sometimes it is the same announcement, and the "your data was involved" part only appears in a follow-up, a portal message, or a phone call you have to initiate.

The first question you are trying to answer is which one you are holding. Do not assume the general announcement means you are clear, and do not assume it means you are exposed. It means you need the call.

The first call: what to ask, and what the answers tell you

Ask for a named contact and a call, in writing, so there is a record. On the call, in this order:

Was our data involved - yes, no, or not yet determined? "Not yet determined" is a legitimate answer early in an investigation, but it is not a final one. Ask when they expect to know, and write the date down. A provider that will not commit to telling you either way is telling you something about how the rest of this will go.

What categories of data, specifically? You are not asking for a technical report. You are asking whether the involved systems held names and email addresses, or passwords, or financial account details, or the contents of files, or health information, or your customers' personal data. Each category points at a different level of urgency and a different set of obligations on your side.

Was it access, or exfiltration? Someone got in is not the same as someone took data. Early in an investigation, providers often know the first and not the second. If they say "no evidence of exfiltration," ask whether that means they have ruled it out or have not finished looking - those sentences sound identical and are not.

Were credentials involved - ours, or theirs that protect ours? If the incident touched the account you sign in with, an API key, an integration token, or anything their systems use to reach into yours, you have work to do on your own side immediately, before the investigation finishes.

Is law enforcement or a regulator involved, and is there anything we should not do? Occasionally there is a reason to delay notification or preserve something. Rare, but ask once.

Will you confirm this in writing? Everything above, by email, from the named contact. If the answer is no, your own notes from the call become the record, so take them in real time.

Two things the answers tell you that the words don't: a provider who can answer specifically, quickly, has done this before and has an investigation running. A provider who reads you the press release over the phone does not yet know what happened to you.

Work out what of yours they actually held

Do this from your own records, not from their answer - their answer describes what they think they hold, which is not always the same thing.

List every place your business touches this vendor: what system it is, which of your people use it, what data goes into it in the ordinary course of work, and what it connects to. The obvious entries are the ones in the contract. The ones that bite you are the file a staff member uploaded once, the integration someone set up two years ago, the support ticket with a screenshot full of customer data, the backup they kept that you forgot about.

Pay particular attention to three categories, because they convert their incident into your incident:

Shared or stored credentials. Any password, API key, or token this vendor holds that also unlocks something of yours. If anyone on your team reuses a password between this service and anything else, that password is now a liability everywhere it works.

Integrations and connected apps. If the vendor's product is connected to your email, your file storage, your accounting system, or your customer database, the question is not only what data they stored - it is what their access could reach. A token with read access to your file storage is exposure of the storage, not just the files you sent them.

Other people's data that you are responsible for. Customer records, employee records, patient or client information, payment details. If any of that sat with this vendor, their breach may be your notification problem, which is the next section.

What to check on your own side

Do these even if the vendor says your data was not involved. They are cheap, and investigations revise their early findings more often than anyone likes.

Sign-in history for the vendor account itself. Look for sign-ins to your account on their platform from places, devices, or times that do not fit your team. Their incident may have included active use of customer accounts before it was caught.

Every credential that touches the vendor. Reset the password on the vendor account, revoke and reissue any API keys or tokens, and sign out existing sessions. If anyone reused that password anywhere else, reset it there too. Treat this as done when you have a list and every item on it is struck through, not when someone says they think they got them all.

The integrations. Review what the vendor's product is connected to and what level of access it has. If the connection is not earning its keep, this is the moment to remove it. If it stays, confirm it has only the access it needs.

Your own monitoring, aimed at the access paths. If the vendor could reach your email, files, or line-of-business systems, watch those for anything unusual in the period since the incident window they gave you. You are looking for the thing the vendor's notice cannot tell you: whether anyone used their access to get to you.

Whether their breach triggers obligations of yours

This is the part people avoid thinking about, and it is the part with clocks attached.

If the data the vendor held was yours - your business records, your credentials - the incident is mostly an operational problem and the sections above cover it.

If the data included personal information about your customers, your employees, or anyone else whose data you are responsible for, then notification obligations may attach to *you*, not just to the vendor. Those obligations exist under state breach-notification laws, under regulations that apply to particular kinds of data, and under contracts you have signed. They differ in who must be notified, how, and by when - the deadlines vary by state, by regulation, and by contract, and some of them are short. Which ones apply to you, and whether the facts as the vendor has reported them actually trigger one, is a determination for your attorney, made early, not a decision to improvise from the vendor's press release.

The same applies to your cyber insurance. Many policies require you to notify the carrier of incidents that could give rise to a claim, and a vendor incident involving your data can qualify. Late notice is one of the ordinary ways coverage disputes start. If you have a policy, read the notice provision and let the carrier know early; telling them is not the same as filing a claim.

The practical rule: the moment you learn that other people's information was in the vendor's systems, the next two calls are your attorney and your carrier - before you decide anything about notification yourself.

What to write down

Start the record with the notice itself, saved as received, with the date and time it arrived. Then keep a running log: every call, who you spoke to, what they said, what they committed to and by when; every check you ran on your own side and what it found, including the clean results; every credential reset, token revoked, integration reviewed; and every decision you made and why.

Two things make this worth the effort. If the investigation's findings change - and they do change - your log is how you know what you already handled and what the new facts reopen. And if this later becomes an insurance claim, a contractual dispute, or a regulator's question, the businesses that come out of it well are the ones that can show a dated, orderly record of having taken it seriously from the first day.