When Your Vendor Calls to Say They Were Breached

The call comes in mid-afternoon on a Thursday. A security contact from a vendor you use for HR data processing, or cloud storage, or payment handling informs you they have had an incident. They are "in the process of notifying affected customers." Your data was in their environment. They will share more details as the investigation progresses.

You are now managing an incident in someone else's environment, with none of the visibility and all of the liability.

This is not the scenario your incident response plan was written for. Most IR plans assume you are the primary victim: you have access to logs, you can image systems, you can query your SIEM, you can isolate the affected network segment. A third-party breach notification flips all of that. You cannot touch the environment where the incident occurred. The attacker moved through someone else's infrastructure. Your evidence is in someone else's custody.

What you can do - and what you need to do quickly - is scope your exposure, meet your own obligations, and decide whether this becomes your incident.

The First Question Is Not "What Happened"

When you get the call, the instinct is to learn as much as possible about the incident itself. What kind of attack was it? How long were they in the environment? What exactly was accessed?

These questions matter eventually. They are not the first questions to answer.

The first question is: what data was in that environment and who does it belong to? Before you can notify anyone, before you can assess regulatory exposure, before you can determine whether this triggers your cyber insurance, you need a data map. You need to know specifically what you transmitted to or stored with this vendor, under what agreements, and whether that data includes anything that creates downstream obligations on your end.

This sounds like information you already have. In most organizations it is not organized in a form that lets you answer the question quickly. Vendor contracts are in legal's system. Data flow documentation is outdated or absent. The original project that onboarded the vendor happened two years ago and the people involved have moved on.

Run down the data map first. Everything else flows from it.

The Notification Clock Is Already Running

Depending on what data was exposed and who it belongs to, you may have notification obligations that started the moment the breach occurred - not the moment you learned about it. GDPR, CCPA, HIPAA, state breach notification laws, and your own customer contracts all operate on different timelines with different triggers. Some require notification within 72 hours of the controller becoming aware. Some require direct notification to the individuals affected, not just to a regulator.

The vendor is handling their notifications. That does not automatically satisfy yours.

If the breach exposed personal data belonging to your customers or employees, you may need to notify them directly. If it exposed protected health information, you have HIPAA reporting obligations regardless of which company was operating the servers. If you hold data under a customer contract that specifies breach notification timelines, those timelines are running.

Get legal and compliance involved early, not after you have finished scoping the technical exposure. The regulatory analysis needs to happen in parallel with the technical assessment, because the legal obligations have hard deadlines and "we were still investigating" is not a defense that reliably works.

What to Ask the Vendor, and What You Will Not Get

You need specific information from the vendor to do anything useful. You want a detailed timeline of the incident, the indicators of compromise, the specific data sets affected, and confirmation of whether your data was confirmed accessed or merely potentially accessible.

What you will actually receive, especially in the early stages, is carefully worded language about an "unauthorized access event" affecting "certain systems" with "customer data potentially impacted." The vendor is managing legal exposure simultaneously with managing the incident, and communications are reviewed by counsel before they go out. This is understandable. It is also genuinely limiting.

Push for the specifics anyway. Ask directly whether your data was confirmed as accessed in logs, or whether it is assumed accessed because it was in an affected system. Ask for the date range of the attacker's access. Ask what authentication logs show regarding your credentials or API keys. Ask whether the attacker moved laterally and what evidence exists about scope.

You will get more information faster if you treat the vendor's security team as a partner rather than an adversary. They are dealing with a bad situation. Being specific about what you need - rather than demanding a full forensic report within 24 hours - tends to produce better cooperation.

Deciding Whether This Becomes Your Incident

Not every third-party breach notification becomes your incident. Some of them are genuinely low-impact: the vendor was breached, your data was in a system not affected, or the data exposed was low-sensitivity and creates no downstream notification obligation.

The threshold for treating a third-party notification as your own incident is roughly this: if the exposed data creates obligations on your part (regulatory, contractual, or to the individuals affected), or if the nature of the access suggests the attacker may have moved into your environment or used vendor access to stage further attacks, you are running your own incident.

In practice, if the vendor held authentication credentials, API keys, or tokens that could be used to access your systems, rotate them immediately without waiting for confirmation that they were specifically accessed. The cost of rotating a set of API keys is low. The cost of finding out six months later that those keys were used to establish persistent access in your environment is considerably higher.

Document the Vendor's Communications

Everything the vendor sends you is evidence. The initial notification, follow-up emails, the forensic summary, the confirmation of scope - save it all, timestamped, in a location your legal team can access. If this ends in regulatory investigation, customer litigation, or an insurance claim, your documentation of what you knew and when you knew it will matter.

The third-party breach scenario is the one where your incident response capability gets tested in the most constrained conditions: limited information, tight timelines, obligations you cannot fully assess until someone else finishes their investigation. Having a pre-planned response - who you call, what you document, what questions you ask, what your data map looks like - is what makes the difference between a well-managed response and three weeks of controlled chaos.

One more thing worth saying: when this happens to you, it will also happen to your own customers someday if you hold their data. The experience of being on the receiving end of a third-party notification is clarifying. It makes the case for your own breach notification procedures in a way that compliance requirements alone rarely do.