Context: Questions We Keep Hearing
Compliance officers, risk managers, and GRC leads with mature third-party risk programs often face unexpected challenges. You've got vendor inventories, due diligence questionnaires, integrated risk assessments, and dashboards that consolidate views across security, compliance, finance, and continuity. Your board sees quarterly reports showing vendor risk ratings. Everything looks controlled.
Then a supplier goes down for eight hours, and you discover that four supposedly independent providers all route through the same data center. Or a financially stable vendor fails, and you realize you can't deliver a critical service because no alternative exists. The questions below reflect that gap between what traditional third-party risk management tells you and what you actually need to know.
Q1: We've integrated our vendor assessments across security, compliance, and continuity. Isn't that enough?
It's necessary, but not sufficient. Integration solves the problem of fragmented visibility, where procurement sees one thing, security sees another, and compliance sees a third. You've eliminated the risk of conflicting assessments flying beneath different radars.
But here's what integration doesn't tell you: what happens to your organization when the vendor fails. You might know everything about the vendor's control environment, financial stability, and recovery capabilities. You still don't know which of your processes stop working, how quickly disruption propagates, or whether your supposedly redundant suppliers share the same underlying infrastructure.
The integrated assessment tells you about the supplier. It doesn't tell you about your dependency architecture. Those are different questions.
Q2: What's the difference between assessing a vendor and understanding our dependency on them?
A vendor assessment examines the external entity: their security controls, certifications, financial condition, continuity plans, regulatory compliance, and operational practices. It's an evaluation of the supplier's characteristics.
A dependency assessment examines the relationship: which applications use that vendor's service, which business processes rely on those applications, which customers depend on those processes, how long each service can remain disrupted before impact becomes intolerable, and whether alternatives actually exist in operational terms.
Consider a cloud provider. You can complete an exhaustive assessment showing low risk across every dimension. Now ask: what happens if they're unavailable for six hours? The vendor assessment can't answer that. The answer lives in your service architecture, process maps, data flows, and recovery assumptions. A vendor with excellent controls can still represent catastrophic dependency risk if they sit at a structural chokepoint in your operations.
Q3: So we need better dependency mapping?
You need dynamic dependency intelligence, not static maps. Traditional dependency mapping typically produces diagrams showing which suppliers support which processes. That's useful for initial visibility, but it doesn't capture interactions, cascades, or hidden concentrations.
What you're really building toward is something closer to a digital twin of your extended enterprise: a model that represents how services, processes, technologies, suppliers, fourth parties, data, and infrastructure interact with one another. Once that model exists, you can simulate scenarios. What fails if this supplier becomes unavailable? What else fails because of it? Which supposedly independent suppliers share the same underlying dependency? What combination of events pushes you beyond tolerance?
This isn't theoretical. Organizations have developed vendor inventories, due diligence processes, and increasingly sophisticated sources of external intelligence over the past two decades. The next evolution is understanding the web of dependencies through which those vendors become important to you.
Q4: Doesn't business continuity already cover this with impact assessments?
Business continuity identifies critical processes and assesses recovery time objectives, but it typically treats each process in isolation. It asks: "Can we recover this process if it fails?" It doesn't always ask: "What combination of supplier failures creates systemic exposure across multiple processes simultaneously?"
You might have three suppliers, each assessed as having adequate continuity controls. Business continuity might confirm that each process can recover within tolerance. But if all three suppliers depend on the same telecommunications provider, the same power grid, or the same fourth-party data center, you've got concentration risk that doesn't appear in individual assessments or traditional impact analyses.
The question isn't whether each supplier can recover. It's whether your organization can continue delivering important services when the supplier is unavailable, and whether supposedly redundant arrangements actually provide independence.
Q5: How do we start building this kind of visibility?
Start by connecting three things you probably track separately: service architecture, process dependencies, and supplier relationships.
Identify your important business services (the ones that, if disrupted beyond tolerance, would cause unacceptable harm to customers, counterparties, or market integrity). Map which internal processes support each service. Then trace which suppliers, technologies, data flows, and infrastructure those processes depend upon. Don't stop at the first tier; follow the chain through fourth parties and shared infrastructure.
This will surface concentrations you didn't know existed. You'll find that multiple "independent" suppliers use the same cloud region, payment processor, or logistics hub. You'll discover that a supplier you rated as low-importance actually supports a component that's irreplaceable on short notice.
The goal isn't to document everything; it's to understand structural exposure. Where are your chokepoints? Which dependencies create the greatest exposure relative to your tolerance? What should you change today to improve tomorrow's outcome?
Q6: This sounds expensive. Do we really need to model the entire extended enterprise?
You don't need to model everything. You need to model what matters: the dependencies that support services where disruption would push you beyond tolerance. That's the operational resilience lens, and it focuses your effort.
Start with services that are important to your customers, markets, or regulatory obligations. Work backward from there. You're not trying to create a perfect simulation; you're trying to answer questions that traditional vendor risk assessments can't: What happens if this fails? How quickly does impact propagate? What combination of events creates intolerable harm?
The cost of not understanding these dependencies shows up when a vendor you rated as moderate risk takes down a critical service, and you discover your recovery plan assumed independence that didn't actually exist.
Where to Go for More
The COSO ERM Framework provides guidance on identifying and assessing risks across the extended enterprise, though you'll need to adapt its principles to capture dependency interactions, not just vendor characteristics. If you're in financial services, operational resilience requirements increasingly expect you to understand these cascading dependencies and concentration risks. Look at how your important business services map to third-party dependencies, and start asking the questions your current risk register wasn't designed to answer.
