Operational Resilience by Sector

The backbone of operational resilience does not change by sector. A firm still names an important service, maps what that service depends on, states what harm would be intolerable if the service stopped, tests a severe but plausible disruption, and keeps evidence that the test changed something. What changes by sector is everything that gives those steps their meaning: the service itself, the person using it, and the harm that follows when it fails. A payment service fails differently from a claims service, and a provider serving many firms fails differently from a firm serving its own customers. That is why sector guides exist. They do not repeat the framework with a new label. They apply the same questions to a different service and let the answers come out differently.

In retail banking the service might be access to a current account and the ability to pay from it. In insurance it might be the intake and payment of a claim after a home has been damaged. In asset management it might be the valuation of a fund and the settlement of a deal in it. Each of these is a service in the ordinary sense: something a person or a firm relies on to complete a task that matters to them. The framework language sits on top of that ordinary sense, and it is useful only while it stays attached to it. Once the service becomes an abstraction, the mapping, the tolerance, and the test all drift with it, and a firm can pass its own exercise while leaving the real service unexamined.

Harm is where sectors diverge most sharply, and it is the part a generic guide most often skips. A retail customer locked out of an account cannot pay rent or buy food. A policyholder waiting on a claim payment cannot repair a home or replace a car. An investor whose dealing service is suspended cannot exit a position while markets move. A merchant whose payment terminal stops working cannot trade. These are not the same harm, and they do not call for the same tolerance, the same communication, or the same recovery order. A tolerance written in abstract terms hides that difference. A tolerance written for a named service, in terms of the users affected and the tasks they cannot complete, exposes it.

Every sector leans on something it does not fully control, but the leaning point differs. Retail banking leans on a core platform and on payment rails. Payments lean on schemes, acquirers, and sponsor banks. Insurance leans on claims platforms, repair networks, and loss adjusters. Asset management leans on custodians, administrators, and pricing vendors. Investment firms lean on exchanges, brokers, and clearing. Fintech firms lean on a banking partner and on cloud services. A provider of ICT services is itself the dependency for others, which reverses the usual question: the firm is not asking what it depends on, but what depends on it. Naming the leaning point matters because recovery follows it. A firm that recovers its own systems while its payment rail is still down has not recovered its service.

A useful test in any sector starts from a disruption the service could plausibly suffer and follows it through to the user. In payments, that might mean a scheme or acquirer outage during a busy trading period, with merchants unable to take payment and customers unable to complete purchases. In insurance, it might mean a surge of claims after a storm, with intake, triage, and payment all under strain at once. In pensions, it might mean a corrupted member record or a failed payroll feed, with benefits at risk of being paid wrongly rather than not at all. The test is useful when it forces a decision: which service recovers first, who decides, what users are told, and what changes afterwards.

Before relying on any guide in this cluster, check whether it names a service you recognise, users you can picture, and a harm you can describe without reaching for framework language. If it does, the rest of the guide has something to attach to. If it does not, treat the guide as background and do the naming work yourself before planning a test. Check also which regime the guide is drawing on at each point. DORA, which applies from 17 January 2025, and the UK regime under FCA PS21/3 and PRA PS6/21 are separate regimes with their own policy statements and dates, and this cluster labels them separately rather than merging them into a single set of expectations.