Resource - Guide
Vendor Dependency Mapping Guide
Why third-party risk starts with dependencies
Most third-party risk programmes begin with questionnaires. A dependency-first approach begins with the business: which services matter, and which vendors they rely on. That context makes every later decision more proportionate.
Not every vendor deserves the same effort
Treating every vendor equally spreads assurance thin. Knowing which vendors support critical services lets teams focus assessments, monitoring and contract terms where disruption would hurt most.
Registers list vendors, not impact
A vendor register tells you who you pay. It rarely tells you which services stop if a vendor fails. Mapping adds the missing link between the vendor record and the business.
Incidents need fast answers
When a vendor reports a breach or outage, the first question is what it affects. A current dependency map turns that question from an investigation into a lookup.
The approach
Eight steps to map vendor dependencies
Start narrow with the services you cannot lose, then expand. The aim is a map that answers impact questions, not an exhaustive inventory.
1. Identify your critical business services
List the services the organisation cannot tolerate losing, such as customer onboarding, payments or claims processing. Agree the list with business owners, not only IT, so it reflects real operational priorities.
2. Break each service into what it needs
For each critical service, record the processes, systems, data and locations it relies on. Keep it to the level of detail you would need to answer: what stops if this is unavailable?
3. Link vendors to those components
Connect each system, process or data flow to the vendors that provide, host or support it. Note whether the vendor delivers the component directly or supports it in the background.
4. Trace the vendors behind your vendors
For vendors supporting critical services, capture the material subcontractors, hosting providers and sub-processors they disclose. This is where shared dependencies and fourth-party risk become visible.
5. Classify vendors by business impact
Use the map to rank vendors by the criticality of the services that depend on them. That ranking, rather than spend or contract size, should decide assessment depth and review frequency.
6. Look for concentration
Check where several services rely on the same vendor or the same underlying provider. These shared points of failure are often invisible in a vendor-by-vendor view.
7. Prioritise assessments and controls
Direct risk assessments, contract requirements and continuity planning at the vendors and concentrations with the highest business impact. Record findings against the same map so risk stays tied to the service it threatens.
8. Keep the map current
Update the map on onboarding, exit, system change and vendor incidents. Connect incidents, risks and performance issues to mapped dependencies so the picture stays useful between formal reviews.
See how exposed you are today
Our Vendor Dependency Exposure assessment gives you a quick read on how well you can currently evidence the dependencies behind your critical services.
Illustrative worked example
Map a claims-processing dependency
This fictional example demonstrates the approach, not a customer implementation or a claim about any real vendor. Assume a claims team uses a hosted application. The starting question is: what would be affected if that application became unavailable?
1. Business service
Claims processing
Receive, review and settle a claim.
2. System
Claims application
Stores claim records and supports review.
3. Direct vendor
Vendor A
Provides the hosted claims application.
4. Fourth party
Hosting Provider B
Hosts Vendor A’s application, subject to verification.
Trace impact before deciding what to do
In this scenario, an application outage could delay claim review. Do not assume every outage stops settlement: check whether payment processing has separate dependencies and whether an agreed manual process can continue. Record those distinctions with the service owner.
If a second vendor also uses Hosting Provider B, record a potential shared dependency. Confirm the services, regions and recovery arrangements before treating it as a shared point of failure. Then decide which vendor needs deeper assessment or continuity review, and assign an owner to any unresolved gap.
Evidence prompts for each connection
- Does the service really depend on this system?
- Ask the claims service owner to confirm the process and system link. Compare the process map with the application inventory. Record the owner, source and date checked.
- What does the direct vendor actually deliver?
- Check the signed agreement, service schedule and architecture documentation. Record the service scope, data involved and who owns the vendor relationship.
- Is the fourth-party link confirmed?
- Request the vendor’s relevant hosting or subcontractor disclosure and clarify which service and region it covers. A public sub-processor list or technical observation is a lead, not proof that this application uses that provider. Mark unresolved links as unverified.
- Would a shared outage affect another service?
- Compare confirmed provider and region details across your other vendor chains. Ask service owners to check outage impact, recovery dependencies and any tested alternatives. Keep the supporting records and unresolved questions with the map.
For each relationship, retain the evidence reference, verification status, responsible owner and review date. Keep unknowns visible; a diagram alone does not verify a dependency or establish compliance.
The foundational principle
Start with Where.
Assessments tell you how a vendor manages risk. Only a dependency map tells you what that risk means for your business.
Start with where. Map the dependency first, and the rest of third-party risk management falls into order.
What a dependency map achieves
The goal is a shared, current view of which vendors your critical services rely on, so effort, controls and response go where the impact is.
Frequently asked
What is vendor dependency mapping?
Vendor dependency mapping is the practice of recording which business services, processes and systems rely on which vendors, and how those vendors in turn rely on others. The result is a connected view that shows what would be affected if a vendor became unavailable or was compromised.
How is dependency mapping different from a vendor risk assessment?
An assessment asks how well a vendor manages its own controls. A dependency map asks what your organisation relies on that vendor for. Mapping comes first because it tells you which vendors matter most, so assessments can be prioritised by business impact instead of sent to everyone equally.
Where should we start?
Start with a short list of the business services you cannot tolerate losing. For each one, record the processes, systems and data it needs, then the vendors that provide or support them. Expand outward only once those critical services are mapped.
How often should a dependency map be updated?
Treat it as a living record. Update it when vendors are onboarded or exited, when services or systems change, and when a vendor incident or contract change affects a mapped dependency, rather than waiting for an annual review.
Put this guidance to work
We run third-party risk for you, so your policy, due diligence and monitoring hold up when it matters.