SaaS Vendor Breach Response: What to Do When a Vendor Is Breached

In 2025, attackers compromised OAuth tokens tied to the Drift chat integration and used them to access data across more than 700 organizations that had connected Drift to their own systems, according to public breach disclosures from Salesloft and affected companies including Google and Cloudflare. None of those organizations were breached directly. Their exposure came entirely through a vendor they trusted enough to connect.

That's the situation this article is about: not preventing a vendor breach, but knowing what to do in the hours and days after you learn one has happened.

Why vendor breaches require a different response than your own

When your own systems are breached, you control the investigation from the start. When a vendor is breached, you're dependent on their disclosure timeline, their forensic findings, and their willingness to share detail, while still carrying much of the legal and reputational responsibility yourself. In most U.S. states, the organization that owns the data, not the vendor that processed it, holds the primary legal obligation to notify affected individuals and regulators when personal information is exposed, even though the incident happened on someone else's systems.

That mismatch, limited control paired with real obligation, is what makes vendor breach response its own distinct problem rather than a smaller version of standard incident response.

The first 24 to 48 hours

Confirm what the vendor actually told you, and what they didn't. Initial vendor breach notifications are often vague on scope, sometimes deliberately, sometimes because the vendor genuinely doesn't know yet. Note explicitly what's confirmed, what's suspected, and what's still unknown, rather than treating an early notification as a complete picture.

Determine what that vendor actually had access to in your environment. This is the question that decides everything downstream, what data could have been exposed, and it's the one companies most often struggle to answer quickly. If you don't already have a clear record of what permissions and data access this vendor held, reconstructing it after the fact under time pressure is a significantly harder version of the same task.

Revoke or rotate any credentials, tokens, or API keys connected to the vendor immediately, even before the full scope is known. In the Salesloft Drift incident, the exposure spread specifically through OAuth tokens that remained valid, so cutting off that access path early limits how much an already-compromised connection can still be used.

Loop in legal counsel before drafting any external communication. Notification timelines, required language, and even whether notification is legally triggered at all depend on what data was actually exposed and which states or jurisdictions your affected individuals are in. This is not a decision to make from the security or IT side alone.

Start a documented timeline immediately. When the vendor notified you, when you confirmed scope, when you revoked access, and every decision made in between. This record matters for your own legal defensibility and is exactly the kind of evidence a regulator or a later audit may ask to see.

Assessing the actual scope of your exposure

Cross-reference the vendor's disclosed timeline against your own access logs. If the vendor believes the compromise started on a specific date, check what that vendor's connection actually did in your systems during that window, rather than relying solely on the vendor's own account of what happened.

Identify every downstream system connected to the breached vendor, not just the primary integration. A compromised OAuth token or API key connected to one tool can sometimes provide a path into other systems through chained integrations, which is part of why the Drift breach spread across so many organizations through a single point of compromise.

Check whether the vendor's access included any of your other vendors or subprocessors. A breach at one vendor can expose data that flows through to a second vendor downstream, and that fourth-party exposure is easy to miss if your assessment stops at the immediately compromised tool.

Notification and ongoing obligations

Determine your notification obligations based on what was actually exposed, not on how the breach happened. Most state breach notification laws are triggered by exposure of personal information, with specific timelines that vary by jurisdiction, some now requiring individual notification within 30 days of discovery. The fact that the exposure originated at a vendor doesn't generally change whether you're obligated to notify, only who else needs to be included in the response.

Review the vendor contract for what it actually obligates them to provide. A well-negotiated vendor agreement should include a defined breach notification window and cooperation requirements, but many companies discover during an actual incident that these terms are vaguer than they assumed, or missing entirely.

Communicate clearly that the incident occurred in a vendor's environment, without shifting blame or making claims about an investigation you can't yet verify. Affected customers and employees generally respond better to a clear, honest account of what's known and what's being done than to language that reads as deflecting responsibility.

What to change afterward

Revisit which of your vendors hold the kind of access that made this incident possible. A breach at one vendor is a reasonable prompt to check whether similar access exists elsewhere in your stack, not just to close the specific gap that was exploited this time.

Confirm the OAuth tokens and API connections tied to the breached vendor were fully revoked, not just the primary login. Standing connections established through integrations sometimes survive a surface-level account deactivation, which is part of what made the Drift incident persist as long as it did across affected organizations.

Where OptyStack fits

Answering "what did this vendor actually have access to" quickly is the single biggest factor in how fast a company can assess real exposure after a vendor breach, and it's difficult to answer under time pressure without an existing record of vendor connections and access.

OptyStack maintains visibility into the applications and third-party connections across your SaaS estate, including access tied to specific vendors, so that record already exists before an incident happens rather than needing to be reconstructed during one.

It's free to start and doesn't require a credit card.

Know what every vendor in your stack can access, before you need to find out fast. Start free with OptyStack.