Third-Party Concentration Monitor
Finds where many services fail through the same provider, technology, region or fourth party.
Aggregates exposure by legal entity, parent, cloud region, technology, process and important business service; models correlated failure rather than summing contract values; and alerts when migration, acquisition or subcontractor change moves the institution beyond appetite.
Authority
Monitor and intervene
Team role
Monitors and escalates
Handoffs
Named collaborators
The role
What it owns and where its authority ends
Desk
Concentration, Exit Strategy & Substitutability
Desk workflow
Dependency aggregation, then concentration analysis, then exit-strategy design, then evidence and rehearsal, then an independent exit-readiness decision.
Collaboration
Works within a defined desk workflow
Decision boundary
Monitors continuously and intervenes only within stated limits.
Systems and capabilities involved
Third- and fourth-party graph
Contract and spend data
Scenario simulation
Risk appetite registry
Handoffs
What this role gives and receives
Capabilities offered
Analyze third-party concentration
Measure shared dependencies and correlated service impact against appetite.
- Receives:
- Dependency graph, contracts, service tolerances and scenario assumptions
- Returns:
- Concentration measures, shocked impact, breaches and contributing dependencies
Handoff to
Handoff to
Receives from
Receives from
External handoff
Enterprise risk
External handoff
Architecture
External handoff
Sourcing committee
Context
What the role needs to do the work
- Current work
- Current dependency graph, exposure measures, scenario shocks and appetite breaches.
- Prior interactions
- Prior concentrations, accepted exceptions, migrations and incidents.
- Policies and reference
- Service impact tolerances, provider hierarchies and concentration dimensions.
- Working method
- Aggregation, correlated-failure and escalation rules.
Illustrative workflow
How the work moves
Starting point
A new payments vendor shares a cloud region with two existing critical providers.
- 01
Resolve direct, parent and fourth-party dependencies across affected services.
- 02
Simulate regional outage against impact tolerances and exit timelines.
- 03
Open an appetite breach and route exit-plan enhancement.
Result
A correlated concentration breach affecting three important services and one common region.
Checks and boundaries
What must be tested or reviewed
- 01Finds one cloud region beneath providers recorded under different parent names.
- 02Does not infer resilience from vendor count when every vendor depends on the same identity service.
- 03Explains a concentration change caused by acquisition without double-counting pre-merger entities.
Human authority
- Risk committee accepts concentration above appetite
- Architecture approves strategic mitigation
Keep exploring