When a vendor is breached, don't wait for their update page: figure out fast what that vendor can see or touch inside your business, and act on that answer before you have all the facts.
Vendor breaches are a recurring headline: a phone system, messaging platform, or file-sharing tool used by thousands of businesses discloses an incident, and every customer of that vendor suddenly has to ask what it means for them, usually with almost no visibility into the vendor's internal investigation. The gap between "something happened to our vendor" and "here's what we do about it" is where most companies lose time they can't get back.
Quick answers
What's the first thing to do when a vendor is breached?
Confirm exactly what that vendor can access in your systems — before you do anything else.
Should I rotate credentials before the vendor confirms exposure?
Yes, for anything plausibly exposed — even though it may briefly disrupt a live integration.
How often should I re-check a slow-to-disclose vendor?
It depends on how much access they hold — high-privilege vendors need a 48–72 hour check-in, not a week.
Do I need a written plan before an incident happens?
Yes — a one-page plan per privileged vendor, reviewed at least yearly.
Why vetting a vendor once isn't enough
Most businesses do vendor due diligence at signup: a security questionnaire, maybe a look at their trust page, a checkbox before the contract is signed. That's reasonable, but it only answers the question that matters on day one: is this vendor safe to start using?
It doesn't answer the question that matters every day after: if this vendor gets breached, what happens to us, and what do we do?
Vetting is a point-in-time filter. A breach is an ongoing event with a timeline, and your response needs its own plan, separate from the vetting checklist you ran before signing.
The fix is simple: treat vendor risk as a lifecycle, not a gate. Vet before you sign, revisit access and exposure on a regular cadence, and have a response plan ready for the vendors that matter most.
Your first 24–72 hours: a vendor breach checklist
When a vendor discloses an incident, work through this in order rather than waiting for their full report:
Confirm what the vendor actually does for you. List every system, integration, and data type connected to that vendor — not what you think it touches, but what it's actually configured to access.
Check what credentials or tokens are shared. API keys, SSO connections, webhooks, and stored payment or contact data are what attackers pivot on. Rotate anything that's plausibly exposed, even before the vendor confirms it was — accept that this may briefly break a live integration. That's a smaller cost than leaving a compromised credential live, but coordinate with whoever owns the integration so the break is expected, not a surprise outage.
Check what your contract actually gives you. Look for a breach notification clause (how fast the vendor is contractually required to tell you), any SLA language on incident disclosure, and a right-to-audit clause you can invoke to get more than their public statement offers. If your contract has none of these, that's a gap to fix at renewal — not something you can retrofit mid-incident.
Pull recent activity logs. Look for unusual logins, data exports, or configuration changes tied to that vendor's integration in the window since the breach likely started. Vendors often understate this window early on.
Loop in whoever owns customer communication and compliance. If customer or employee data may have moved through the vendor, your own notification obligations may kick in. Check what applies to your industry and state rather than assuming a fixed deadline.
Document the decision, not just the action. Write down what you knew, when, and why you chose to rotate credentials, pause the integration, or wait for more information. Log it in the same one-page plan or incident doc (see below), owned by whoever is running the response, and retain it for as long as your industry's record-keeping obligations require — this matters if a regulator or customer asks later.
If you don't have anyone in-house who can run this checklist under pressure, that's a gap worth closing before the next vendor incident, not during it. This is exactly the kind of work covered under incident response.
Figure out your actual blast radius
Not every vendor breach is your problem. A breach of a vendor's marketing database is very different from a breach of a vendor that holds your SSO tokens or has admin access to your cloud environment.
A simple heuristic: rank your vendors by what they can do, not what they cost. A vendor with write access to your infrastructure, your identity provider, or your customer data deserves an incident plan. A vendor that only has your name and email for a newsletter probably doesn't need the same level of response.
In one engagement, a venture-backed, fast-growing technology company with no dedicated security hire brought us in for a cloud security review across AWS and GCP, alongside manual application and infrastructure penetration testing and virtual CISO leadership. The review surfaced 900+ AWS findings and worked through 580+ GCP findings to remediation, brought endpoint EDR coverage to 100%, and — during the engagement — we identified and contained one active intrusion.
That containment was only possible because the access map already existed: we knew which systems, credentials, and integrations mattered before the intrusion turned up, which is exactly the map you need on hand before a vendor breach forces the same question about a system you don't control. Details are in our case study.
Build the plan before you need it
Handling a vendor breach well comes down to one thing decided in advance: who owns the call to cut a vendor's access, and how quickly that can actually happen on your systems. A vetting spreadsheet doesn't make that call under pressure — a named owner and a tested process do.
Here's a template you can copy directly, for any vendor with privileged access (identity, payments, cloud infrastructure, core communications):
Vendor Breach Response Plan — [Vendor Name]
- Owner: [name/role] — the person authorized to cut access without a meeting
- Access this vendor holds: [systems, data types, integrations, credential types]
- Notify first, in order: [internal roles]
- Immediate action: [specific credentials/integrations to rotate or disable]
- Customer/compliance trigger: [conditions requiring external notification, and who drafts it]
- Re-check date: [set explicitly — see blast-radius guidance below]
Format: one page, kept wherever your team already stores operational runbooks (shared drive, wiki, or IR tool) — not buried in email.
Owner: whoever holds the security lead or vCISO role keeps it current.
Retention: keep completed plans, with decisions logged, for as long as your compliance obligations require incident records to be retained; review the plan itself at least once a year or whenever the vendor relationship changes significantly — a new integration, more data, or a higher access level.
If you don't have the internal bandwidth to build and maintain this across a growing vendor list, a fractional security lead can own it without you hiring full-time. That's the core of what a virtual CISO does, and it pairs naturally with compliance support if notification obligations are part of the picture.
What if the vendor is slow or won't tell you anything?
This is the realistic failure mode, and it's common. Vendors under legal advice often say very little in the first days. Don't wait for their statement to act.
Work from what you control: rotate your own credentials and tokens regardless of confirmation (accepting the integration risk noted above), restrict the vendor's access to the minimum your operations can tolerate, and set a firm re-check date rather than "when they update us."
How firm depends on the same blast-radius logic from earlier: for a vendor with privileged access to identity, payments, or infrastructure, check back in 48–72 hours, not a week — that's the reason they landed in the high-risk tier in the first place. For a lower-access vendor, a week is a reasonable cadence.
If a high-access vendor stays silent past your re-check date, that silence is itself a decision point — consider suspending the integration until you get real answers.
The takeaway
Vendor breaches are going to keep happening. That's the reality of running a business on other people's software. What separates a bad week from a bad year is whether you had a response plan sitting ready, or whether you're building one from scratch while the news is still breaking.
If you're not sure how exposed your business is to your current vendor stack, a good starting point is a free security review. It's a low-friction way to see where your real access risks sit before you need to react to one.
Want this looked at for real? Get a free security review and we will show you where you actually stand.
Top comments (0)