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
This interactive BCM.Center tool is intended to support structured professional judgement, not replace it. The result should be used as a documented discussion aid during business impact analysis, recovery strategy design, continuity planning, exercise preparation, incident governance or assurance. The strongest use of the tool is to make assumptions visible, create a repeatable scoring conversation, and expose where evidence is weak or conflicting.
Use current, organization-specific inputs wherever possible. Avoid treating a single numeric result as an approval decision. A mature continuity program should retain the underlying evidence, record who supplied the inputs, identify the review date, and document any management override. Where an input is uncertain, use the more conservative value and record the uncertainty for follow-up.
Interactive assessment
Enter the current values, then calculate. All processing happens in your browser; this tool does not save the values to BCM.Center.
100 means the service relies heavily on one supplier or common upstream provider.
100 means critical applications share major common infrastructure or identity/network dependencies.
100 means alternate arrangements depend on the same location, region or utility.
100 means critical capability is held by very few people.
100 means critical data or credentials have a single effective source.
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.
The numerical output is only useful when the scoring basis is consistent. Re-run the assessment when assumptions, suppliers, staffing, technology, incident conditions, regulatory expectations or recovery dependencies change. If two business owners produce materially different scores for the same scenario, treat the disagreement as a governance issue that needs evidence and facilitation rather than averaging the numbers without discussion.
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.
Corrective actions should be owned, dated and traceable. High-priority actions should connect to the continuity improvement backlog, risk register, exercise program or recovery strategy decision record. Closure should require evidence, not only a status change. Examples of evidence include approved procedures, tested alternate arrangements, supplier commitments, technical recovery results, call-tree tests, staffing rosters and exercise observations.
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.
Review the assessment at least when the related process, service, dependency or recovery strategy changes. For critical services, consider independent challenge by the BCM function, risk function, technology recovery lead, supplier manager, facilities lead or crisis management team as appropriate. The review should confirm that the inputs remain current and that the resulting treatment is proportionate to the operational consequence.
Common mistakes to avoid
Do not use the tool as a substitute for a BIA, risk assessment, recovery plan or exercise. Do not inflate scores to justify a preferred investment and do not suppress scores to avoid remediation. Avoid combining unrelated services into one assessment because different dependencies and recovery objectives can disappear inside an average. Do not assume that a documented workaround is effective until it has been demonstrated under realistic conditions.
Another common mistake is to confuse availability with recoverability. A supplier, application or facility may be available most of the time but still have weak recovery capability after a severe disruption. Likewise, a plan may exist but depend on unavailable people, inaccessible credentials, untested data restoration or a single communication channel. The assessment should focus on the ability to sustain or recover the required business outcome.
Evidence to retain
Retain the completed assessment, input source, decision owner, review date, supporting evidence and resulting actions. Where the score is used to support funding or acceptance of residual risk, retain the approval and rationale. During an audit or post-incident review, this evidence is more valuable than the score itself because it demonstrates that the organization understood the assumptions and made a deliberate decision.
Related BCM.Center knowledge
- Dependency Mapping for Business Continuity
- Supplier Business Continuity Questionnaire
- Third-Party Business Continuity Management
BCM.Center tools are educational practitioner aids. Adapt thresholds, scoring scales and decision rights to your organization's risk appetite, regulatory obligations, sector, operating model and approved business continuity management system.
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.