The Vendor Behind Your Vendor: Fourth-Party Risk and Concentration

Category: Operational Resilience Author: Cody Swidler Tags: third-party risk, fourth-party risk, concentration risk, TPRM, DORA, vendor management

The most instructive outage I've worked started at a company nobody in the room had ever heard of. Our vendor was fine — their status page was green, their account manager was responsive, their SOC 2 was clean. But their document-processing subcontractor had failed, and our client onboarding stopped moving. It took four hours to even establish why we were down, because the company that had actually broken didn't appear on any list we maintained. We had assessed the vendor. We had never met the vendor's vendor.

Every vendor list conceals a second list. Your payroll provider runs on someone's cloud. Your claims processor sends documents to an OCR shop you've never evaluated. Your market data vendor licenses its feed from an upstream aggregator that is, quietly, the same aggregator your backup vendor uses. Third-party risk programs assess the companies you signed contracts with; the failures increasingly arrive from the companies they signed contracts with.

Concentration Is the Multiplier

Fourth-party exposure would be manageable if it were diverse, but it isn't — it concentrates. Modern supply chains funnel through a handful of cloud platforms, payment rails, identity providers, and data aggregators, which means your carefully diversified vendor portfolio may be a monoculture one layer down. I've run the mapping exercise at several organizations, and the result is always the same shape: ten strategically chosen, individually assessed, contractually diversified vendors — six of which turn out to sit in the same cloud region. The redundancy you paid for at layer three doesn't exist at layer four.

This is why concentration deserves its own analysis rather than a question buried in a due-diligence form. The question isn't "is this vendor risky?" — it's "what single upstream failure takes out multiple vendors at once, and which of my critical processes are standing downstream of it?" That's a resilience question, not a procurement question, and answering it requires joining your vendor inventory to your process dependencies — which is exactly the kind of cross-assessment join I argued for in integrating risk assessments. Your BIA already knows which processes are Tier 1 and which vendors they depend on. The concentration analysis just asks what those vendors have in common.

The Regulators Got There First

If the operational argument doesn't move your organization, the regulatory one now will. DORA's third-party provisions explicitly reach subcontracting — financial entities are expected to understand the chain supporting critical functions, weigh concentration risk before signing, and maintain a register of information covering their ICT arrangements, not just their direct contracts. Examiners on the FFIEC side have been asking sharper versions of the same questions. As I wrote in DORA is not an IT problem, treating this as an IT compliance chore misses what's actually being demanded: evidence that someone in the organization understands the dependency chain and has decided, deliberately, how much of it to accept.

The uncomfortable part is that you can't fully outsource the discovery. Vendors disclose subcontractors reluctantly, generically, and in contract language designed to preserve flexibility. Getting real answers takes contract clauses that require disclosure of material subcontractors, reassessment questionnaires that ask specifically about the dependencies behind your service, and — for your most critical vendors — the direct question in the annual review: "walk me through what happens to my service when your primary infrastructure provider has a regional outage."

What a Proportionate Program Looks Like

You cannot map every vendor's supply chain, and you shouldn't try — a fourth-party program that attempts full coverage will drown in questionnaires and produce nothing. Proportionality does the work: start from your Tier 1 processes, take the critical vendors behind them, and map material subcontractors for that population only. At most organizations that's fifteen or twenty vendors, and the mapping surfaces the two or three concentration points that actually matter. Record them as named dependencies in your vendor register, so the exposure is visible in the same place your vendor risk scores live.

Then treat the concentration points the way you'd treat any other risk that can't be transferred: decide. Some concentrations you accept explicitly — everyone's identity provider is one of three companies, and multi-homing identity is usually a worse trade than the risk. Some you mitigate with exit and contingency plans that are honest about switching time — a contingency plan whose first step is "negotiate a new contract" is not a contingency plan. And some you engineer around, which is expensive, which is precisely why the decision belongs in a governance forum with the authority to spend money, not in a TPRM analyst's tracking sheet.

Exercise the Chain

The last discipline is the one that makes the others real: put the fourth-party failure in your exercise rotation. "Your vendor's subcontractor is down; the vendor's status page is green; support is telling you nothing is wrong" is one of the most productive tabletop scenarios I know, because it attacks the assumption every escalation plan quietly makes — that the failing party knows it's failing and will tell you. The exercise finds the holes: no contractual right to incident information beyond your direct vendor, no monitoring that detects degradation before the vendor admits it, no decision framework for invoking contingency when the vendor keeps promising recovery in "another hour."

The vendor behind your vendor doesn't appear in your contracts, your QBRs, or your risk register — until the day it appears in your incident channel. The programs that handle that day well are the ones that met the second list before the incident introduced it. Map the chain behind what's critical, name the concentrations, decide about them out loud, and rehearse the failure. That's the whole discipline, and it's a quarter's work for the population that matters.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.