Dependency Mapping

Dependency mapping for operational resilience and continuity

Dependency mapping is the practice of identifying every people, process, technology, data, third party, and premises dependency an important business service relies on, and recording the relationships between them. This page shows the canonical mapping flow as a BPMN 2.0 process - the artefact regulators (PRA and FCA, APRA, OSFI, EU DORA) expect when they ask "show me how this service stays up".

By Jack Finnegan · Updated 21 May 2026

Map a service dependency map Operational resilience hub

What it is

What dependency mapping actually is

Dependency mapping is the discipline of recording every resource an important business service relies on. The canonical resource categories - people, processes, technology, facilities (premises), and information (data) - come straight from the UK mapping requirement under PRA SS1/21 and FCA PS21/3, with the Basel Committee's 2021 Principles for Operational Resilience as the regulator-neutral source. Third-party providers (and their fourth parties) cut across every category and are typically tracked as a separate axis. The output is a structured map, not a paragraph: every dependency is named, every relationship between dependencies is captured, and every single point of failure surfaces visibly.

Dependency mapping is the diagrammatic core of operational resilience. Without it, impact tolerances float (you cannot reason about the maximum tolerable disruption of a service when you do not know what disrupts it), scenario testing is theatre (you cannot test severe-but-plausible disruptions to a system you have not mapped), and third-party risk management is incomplete (you cannot manage concentration risk in vendors you do not know you have).

The problem today

Dependency maps that exist only in former employees

The most common failure mode is the mental model: the senior architect who knows how everything connects, has never written it down, and leaves the firm in a senior departure round. The second most common is the Visio file from 2019: technically a dependency map, practically a museum piece, with vendor logos for companies that have been acquired and system names for tools that have been deprecated. The third is the unstructured page in the team wiki: prose paragraphs describing dependencies, no diagram, no relationships, no way to query "which services depend on Vendor X?" when Vendor X has an outage.

The fix is the same in every case: produce a structured, BPMN-style dependency map per important business service, validate it with the service owner, refresh it on a known cadence, and treat it as a working artefact instead of a one-off compliance deliverable.

Five categories

The five dependency categories every regulator expects

People

Roles, teams, headcount, key knowledge holders. The "single architect who knows everything" is a people-dependency concentration risk every regulator now asks about.

Processes and technology

Internal processes (the BPMN map for the service itself), applications, infrastructure, integration points. The technology layer is where most teams over-document.

Data

The data stores and flows the service reads from and writes to. Often missed because data flows are not visible on the application architecture diagram.

Premises

Data centres, offices, contact-centre sites, and the physical locations a service depends on. Often a single point of failure that registers everywhere except the dependency map.

Third parties

Material service providers (and their fourth parties), cloud regions, payment networks, market-data vendors. The third-party slice is where the regulator’s scrutiny is heaviest under DORA, CPS 230, and OSFI E-21.

Process Map

Dependency mapping as a process map

The end-to-end mapping flow - scope a service, identify dependencies in the five categories, map relationships, surface single points of failure, validate, register.

Open in editor

Dependency mapping for an important business service

Dependency mapping rendered as a BPMN 2.0 process. The flow scopes the important business service, identifies the five dependency categories (people, processes and technology, data, third parties, premises), validates with the service owner, surfaces single points of failure, and registers the map for ongoing maintenance.

Confirm scope - which important business service or critical operation is being mapped.
Identify people: roles, teams, headcount, key knowledge holders.
Identify processes, technology, data, third parties, and premises that support the service.
Map relationships between the dependencies - which task depends on which system, which system on which vendor.
Surface single points of failure and concentration risks.
Validate the map with the service owner and second-line risk.
Register the dependency map and schedule the next refresh.

What this diagram shows: The process starts when an important business service is scoped for mapping. The three identification tasks (people; processes/tech/data; third parties/premises) run in sequence here for diagram clarity, though in practice they often happen in parallel workshops. The Map Relationships task connects the inventory together; Surface Single Points of Failure makes the brittle bits visible. Validation with the service owner can loop back to relationship mapping if revisions are needed; once approved, the map is registered and a refresh schedule is set.

FAQ

Frequently asked questions

What is dependency mapping?

Dependency mapping is the practice of identifying every external resource an important business service relies on - people, processes, technology, data, third parties, premises - and recording the relationships between them. The output is a structured map (not a paragraph) that lets a firm reason about single points of failure, concentration risk, and impact tolerance breaches when a dependency is degraded or lost.

Which regulations require dependency mapping?

Most modern operational-resilience regimes require dependency mapping explicitly or implicitly. The UK regime (PRA SS1/21 and FCA PS21/3, with FCA rules codified in SYSC 15A) requires firms to identify the resources their important business services rely on. APRA CPS 230 requires the same for critical operations. OSFI Guideline E-21 (Canada) follows the same pattern. The EU Digital Operational Resilience Act (DORA) requires ICT third-party dependency mapping with mandatory registers. The Basel Committee's 2021 Principles for Operational Resilience is the regulator-neutral source the national regimes trace back to.

How often should dependency maps be refreshed?

The minimum is annually (most regulators require an annual operational-resilience self-assessment that the dependency maps feed into). In practice the cadence should match the rate of change in the underlying service - quarterly for actively-changing services, annually for stable ones, immediately on any material change (a new third party, a major system release, an organisational restructure). The discipline of treating the dependency map as a living artefact, not a one-off, is more important than the specific refresh cadence.

What is the difference between a dependency map and an architecture diagram?

An architecture diagram shows how systems are connected from a technology perspective - applications, services, databases, network paths. A dependency map is broader: it includes the non-technical dependencies (people, processes, third parties, premises) and is structured to support resilience reasoning (single points of failure, concentration risk, impact tolerance) rather than purely engineering reasoning. Architecture diagrams are an input to dependency mapping, not a substitute for it.

How does dependency mapping fit into operational resilience?

Dependency mapping is the diagrammatic core. Without it the rest of the operational-resilience programme floats: impact tolerances cannot be reasoned about for a service you have not mapped, scenario tests cannot exercise severe-but-plausible disruptions to systems you have not identified, and third-party concentration risk cannot be measured across services that do not share a vendor inventory. The dependency map is what makes the abstract programme concrete.

Does BA Copilot replace our existing CMDB or third-party register?

No. A CMDB (configuration management database) is the source of truth for IT assets and their relationships. A third-party register is the procurement-led source of truth for contracts and vendors. BA Copilot is the modelling layer that produces the visual dependency map per important business service - the artefact that ties the CMDB, the third-party register, and the business process together into a single picture the service owner and the regulator can both read.

Jack Finnegan, Founder & CEO, BA Copilot

From the founder

14 Years in BPMN

I'm Jack Finnegan. I've spent fourteen years working hands-on with BPMN, as an analyst, an engineer, and a product director, where I felt every sharp edge of legacy business process platforms.

BA Copilot is the platform I wanted on every one of these projects: AI-first process management, which treats BPMN as a first-class output rather than an export afterthought.

Jack Finnegan on LinkedIn

Sources

Sources and verification

Last verified 21 May 2026 by Jack Finnegan.

References cited on this page:

PRA SS1/21 and FCA PS21/3
Basel Committee Principles for Operational Resilience (2021)
EU DORA

Make dependency mapping a living artefact

Open the dependency-mapping template, rename categories to match your taxonomy, and capture the dependencies for one important business service in a single working session.