Understanding the Template's Purpose
You've probably conducted third-party risk assessments to evaluate a supplier's security controls, financial stability, or continuity plans. However, these assessments often don't reveal what happens when a supplier fails.
This template helps you map the dependencies between third parties and your organization's critical services. It answers a question traditional risk registers can't: what happens if a supplier is unavailable for eight hours?
The template creates a structured record of how services, processes, data flows, and infrastructure connect through external parties. Use it to identify hidden concentration risks, understand disruption paths, and determine which supplier relationships create structural exposure regardless of the supplier's risk rating.
Gathering Prerequisites
Before mapping dependencies, ensure you have:
Service Inventory: A current list of the business services your organization delivers to customers, members, or internal stakeholders. Focus on outcomes, not systems (e.g., "loan origination," not "the loan system").
Critical Service Designation: Identify which services must continue within defined time tolerances. If you've completed operational resilience work under regulatory requirements, you already have this.
Technology and Process Ownership: Know who owns each application, platform, and core process. You'll need them to validate dependencies.
Third-Party Inventory: Your existing supplier list from procurement, security, or GRC platforms. The template enriches this, it doesn't replace it.
Access to Technical Teams: Infrastructure, application, and platform teams can identify dependencies that procurement contracts never capture.
Building the Template
Create a spreadsheet or database with these columns:
Third Party Name | Service Supported | Dependency Type | Substitution Time | Shared Infrastructure | Tolerance Threshold | Propagation Path | Last Validated
Here's how to fill each field:
Third Party Name: The external entity providing the capability. Be specific. "AWS" is less useful than "AWS us-east-1 for transaction processing."
Service Supported: Which business service depends on this third party? Link to your service inventory. A single supplier may support multiple services; create separate rows for each.
Dependency Type: What does the third party actually provide?
- Platform/Infrastructure
- Data Processing
- Application Component
- Business Process
- Information/Intelligence
- Physical Logistics
- Telecommunications
- Payment/Settlement
- Professional Services
Substitution Time: How long would it take to move this function to an alternative provider and restore service? Measure in hours or days. If you don't know, write "unknown" and mark it for technical review.
Shared Infrastructure: What underlying dependencies does this third party rely on that you also use? Common examples: the same cloud region, telecommunications provider, payment network, port, or data center. This reveals false redundancy.
Tolerance Threshold: How long can the supported service remain disrupted before impact becomes intolerable? This comes from your operational resilience or business continuity analysis. Express it as a time window (e.g., "4 hours," "24 hours," "7 days").
Propagation Path: What else fails if this third party fails? List the cascade: "Third party → Application X → Process Y → Service Z → Customer impact." Be specific about the mechanism.
Last Validated: When did someone with technical knowledge confirm this dependency still exists as described? Dependencies drift as architecture changes.
Customizing the Template
Add Columns for Your Regulatory Context: If you operate under operational resilience frameworks, add fields for impact tolerance, recovery time objectives, or regulatory reporting thresholds. If you're subject to data localization rules, add jurisdiction and data-flow columns.
Extend to Fourth Parties: Add a "Sub-Processor" or "Fourth Party Infrastructure" column to track dependencies your third parties rely on. This matters especially for cloud providers, payment processors, and logistics networks.
Connect to Your Risk Register: Add a column linking to your existing third-party risk assessment ID. This template doesn't replace inherent risk ratings; it shows you what those ratings mean in context.
Map to Controls: Add a "Mitigating Controls" column identifying what you've implemented to reduce dependency exposure: contractual failover provisions, technical redundancy, data replication, manual workarounds, or alternative suppliers.
Track Concentration: If multiple critical services depend on the same third party, that's concentration risk. Add a summary view showing which suppliers appear most frequently in your critical service paths.
Validating Your Map
Test with a Scenario: Pick one third party from your template. Walk through what happens if they experience an eight-hour outage. Can you trace the impact through your dependency map? If not, you're missing connections.
Validate Substitution Times with Technical Teams: Procurement might believe you can switch cloud providers in a week. Infrastructure knows it takes three months and requires application re-architecture. Verify your assumptions with the people who would execute the change.
Compare to Actual Incidents: When a third party experiences disruption, compare what happened to what your dependency map predicted. If reality diverged, update your template and investigate why your model was incomplete.
Review Quarterly: Dependencies change as you adopt new services, migrate platforms, or renegotiate contracts. Treat this template as a living document, not a point-in-time snapshot.
Cross-Check with Your Resilience Testing: If you run tabletop exercises or failover tests, use this template to identify which third-party scenarios would exceed your tolerance thresholds. Those become your priority testing candidates.
The goal isn't to create the world's most sophisticated assessment of your suppliers. It's to understand what your suppliers mean to your organization. That's a different question, and it requires a different map.
