Article
Map a bank's critical operation to its supplier dependencies
Build a practical CPS 230 dependency map from a banking operation to processes, resources and providers, then use it to identify recovery gaps.
Contrata editorial team ·
A bank's supplier list might identify its core platform, payments service and telecommunications provider. It does not necessarily show what happens when one of those services stops, or which internal tasks must restart before customers can use the operation again.
A dependency map closes that gap by connecting the operation to the work, resources and external services needed to deliver it. Its value lies in the questions it reveals: an untested recovery sequence, a shared dependency or an alternative process that needs the same unavailable system.
This guide develops a fictional payments example. It is a practical mapping method for a lean risk team, not a prescribed diagram or a complete banking architecture.
Begin with the operation and its boundary
CPS 230 requires documented processes, resources and interdependencies for critical operations. It also requires tolerance levels covering disruption time, data loss and minimum alternative service levels.
Start with your bank's approved operation definition and tolerances. Do not invent new tolerances inside a supplier review. If the existing definition is too broad to map usefully, raise the ambiguity with the operation owner.
For the fictional Riverbank Mutual, the workshop focuses on a defined customer payment journey: receiving an instruction, validating it, processing it, communicating the outcome and reconciling the result. Other payment activities remain outside this particular map and are recorded as exclusions, rather than assumed to be covered.
Write down what counts as delivery. Does a system being available mean the customer instruction has been completed? What if the payment moved but the bank cannot confirm the result? The answers determine which supporting steps belong in the map.
Map the process before the supplier
Ask the operation owner and the people who perform the work to describe the normal sequence. Include exception handling and reconciliation, not just the successful automated path.
Riverbank's first workshop produces five process steps:
- Receive the customer instruction.
- Authenticate and validate the request.
- Send the instruction through the processing route.
- Establish and communicate its status.
- Reconcile records and investigate exceptions.
These are illustrative steps, not a claim about every bank's payments architecture. Their purpose is to expose dependencies at a level the team can verify.
For each step, ask what it needs to start and what it produces for the next step. Where two people give different answers, record the disagreement as a question. Do not hide it by drawing a single confident arrow.
Add resources, then providers
A supplier name is rarely the complete resource description. “Technology provider” does not identify the application, data, connectivity or access method the operation needs.
Use a working table before trying to make the diagram attractive:
| Process step | Resource needed | Dependency to verify | Suggested evidence |
|---|---|---|---|
| Receive instruction | Customer channel and available transaction data | Channel platform and connectivity | Service inventory and data-flow record |
| Validate request | Authentication and decision rules | Identity service and internal configuration | Access design and operations walkthrough |
| Process instruction | Processing connection and authorised staff | Processing provider and internal approval capability | Service scope and operating procedure |
| Communicate status | Reliable result information | Status feed and customer communications | Exception handling procedure |
| Reconcile | Matching records and investigation access | Data export, reconciliation tools and trained people | Reconciliation walkthrough and sample output |
Use arrangement identifiers alongside provider names. If a provider supplies several services, the map should identify which one supports the process. For the distinction, see material providers and material arrangements.
Mark the strength of each connection
A line on a diagram can look more certain than the evidence behind it. Give each important connection a status that the team understands, such as confirmed, assumed or unresolved.
“Confirmed” should have a source and a date. It might mean the operation owner checked the connection against an architecture record and a walkthrough. It does not mean that the dependency will always work or that recovery has been demonstrated.
Separate three questions:
- Do we know that this dependency exists?
- Do we understand how it behaves during disruption?
- Have we tested the recovery or alternative route we intend to use?
Riverbank knows its reconciliation process uses a provider export. It has not yet established whether the export remains available during a failure of the main processing service. The map therefore shows a confirmed normal dependency and an unresolved recovery assumption.
That distinction creates a useful question for the provider. A generic request for “your latest BCP” would be less precise.
Trace the alternative route too
A map of normal operations cannot establish whether a workaround is usable. Draw the proposed alternative as a separate path and identify everything it needs.
In the fictional example, operations proposes a manual exception queue. The workshop discovers that staff would still need access to the same identity service used by the normal platform. The alternative path therefore does not address an identity-service outage.
The team also asks how staff obtain current instruction data, how approvals are recorded, how duplicate processing is prevented and how the queue rejoins the normal process. These are design questions for Riverbank's own procedures, not generic requirements for a particular payment method.
Where the answer depends on another supplier or an internal team, link that dependency explicitly. A workaround is not independent just because it has a different name.
Use the map to choose a useful exercise
CPG 230 discusses reporting test scope, demonstrated outcomes, issues and remediation. Apply that discipline to the questions your map raises.
For Riverbank, a useful exercise could examine loss of the processing service while the customer channel remains available. The team would need to establish how new requests are handled, how uncertain transaction status is managed and how the reconciliation backlog is controlled after service returns.
The exercise plan should state which parts are simulated, which evidence is observed and which assumptions remain untested. A discussion exercise can reveal ownership gaps without demonstrating technical restoration. Record its result at that level.
A concise findings record might contain:
- The dependency or recovery assumption examined.
- The evidence observed and the service boundary covered.
- The effect on the bank's approved tolerance assessment.
- The gap, owner and next action.
- The evidence needed to close the finding.
Keep the map small enough to maintain
Start with one operation boundary and a clear question. Add detail where it changes a risk or continuity decision. Avoid copying an entire technology architecture into a risk diagram that nobody can keep current.
Give the map an owner, version and review date. Link changes in service scope, systems, delivery arrangements and recovery procedures to the relevant part of the map. Preserve the unresolved questions alongside the diagram so they survive handovers.
Extend only the consequential branches through fourth-party dependency mapping, then use the shared-cloud scenario to test dependencies that could fail together.
Before closing the workshop, ask someone who did not draw the map to trace one failed dependency through to the customer effect and proposed recovery. If they cannot follow the path, improve the labels or evidence links before adding more boxes.