Dependency Concentration Risk Analyzer

Use this tool when a business service appears diversified on paper but several recovery paths still depend on the same provider, site, network, specialist, data source or utility. Concentration is often hidden because dependencies are documented in different plans and owned by different teams.

What this tool is designed to decide

Inventory the dependency behind each recovery path, not just the supplier or system name. Look for shared carrier routes, cloud regions, identity providers, data feeds, facilities, specialist teams and upstream subcontractors that make apparently separate options fail together.

The result should direct investigation, not declare a dependency safe. A low visible concentration score is unreliable when dependency data is incomplete, while one confirmed shared dependency can justify immediate treatment even if the overall score looks moderate.

How to interpret the result

This is a risk index, so a higher score is worse. The average reflects broad concentration across the service while the maximum dimension prevents one severe single point of failure from disappearing inside a low average. A score above 75 should normally trigger explicit treatment or acceptance because multiple continuity arrangements may fail together during one event.

Retain the dependency map, ownership, evidence source, recovery requirement, known shared components and accepted residual concentration. For third parties, record what has been evidenced versus what is only stated by the provider.

Recommended corrective actions

• Map common upstream dependencies behind apparently different suppliers or systems.
• Design at least one recovery path that does not share the dominant failure domain.
• Confirm whether alternate sites share power, telecom, transport or regional hazards.
• Separate privileged credentials and recovery documentation from a single repository.
• Test simultaneous loss of the highest-concentration dependency and the normal fallback.

Test one dependency failure across multiple services at the same time. The useful question is not whether each service has an alternate, but whether those alternates remain available when the common dependency is removed.

Governance and assurance

• Dependency owners should validate the failure domain, not just the component name.
• Procurement should assess common parent companies and subcontractors where supplier diversification is claimed.
• Technology architecture should validate shared network, identity, cloud-region and platform dependencies.

Enter dependencies at the level needed to expose common cause. The calculation stays in the browser; validate important conclusions with architecture, supplier and operational owners before using them in risk acceptance or investment decisions.

Common mistakes to avoid

Do not count two contractual suppliers as independent when both rely on one facility, network, cloud platform or specialist subcontractor. Commercial diversity is not the same as technical or operational independence.

Corrective actions can include independent routing, alternate credentials, second-source data, geographic separation, contractual transparency, manual fallback or explicit prioritization when shared capacity is constrained.

Evidence to retain

Use the tool alongside BIA and service mapping so concentration is evaluated against business consequence. A shared dependency supporting several low-criticality services may be acceptable; the same pattern across time-critical services may require urgent treatment.

Worked concentration example

Consider a critical service with two network providers, two SaaS applications and two outsourced support vendors. On paper, the service appears diversified. Mapping the underlying dependencies shows that both network providers use the same building entry, both SaaS applications depend on the same identity provider, and both support vendors rely on one specialist subcontractor. The analyzer should make those common-cause relationships visible. Management can then distinguish cosmetic diversification from true resilience and decide whether independent routing, alternate identity access, a second subcontractor or explicit service prioritization is justified.

Concentration evidence to retain

• Service-to-dependency map with ownership.
• Known upstream providers and shared infrastructure.
• Evidence supporting claimed geographic or technical separation.
• Recovery targets and capacity commitments for each dependency.
• Scenario results showing impact when the shared dependency is removed.
• Accepted residual concentration with accountable owner and review date.

Related BCM.Center knowledge

• Dependency Mapping for Business Continuity
• Supplier Business Continuity Questionnaire
• Third-Party Business Continuity Management

High availability can coexist with severe concentration risk. The issue is the size of the correlated failure when the common dependency is lost, so scenario testing should focus on common-cause disruption rather than average uptime.

Look for common-mode failure

The most important concentration risks are often invisible in a basic dependency list. Two applications may run on different servers but share the same identity provider, storage platform, cloud region, network path or database cluster. Two suppliers may be separate legal entities but rely on the same subcontractor, port, telecom carrier or logistics route. Two offices may be in different buildings yet depend on the same electrical substation or transport corridor. During review, ask what single event could disable multiple supposedly independent recovery options at the same time. Document the common-mode dependency explicitly and test at least one scenario in which the primary service and its normal fallback are both unavailable. This exposes whether the organization has true diversification or only duplicated components inside the same failure domain.