Home / Wiki / O / Operational Resilience Mapping

Operational Resilience Mapping

Compliance Risk and ControlsUpdated 15 Nov 2026

Operational resilience mapping is the process by which a bank, insurer, payment firm or market infrastructure identifies and records everything that a critical service depends on, from end to end. For each service, the firm documents the people, processes, technology, facilities and information involved in delivering it, including those supplied by other group companies and by outside providers. The resulting map shows where a failure would interrupt the service and how difficult it would be to substitute or recover each component.

Mapping is a regulatory requirement in the United Kingdom, where it forms the second step of the operational resilience framework after a firm has identified each important business service, and it supports the setting and testing of an impact tolerance for each one. Comparable expectations appear in the Basel Committee's principles for operational resilience and, for information and communication technology, in the European Union's Digital Operational Resilience Act.

01

Why regulators require it

Traditional operational risk management and business continuity planning were organised by department, system or building. A firm might know the recovery arrangements for its data centre and for its payments team separately without knowing whether, taken together, they would allow a customer to make a payment after a serious incident. Outages at banks and market infrastructures during the 2010s showed that failures often occurred at the joins between systems, teams and suppliers.

Supervisors responded by shifting attention from individual assets to services as experienced by customers and markets, and by asking firms to assume that disruption will happen. Mapping is what makes that shift practical: it connects the outward-facing service to the internal resources that produce it.

02

What a map contains

A map follows a service from the point at which a customer or counterparty initiates it to the point at which it is complete. Along that path it records the resources used, usually grouped under five headings:

  • People. The teams and key individuals, their locations and the skills that would be hard to replace.
  • Processes. The sequence of activities and controls, including manual steps and workarounds.
  • Technology. Applications, infrastructure, networks and the connections between them.
  • Facilities. Offices, data centres and other premises.
  • Information. The data the service needs, where it is held and how it flows.

Dependencies on third parties are recorded against whichever heading they fall under, and should extend to material subcontractors. This links mapping to third-party risk management and to the records kept in the regulatory outsourcing register. Regulators do not prescribe a format; they require that the map be detailed enough to serve its purposes and proportionate to the firm's size.

03

How firms use the map

Regulators state two purposes. The first is to identify vulnerabilities. A completed map exposes single points of failure, such as one application supporting several services or one person holding essential knowledge; concentration in a single supplier or location; components with long recovery times; and technology that is out of support. Firms are expected to remedy weaknesses that would prevent them from staying within tolerance.

The second is to support scenario testing. Firms must test whether they could remain within impact tolerance for each service in severe but plausible scenarios, for example the loss of a data centre, a cyber attack that corrupts data, or the failure of a key supplier. The map tells the testers which resources a scenario would remove and what the knock-on effects would be. It also informs recovery priorities, by showing whether each component's recovery time objective is consistent with the tolerance for the service as a whole, and it is a working document during real incidents.

04

Regulatory framework

The United Kingdom's rules were published in March 2021 by the Prudential Regulation Authority, the Financial Conduct Authority and the Bank of England. They took effect on 31 March 2022, by which date firms had to have identified their services, set tolerances and completed initial mapping and testing. A transitional period ended on 31 March 2025, after which firms must be able to remain within tolerance. The firm's board must approve a written self-assessment, and accountability is assigned to an individual under the senior managers regime.

The Basel Committee's principles, issued in March 2021, ask banks to map the interconnections and interdependencies needed to deliver critical operations. The Digital Operational Resilience Act, which has applied since January 2025, requires financial entities to identify and document the technology assets and supplier arrangements that support their critical or important functions. UK rules on critical third-party oversight extend supervisory attention to major suppliers themselves.

05

Practical difficulties

Mapping is laborious. Large firms run thousands of applications, and inventories are often incomplete or inconsistent between departments. Obtaining information from suppliers about their own subcontractors can be difficult. Maps go out of date as systems and organisations change, so firms need a process to review them at least annually and after material change, and many link them to configuration databases to keep them current. Choosing the level of detail is a matter of judgement: too little and the map cannot support testing, too much and it cannot be maintained. Oversight usually sits with the board risk committee, alongside wider cybersecurity risk reporting.

Last updated 15 Nov 2026