标签：#vendorrisk

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 re