A company may pay 30 vendors and assume its tools are spread out, yet many of those vendors sit on the same few platforms: one cloud, one identity provider, one DNS service, one email provider, one payment processor, or one AI model provider. When one of those underlying platforms goes down, more of the business breaks than the contracts suggest. A four-step mapping exercise, run against a fictional 200-person company, narrows 30 line items to about five real choke points, and a four-week plan turns that map into exit terms, export drills, and backup identity paths.
Why 30 vendors can mean five choke points
Vendor lists look diverse on paper. Underneath them, a small number of shared providers carry most of the load. The exercise starts by listing every direct vendor, then asks one question for each: what does this product actually depend on to run?
Layer by layer, the dependencies collapse into a handful of providers. A SaaS tool depends on a cloud. The cloud depends on DNS and identity. Email, payments, and AI inference point at the same few names. A 200-person company with 30 vendors typically lands on about five choke points once the layers are drawn.
That single number reframes the risk conversation. The threat is not one vendor failing. It is one of the five underlying platforms failing and dragging several vendors with it.
What warning signs to watch for
Watch for multiple vendors running on the same underlying platform, overlapping dependency chains that compound a single failure, and shared cloud regions without documented failover.
- Two or more critical tools run on the same cloud region with no documented failover.
- Single sign-on depends on one identity provider with no tested backup path.
- DNS for production domains is managed by one vendor, or by a reseller of one vendor.
- Outbound email, payment processing, or AI inference all route through one provider each, with no alternate ready.
- Vendor contracts are silent on exit help, data export format, or service-level commitments during outages.
Each item prompts one more question before signing or renewing.
Questions to ask every critical vendor
The exercise gives security and IT teams a short script they can run against every vendor that touches a choke point, surfacing the exit help, data export format, and service-level commitments that contracts leave undefined.
- Which cloud, identity provider, DNS service, and AI model provider do you depend on to deliver your product?
- If one of those goes down, which of your features stop, and which keep working?
- What is your exit clause, and how many days of professional services or documentation do you provide to help us leave?
- In what format can we export our data, and is that export tested, or only promised?
- What does your SLA actually pay out during a multi-hour outage, and what is excluded?
- Can we run a trial export or a trial migration before we sign?
Answers to those six questions tell a team whether a vendor is a real choice or a hidden copy of someone else’s risk.
Contract terms that change the outcome
Three clauses do most of the work after the dependency map is drawn:
- Exit help: a defined number of days of vendor-assisted migration, with named contacts, not a generic support queue.
- Data portability: a documented export format the vendor actually tests, with sample exports available on request.
- SLAs: credits that scale with outage length, and exclusions written in plain language, not buried in definitions of force majeure.
Renegotiation works best while a contract is up for renewal and a competitor has a real shot at the business.
Architecture moves that reduce blast radius
The exercise pairs the legal work with architecture habits that cut the damage when a choke point fails: build on open protocols so switching providers is a configuration change, not a rewrite.
- Standard protocols. Where possible, build on open protocols so switching providers is a configuration change, not a rewrite.
- Export drills. Run a trial export from each critical vendor on a schedule, not just at renewal. Treat a failed export the same way an outage is treated.
- Backup identity paths. Keep a tested second identity provider, or at minimum a documented break-glass admin path, so a single sign-on outage does not lock the company out.
Each move caps the blast radius of one vendor failure below the replacement cost of that vendor.
The four-week plan teams can start on Monday
Four-week schedule designed to fit alongside normal operations:
- Week 1: list every direct vendor in a spreadsheet, with owner, renewal date, and annual spend.
- Week 2: for each vendor, record the cloud, identity, DNS, email, payments, and AI model provider underneath it.
- Week 3: count the dependencies. The vendors that show up most often are the ones to monitor, renegotiate, or back up first.
- Week 4: schedule one export drill, one identity failover test, and one vendor contract review tied to the highest-count choke point.
By the end of week four, a team has a visible map of its real exposure, one tested exit path, and one contract in better shape than it was on Monday.
FAQ
What is vendor concentration risk?
Vendor concentration risk is the danger that comes from many direct vendors depending on a small number of shared underlying providers, such as one cloud, one identity provider, one DNS service, one email provider, one payment processor, or one AI model provider. An outage at one of those providers can break several vendors at once.
How do you find vendor concentration risk in a company?
List every direct vendor, then for each one record what it depends on underneath: cloud, identity, DNS, email, payments, and AI model. Count which underlying providers appear most often. A 200-person company with 30 vendors typically lands on about five choke points once the layers are drawn.
What should be in a vendor contract to reduce concentration risk?
Three clauses do most of the work: a defined exit-assistance period with named contacts, a tested data export format with sample exports available, and SLAs whose credits scale with outage length and whose exclusions are written in plain language.
This article summarizes reporting from helpnetsecurity.com.