A bank can operate several customer-facing apps, payment services and risk systems while relying on the same underlying technology provider for all three. From the customer’s perspective, those are separate services. During a disruption, they may fail together. Operational resilience therefore depends on understanding the links between important banking services and the people, processes and suppliers that support them.
The Basel Committee’s principles for operational resilience ask banks to identify critical operations, map their dependencies and test their ability to remain within tolerance levels during severe but plausible disruption. This is a change in emphasis from asking whether individual systems have backup capacity to asking whether customers can still complete an important activity. A bank may recover a server while a payment journey remains unavailable because identity verification, network access or a third-party interface is still down.
Map the service from end to end
Mapping begins with an outcome a customer or market participant needs: receive salary, make a payment, access deposits or settle a transaction. The bank then traces the technology and human steps required to deliver it. This includes upstream cloud services, telecommunications, outsourced processing, authentication tools and internal data stores. A dependency map is useful only if it identifies where apparently separate paths converge.
That convergence is easy to miss. Two applications may use different software but the same identity provider. Backup infrastructure may occupy a separate building yet depend on the same network operator. An outsourced contact centre may have spare staff but no way to view the customer’s account when a core system is unavailable. A credible map records these common points and the service-level consequence of losing each one.
The Financial Stability Board’s third-party risk toolkit describes approaches to identifying, managing and overseeing service-provider risk. Its central implication for banks is practical: contractual assurances and supplier due diligence should be tied to the actual services a provider supports. The contract may permit an audit, but the bank still needs to know which failure scenario to test and what evidence would demonstrate recovery.
Test the customer outcome
A recovery exercise should start with a plausible event and measure the service. Suppose a cloud region fails while payment volume is high. Can customers log in? Can the bank accept, screen and complete payments? What happens to transactions already in flight? Can staff see which payments are pending, and can the bank explain that status clearly? Counting restored machines is less useful than measuring the time and accuracy of the customer journey.
Tests also need decision points. Who can declare an incident? When does the bank switch processing? Who approves a manual workaround, and how are errors reconciled afterward? The people responsible for customer communication, compliance and liquidity may need to act before technology teams finish diagnosis. Exercising these handoffs can reveal weaknesses that a narrow disaster-recovery test misses.
In Europe, the Digital Operational Resilience Act framework described by the EBA requires financial entities to maintain registers of information concerning ICT third-party contractual arrangements. The register supports oversight and risk assessment. It does not substitute for current service maps, realistic tests or management judgment about which dependencies could interrupt critical operations.
Concentration changes the scenario
Risk can build inside one bank and across many banks. A provider used by numerous institutions may create common exposure even if each contract appears individually acceptable. The European supervisory authorities’ DORA oversight guide describes the framework for oversight of designated critical ICT providers. Oversight of a provider adds information and discipline, but each bank remains responsible for its own service continuity and exit planning.
An exit plan is credible when it describes data portability, technical dependencies, likely migration time and temporary service arrangements. It is less credible if it simply names an alternative supplier that has never been integrated or tested. Switching providers during an acute disruption may be unrealistic for a complex core service. For some functions, graceful degradation and clear customer communication may be more achievable than immediate replacement.
Management needs usable measures
Boards cannot supervise resilience through a single uptime percentage. They need evidence of which services are critical, the tolerance set for disruption, the results of severe but plausible tests, unresolved dependencies and the time needed to restore customer outcomes. Measures should show whether repeated incidents are improving the system or merely generating the same remediation plans.
The ECB’s update to its TIBER-EU testing framework illustrates the role of advanced testing aligned with digital operational resilience requirements. Threat-led exercises are valuable when findings reach the teams that own controls, contracts and recovery decisions. Their value is limited if tests are treated as a certificate rather than a way to expose failure paths.
Define a tolerable disruption
A tolerance for disruption should be stated in terms that matter to customers and markets. For a payment service, that may include the maximum duration of unavailability, the number or value of delayed transactions and the integrity of records after recovery. Different services warrant different thresholds. A bank should explain why a chosen limit is defensible and whether its existing systems can meet it during a severe but plausible event.
A tolerance is not the same as a service-level promise from a technology vendor. The supplier may restore its platform before the bank has reconciled failed transactions or reopened the customer channel. Conversely, the bank may maintain a limited but useful service through a workaround while the provider remains impaired. Metrics should capture these differences and give incident leaders a clear trigger for escalation.
Follow subcontractors and data
A bank’s direct provider may rely on other companies for hosting, security software or telecommunications. Subcontracting can create a chain whose weakest link is not visible in a standard procurement review. The bank needs enough information to understand material sub-dependencies, the provider’s notification duties and what happens if a subcontractor changes. This does not mean auditing every minor vendor. It means focusing attention where a change could affect a critical operation.
Data location and accessibility matter in recovery. If a service is unavailable, can the bank obtain current customer and transaction data in a usable format? If copies exist, how recently were they updated, and who can access them? A backup that cannot be restored within the service tolerance has limited value. A transition plan should also address data deletion and control after a contract ends, while preserving evidence needed for reconciliation or regulatory duties.
Incidents expose governance gaps
During an outage, teams must make trade-offs. A manual payment process may maintain access for urgent cases but introduce operational error or fraud risk. A decision to close a channel may protect record integrity while preventing customers from accessing funds. These judgments should have accountable owners, a record of why the decision was taken and a means to reverse it when conditions improve. The framework must be practised before a real incident.
Communication should reflect what is known, what remains uncertain and when the next update will arrive. Customers need to know whether a payment was received, queued or rejected. Staff need consistent instructions so that the same question does not receive conflicting answers across branches and call centres. Recovery is incomplete until outstanding transactions have been reconciled and complaints caused by the disruption have a clear path to resolution.
Evidence for supervisors and boards
A board pack can bring together critical service maps, concentration exposures, test results and time-bound remediation actions. It should indicate which problems recur, what has actually been fixed and what residual risk is being accepted. An issue rated as low probability but capable of disabling several critical services deserves explanation. The board also needs visibility when a planned growth or technology change increases dependence on an already important provider.
This approach is more demanding than an annual policy review. It requires the first line of business to own the customer service, technology teams to understand the failure path and risk teams to challenge assumptions. Independent assurance can test the evidence, but it cannot replace operational ownership. The result should be a continuously updated view of whether the bank can continue delivering its most important services.
Resilience is ultimately a question of what a bank can continue to do for customers under stress. Shared technology can bring efficiency, scale and security expertise, but it can also make distinct services fail together. Banks that trace those links, test the customer outcome and fund specific repairs are better placed to judge their resilience than banks that rely on an impressive inventory of controls.
Sources
Basel Committee’s principles for operational resilience
Financial Stability Board’s third-party risk toolkit
Digital Operational Resilience Act framework described by the EBA