The Vendor Management Trap
Someone told you need a vendor risk management program. So you exported your accounts payable list and discovered 127 vendors. Now what—send questionnaires to all 127? Review every contract? Maintain a spreadsheet the size of a small database?
That way lies madness. And here's the thing: it's also the wrong approach.
Most vendor risk programs make a critical mistake: they treat contract value as the primary indicator of vendor importance. A million-dollar infrastructure contract gets intensive scrutiny, while the $50/month analytics tool quietly processing customer data gets almost none.
This creates a massive mismatch between perceived vendor importance and actual vendor risk.
The Real Principle: Risk-Based Tiering
The office plant service is not the same risk as your cloud infrastructure provider. But many programs treat them identically—either everything gets a checkbox review, or nothing gets reviewed at all.
What matters isn't contract value—it's data exposure, business criticality, and operational dependencies. A free Slack integration with admin access to your systems poses more risk than a $100K vendor with no data access. See how vCISO Lite scores vendors on these dimensions.
The solution is tiered classification: group vendors into risk categories, then apply proportional due diligence. More rigor where it matters, less where it doesn't.
The Four-Tier Framework
Tier 1: Critical (5-10 vendors)
These vendors can take down your business or expose sensitive data. They deserve real attention:
Examples
Cloud infrastructure (AWS, Azure, GCP). Core SaaS (CRM, your main line-of-business apps). Payment processing. Customer data processors. Identity providers (Okta, Google Workspace).
Assessment
Full security review with detailed questionnaire (SIG Lite or equivalent). Request and review SOC 2 report. Contract security terms review. Annual re-assessment. Monitor for breaches in security news.
Tier 2: Important (10-20 vendors)
These have meaningful access or could cause operational disruption, but aren't existential risks:
Examples
Communication tools (Slack, Zoom). HR/payroll systems. Development tools (GitHub, CI/CD). Support ticketing. Email marketing platforms.
Assessment
Abbreviated questionnaire (key controls only). Check for SOC 2 or ISO 27001 certification. Review data handling terms. Re-assess every 18-24 months or on renewal.
Tier 3 & 4: Standard and Minimal (Everything Else)
Office software, design tools, project management, office supplies, physical vendors. Verify basic certifications exist for Tier 3; standard procurement for Tier 4. Don't spend hours reviewing the catering company.
Two operational rules that override the tier logic above. First, if a vendor has access to multiple business resources, always assign them the highest applicable tier — risk is cumulative, not additive per system. Second, any vendor whose access is “unknown” starts as Tier 1 until you figure out what they actually touch. Unknown access is Tier-1-shaped by construction.
The Tiering Scorecard
When onboarding a vendor (or retroactively tiering your existing list), score them on three dimensions:
- Data Access: Customer data access: +10 points. Employee data (PII, HR): +5 points. Financial data: +5 points. No data access: 0 points.
- System Access: Production environment access: +10 points. API integrations: +5 points. Internal network access: +5 points. No system access: 0 points.
- Business Impact: Downtime stops revenue: +10 points. Significant operational impact: +5 points. Limited impact, easily replaceable: 0 points.
15+ points = Tier 1 | 10-14 points = Tier 2 | 5-9 points = Tier 3 | 0-4 points = Tier 4
Customer data: +10. Financial data: +5. API integration: +5. Revenue impact: +10. Total: 30 → Tier 1
Internal communication data: +5. API integrations: +5. Operational impact: +5. Total: 15 → Tier 1 (just)
Internal design assets only: +2. No integrations: 0. Limited impact: 0. Total: 2 → Tier 4
Red Flags in Vendor Reviews
When you do review vendors, watch for these signals:
Major Concerns
- No MFA option — disqualifying for Tier 1/2.
- Resistance to questionnaires — good vendors expect security reviews.
- No incident response plan — how will they notify you of a breach?
- Data in unexpected locations — know where your data actually lives.
Worth Noting
- No SOC 2 / ISO 27001 — not disqualifying for smaller vendors, but note it.
- Long questionnaire turnaround — may indicate immature security program.
- Generic responses — “we take security seriously” without specifics.
Managing Without a Full-Time Team
You don't need a dedicated vendor risk manager. Here's a sustainable rhythm:
Quarterly (2 hours): Check Tier 1/2 certification expirations. Review security news for vendor breaches. Update inventory with new additions. Annually (1 day): Re-tier all vendors. Request updated SOC 2 reports from Tier 1. Send refresh questionnaires to Tier 2. Trigger-based: New vendor onboarding. Vendor breach announcement. Contract renewal. Significant service change.
What per-vendor tiering misses: portfolio concentration risk
The four-tier framework above answers “which vendors deserve scrutiny.” It does not answer “which vendors are actually independent.” Two Tier-1 vendors that both run on the same upstream cloud, the same DNS provider, the same identity federation layer, or the same content-delivery network are not two independent risks — they are one shared-dependency risk wearing two logos. Per-vendor assessment misses this by construction.
The measurement discipline for portfolio-level risk is concentration analysis. The Herfindahl-Hirschman Index (HHI), which the U.S. Department of Justice publishes as the standard concentration metric for market analysis (below 1,500 = unconcentrated; 1,500-2,500 = moderate; above 2,500 = concentrated), maps cleanly to vendor portfolios: cluster your Tier-1 vendors by upstream shared dependency (cloud region, DNS resolver, identity provider, CDN, payment rail) and compute the concentration score across each cluster. Any cluster over 2,500 is where a single-vendor failure at the shared layer takes down multiple “independent” Tier-1 vendors at once.
The academic anchor here is Geer & Jardine’s Virginia Tech open-access paper On market concentration and cybersecurity risk, which formally applies HHI to cyber vendor concentration. The methodology isn’t vendor-proprietary; it’s a defensible extension of published economic theory into vendor-risk management.
The systemic pattern: CrowdStrike and Cloudflare
Two events in the last 18 months made concentration risk unignorable. On July 19, 2024, a CrowdStrike Falcon sensor update crashed roughly 8.5 million Windows machines worldwide — airlines grounded, hospitals slowed to manual, banking apps offline for hours. Every affected company had CrowdStrike as one Tier-1 vendor among many; the per-vendor risk assessment showed independent scores. The correlated risk showed up only at the portfolio level.
On November 18, 2025, a Cloudflare outage lasting roughly four hours took down banking apps, payment processors, and consumer-facing services across the globe. Same pattern: dozens of “independent” vendors turned out to depend on the same edge network. Aon’s 2025 Cyber Risk Report names both events by reference as the reason insurers now model systemic exposure rather than per-vendor exposure — the concentration story stopped being theoretical the day a single vendor update took down every other vendor in the portfolio simultaneously.
The regulatory floor: BCBS, DORA, NIS2
Regulators moved on concentration risk in the same window, and vendors selling into regulated buyers now inherit those obligations directly. Three anchors matter in 2025-26:
- BCBS Principles for the sound management of third-party risk (July 2024)— the Basel Committee’s first update in 19 years, superseding the 2005 Joint Forum outsourcing paper. Twelve principles, with concentration risk and third-party lifecycle named as first-class concerns. Every SaaS vendor selling into a bank now inherits this framing.
- DORA (in force January 17, 2025) — legally requires EU financial entities to maintain a Register of Information for all ICT third-party providers, cascade DORA obligations contractually, and demonstrate a concentration-risk management process. In November 2025 the European Supervisory Authorities published the first list of Critical ICT Third-Party Providers (CTPPs) — cloud and data-center providers now under direct regulator oversight.
- NIS2 Article 21(2)(d) (transposition deadline October 17, 2024) — requires essential and important entities across 18 EU sectors to manage supplier and service-provider security continuously, with contractual clauses that cascade the obligations. Vendors selling into NIS2-scoped buyers must show their own supply-chain policy.
The four-tier scorecard above is the operational baseline. For any buyer regulated under DORA, NIS2, or the BCBS principles, add a second axis: which of my Tier-1 vendors are themselves subject to these regimes, and do I have the contractual pass-through language the regulator expects.A perfectly-scored Tier-1 vendor without that pass-through can still fail your buyer’s regulator audit — and that failure lands on you as a procurement finding.
The Bottom Line
Effective vendor risk management isn't about reviewing every vendor with equal rigor—that's impossible and counterproductive. It's about knowing which vendors matter most, focusing limited time on critical risks, having a documented process you actually follow, and updating assessments when things change.
Five thorough vendor reviews beat 50 checkbox exercises. Start with your Tier 1 vendors—the ones with customer data, production access, or revenue impact. Get those right, and you've addressed the vast majority of your actual vendor risk.
The other 50 vendors? They can wait.