Assume the Vendor Is Compromised: The Hour-Zero Playbook

When a vendor is breached, the clock that matters is not theirs. It is yours. A direct breach compromises one organization. A vendor breach compromises everyone downstream of that vendor at the same moment. The 2023 MOVEit campaign is the clearest example on record: a single flaw in one file-transfer product reached more than 2,700 organizations, most of them customers of customers who never touched the software directly. Our Third-Party Cyber Risk Report found third-party involvement in breaches has doubled to 30%, and the hard part is that you often learn about these events from a news headline or a terse vendor email, not from your own monitoring.

The teams that come through a vendor breach well are not the ones who improvise fastest. They are the ones who wrote the playbook on a calm day. Here is what that playbook contains.

Why a vendor breach is a different kind of incident

Your standard incident-response plan quietly assumes you own the compromised system. In a vendor breach, you usually do not, and that changes every step.

• You do not control the investigation. The timeline, the forensics, and the disclosure belong to the vendor. You are working from partial information that arrives on their schedule, not yours.
• The blast radius is the vendor's reach, not your size. A small vendor with broad access or a wide customer base can carry more risk into your environment than a large one with none.
• The entry point is legitimate access. The vendor's credentials, API tokens, and standing integrations are valid access into your systems. A vendor compromise turns that trusted connection into an attacker's connection, and it will look legitimate in your logs until you look closely.

The real work happens before hour zero

You cannot build any of this during the incident, which is exactly when everyone tries to. Prepare it in advance.

• Keep a vendor inventory that maps access, not just names. For each critical vendor, know what data it holds, what access it has into your environment, and which fourth parties it depends on. The vendor you forgot about is the one with a standing integration nobody has reviewed since onboarding.
• Pre-build the kill switches. Know, ahead of time, how to revoke a vendor's credentials, tokens, and integrations quickly, and know what breaks when you do. The middle of an incident is a bad time to discover that cutting off a vendor also takes down your billing.
• Name the decision-maker now. Shutting off a critical vendor is a business decision as much as a security one. Decide in advance who makes that call, so the person recommending it in the moment is not also fighting to be heard.
• Rehearse it. Put a vendor-breach scenario into your tabletop exercises. The dependencies and workarounds you discover in a drill are the ones that would otherwise surface at the worst possible time.

The four moves at hour zero

1. Scope your exposure, not theirs. Do not wait for the vendor's full report. Determine what access and data this vendor has in your environment, and start looking for signs that access has been misused. Their incident is context. Your exposure is the thing you act on.
2. Contain the trust relationship. Rotate or revoke the vendor's credentials, tokens, and standing integrations. Treat that valid access as attacker access until proven otherwise. This is the moment your pre-built kill switches earn their keep.
3. Hunt for the access being used. Pull logs for the vendor's connections, service accounts, and integration activity. A vendor compromise shows up as legitimate credentials doing things they have never done before: new source addresses, odd hours, unusual data volumes.
4. Communicate on your own timeline. Decide what you tell customers, regulators, and leadership based on your exposure, not the vendor's public-relations schedule. Report what you can defend: what access existed, what you have contained, and what you are still verifying.

After the first hour

Treat the vendor's "all clear" as provisional and verify before you restore the trust relationship. Then use the incident as evidence for your vendor program: tier vendors by blast radius rather than contract size, because the provider that just cost you a weekend may be one of your smallest. A single vendor breach can ripple across an entire sector at once, as the recent wave of financial-sector incidents showed when one provider's compromise reached dozens of downstream institutions. Feed every lesson back into the plan and the tabletop, and pressure-test the whole approach against your broader incident-response plan so the vendor scenario is not a special case bolted on the side.

Frequently Asked Questions

What should you do first when a vendor is breached?

Scope your own exposure before waiting on the vendor's full report. Determine what access and data the vendor has in your environment, then contain that trust relationship by rotating or revoking the vendor's credentials, tokens, and integrations, treating that access as compromised until proven otherwise.

How is a vendor breach different from a normal incident?

You do not control the investigation, timeline, or disclosure, the blast radius reflects the vendor's reach rather than your own size, and the entry point is legitimate access, the vendor's valid credentials and integrations, which looks normal in your logs until examined closely.

How do you prepare for a third-party breach in advance?

Maintain a vendor inventory that maps each critical vendor's access and data, pre-build the ability to revoke that access quickly and understand what breaks when you do, name the decision-maker who can cut off a vendor, and rehearse a vendor-breach scenario in your tabletop exercises.

Should you immediately cut off a breached vendor?

Contain the vendor's access quickly, but understand the operational cost first, which is why the kill switches and dependencies should be mapped in advance. The decision to fully sever a critical vendor is a business call as well as a security one, so it should be made by a pre-designated owner rather than improvised mid-incident.