Impact ratings tell you how much a process matters. Dependency mapping tells you what has to keep working for the process to run. It is the half of the BIA that produces the most surprises — and the half that, done badly, hides the gaps that the first real-world incident exposes.
This article walks through a working dependency-mapping method. The parent topic is our BIA pillar guide.
The five dependency dimensions
A complete dependency map covers five dimensions. Missing any of them produces a BIA that looks complete but breaks in real incidents.
1. Applications. The software systems the process uses — core banking, CRM, ERP, custom platforms, integration buses. The most-mapped dimension because it has the most institutional visibility (every IT team has an application inventory). Tie BIA dependencies to that inventory by name and identifier.
2. Vendors and third parties. External providers — cloud platforms, SaaS, payment processors, telcos, custodians, outsourced ops, professional services. Two layers of vendor exposure: the direct vendors (the process owner knows about) and the indirect vendors (sub-processors, vendor-of-vendor relationships). Indirect exposure is where concentration risk hides.
3. Locations. Physical sites the process depends on — data centres, branches, call centres, treasury floors, document storage. Locations are mapped less rigorously than applications but matter more during regional events (power outages, weather, geopolitical).
4. People roles. Skills and authorities the process requires. Mapped as roles, not named individuals. "Authorised signatory for cross-currency settlements above $X" is a role; "Sara" is a person. Roles persist across personnel changes; named-individual maps go stale within months.
5. Data feeds. Inbound and outbound dataflows. Reference-data feeds (FX rates, security prices, KYC lists). Transactional feeds (clearing files, settlement messages). Outbound regulatory feeds (transaction reporting). The most-overlooked dimension because data feeds are often invisible until they stop.
Some methodologies add a sixth dimension — infrastructure (networks, identity, security services). We treat infrastructure as a horizontal that crosses applications and locations rather than a separate dimension, but the modelling choice is yours.
The workshop method
Dependency mapping is workshop work, not desk research. The process owner alone cannot produce a complete map; they need the cross-functional perspective. A working workshop format:
Attendees. Process owner (lead). BCM facilitator. Representatives from IT operations (applications and infrastructure), vendor management, facilities, and any specialist function the process touches (treasury, compliance, etc.).
Time. 90 minutes per process for the initial workshop. Allow another 60 minutes for follow-up validation after the workshop.
Inputs. Pre-circulated process description. Pre-fetched application inventory and vendor register filtered to the process owner's department.
Output. A populated dependency map covering all five dimensions, with each dependency tagged for criticality.
The workshop script
Opening (10 min). BCM facilitator opens with the BIA context: this workshop produces the dependency map for [process]. Walk through the five dimensions briefly.
Dimension by dimension (60 min). Cover each dimension in turn. The process owner narrates; the facilitator captures structured records.
For applications: "What applications does this process use at each step? Which are critical-path (process stops if it's down) vs. peripheral (process continues degraded)?"
For vendors: "Which external providers does the process depend on? For each, what specifically do they provide? What is the contractual SLA?"
For locations: "What physical sites must be operational? Just the primary, or are there branches, call centres, treasury floors required?"
For roles: "What roles must be available to operate the process? What authority levels are required? Where are the deputies?"
For data feeds: "What inbound feeds does the process consume? What outbound feeds does it produce? What is the cadence?"
Cross-checks (15 min). Compare the workshop output to the application inventory and vendor register. Spot the missing items in both directions: dependencies the workshop missed vs. items in the inventory that the process owner didn't mention.
Criticality tagging (5 min). For each dependency, tag as critical-path (process fails without it), degraded-but-operational (process can run reduced without it), or peripheral (process unaffected by short-term loss).
Common dependency-mapping gaps
In our experience, three categories of dependency are missed most often:
Identity and access infrastructure. Authentication services, privileged-access management, SSO providers. Treated as ambient infrastructure, not called out. When they fail, every dependent application is unavailable simultaneously.
Indirect vendor dependencies. The process uses Vendor A. Vendor A uses Vendor B for storage. Vendor B has a regional outage. The process is down, but Vendor B does not appear anywhere in the BIA. Sub-processor mapping is hard but important — at minimum, identify the sub-processors for critical primary vendors.
Cross-process dependencies. Process A depends on Process B (an upstream process that produces a feed Process A consumes). Internal cross-process dependencies are often invisible because both processes are "ours." Capture them explicitly.
Keeping the map current
A dependency map captured once and never refreshed is the most common BIA failure mode. The maintenance pattern:
- Annual full refresh alongside the BIA refresh cycle.
- Change-triggered review whenever a new application is onboarded, a vendor is replaced, a location is added or closed, or a major process change ships.
- Post-incident review after every real-world activation. Did the incident expose a dependency the map missed?
The trigger needs to live inside the change-management process — without a hook there, dependency maps drift quickly.
The dependency map as exercise input
The dependency map is the second BIA output that feeds the exercise programme (the first is the recovery-objectives chain). Scenario design draws directly from the map: "primary data centre unavailable" tests the location dimension; "Vendor X major outage" tests the vendor dimension; "core banking unavailable" tests the application dimension. Exercises that don't trace back to documented dependencies tend to test the wrong things.
For exercise-programme design, see the crisis management playbook. For the underlying BIA methodology, return to the BIA pillar guide.
The platform surface
Dependency mapping at scale becomes intractable in spreadsheets — the cross-references between BIAs, application inventories, vendor registers and risk assessments multiply quickly. A structured platform models the relationships explicitly, so a change to a vendor's status flags every BIA that depends on it. The BCMStack BIA module is built around this dependency model.
The work is unglamorous. The payoff is in the incidents the dependency map prevents from becoming surprises.