Dependency mapping in a BIA identifies what a critical activity must receive, use or rely on to operate at each recovery stage. A useful map is not a catalogue of every supplier and system; it shows the dependencies whose failure can prevent the required level of service from being achieved within the required time.
Map from the activity outward
Start with a defined business activity and its minimum required output. Ask what must be available to deliver that output at the recovery target and during degraded operation. Capture people and skills, facilities, technology, information, utilities, third parties, upstream processes and downstream recipients. This keeps the analysis tied to continuity rather than producing an enterprise inventory with no recovery meaning.
- Name the dependency and the capability it provides.
- Record when it is needed, not merely that it exists.
- Identify the owner and source of evidence.
Distinguish dependency types
An upstream dependency supplies something the activity needs; a downstream dependency relies on the activity output. Shared dependencies support several activities and can create concentration risk. Reciprocal dependencies can create loops in which two teams each assume the other recovers first. External dependencies require evidence about supplier commitments and alternatives rather than internal assumptions.
- Flag shared identity, network, facilities and data platforms.
- Identify single points of failure and geographic concentration.
- Record manual or alternate modes where they genuinely exist.
Add time and minimum capacity
A dependency is meaningful only in relation to time and capacity. A system may be unnecessary during the first two hours because a manual queue is available, but essential before the queue exceeds safe capacity. A supplier may be available within 24 hours while the business needs replacement stock in eight. Record the latest acceptable availability time and the minimum capacity needed at each recovery stage.
- Separate normal capacity from minimum continuity capacity.
- State maximum tolerable workaround duration.
- Capture lead time for people, access, equipment and suppliers.
Validate cross-functional assumptions
Dependency records often conflict. The business may assume an application recovers in four hours while technology classifies it for next-day recovery; procurement may know a supplier has no contractual recovery commitment; facilities may know the alternate site cannot support the stated headcount. Reconcile these differences explicitly and assign unresolved gaps to owners.
- Compare business RTO needs with technology recovery commitments.
- Confirm supplier and facility capacity with the responsible owner.
- Do not treat a planned improvement as current capability.
Worked example
A claims activity requires six trained staff, identity access, the claims platform, a document repository and an external payment service. For the first four hours, staff can record urgent claims offline, so the document repository is not immediately critical. By eight hours, identity and the claims platform must be available to prevent an unsafe backlog. The payment service is required by 24 hours. The map therefore creates a recovery sequence rather than five identical “critical” dependencies.
Turn the map into action
Use the dependency map to test recovery strategies, identify conflicting targets, prioritize supplier assurance and design exercises. For highly shared dependencies, aggregate demand across activities: ten teams each requiring five people at an alternate site is a fifty-seat requirement, not ten independent five-seat assumptions.
- Escalate target/capability mismatches.
- Test shared dependencies under concurrent demand.
- Link material gaps to funded treatment or explicit risk acceptance.
Acceptance test
A reviewer should be able to select a critical activity and determine what must be restored first, by when, at what minimum capacity, who owns each dependency, what evidence supports the assumption and what happens if the dependency is unavailable. If the map cannot answer those questions, it is still an inventory rather than a continuity dependency model.
Capture dependency evidence at the right level
A useful dependency record identifies the service or capability actually consumed. “IT” is too broad; “corporate identity service for privileged and standard user authentication” is actionable. “Supplier” is too broad; identify the contracted service, location or product, normal lead time, continuity commitment and available substitute. For people, distinguish headcount from scarce competence, authorization or delegated authority.
Do not assume that a resilient component makes the end-to-end service resilient. A cloud application may be highly available while identity, network connectivity, data feeds or a specialist support team remain single points of failure. Follow the dependency chain far enough to expose material shared services, but stop where additional detail no longer changes a recovery decision.
Visualizing and aggregating dependencies
For complex portfolios, maintain a structured dependency register that can be aggregated by service, supplier, site or technology. This allows BCM teams to discover that many individually acceptable BIAs rely on the same data centre, telecom carrier, specialist team or logistics provider. A visual map can help workshops, but the underlying data should remain searchable and owned; a diagram alone becomes stale quickly.
Direction matters. Mark whether the activity consumes the dependency, provides an output to another activity, or both. Also distinguish hard dependencies from soft dependencies. A hard dependency prevents minimum service; a soft dependency reduces efficiency but can be bypassed temporarily. This distinction is valuable during constrained recovery.
Testing the dependency model
Exercises should remove a shared dependency and require teams to operate with the documented alternatives. Measure how long workarounds remain safe, whether access is available, whether alternate suppliers can meet volume, and whether concurrent demand exceeds planned capacity. Update the BIA when the test disproves an assumption.
- Check that dependency owners recognize the commitments attributed to them.
- Check that recovery times align in both the consumer and provider records.
- Check that alternate arrangements have access, data, equipment and authority—not just a name.
- Check that shared capacity has been aggregated across simultaneous users.
Related BCM.Center resources: Critical Activity Prioritization · How to Identify Critical Activities for Business Continuity.