What Is Operational Resilience

Operational resilience is the ability of a firm to keep an important business service running for its users through disruption, and to restore that service before the harm it causes becomes intolerable. The starting point is the service itself, such as a payment, a claim, or a trade, and the people who depend on it, rather than a list of servers or applications.

That shift in starting point changes the questions a firm asks. Instead of asking whether a system is back online, the firm asks whether users can still pay, claim, or trade, what harm a stop would cause while they cannot, how long that harm could be borne, and what must be restored first. A firm can patch servers and still fail users, because no one asked those questions in that order.

A system inventory describes what a firm owns. A service description describes what users receive, and that is the thing whose loss hurts. A payment service, for example, draws on a customer channel, a processing engine, a settlement partner, and a data store, and a failure in any one of those places can stop the whole service even while the other parts look healthy.

Starting from the service forces the firm to trace that chain end to end and to notice dependencies that an inventory would hide, such as a single supplier, a manual workaround, or a data feed that no one owns. The map that results is not decoration. It is the basis for deciding what to protect, what to test, and what to restore first when something breaks.

Harm in this context is the effect on users and on the wider market when a service stops or degrades, not merely the internal inconvenience of an outage. A customer who cannot make a rent payment, a claimant waiting on money after a loss, or a trader unable to close a position each experience a different kind of harm, and the seriousness of that harm shapes how urgently the service must return.

Because harm differs by service, a single recovery target copied across a firm tells the reader very little. A tolerant approach sets a limit for each important service in terms of the harm a disruption would cause, and then judges recovery against that limit. The limit is a judgement about users, made in advance, not a figure discovered during an incident.

The recurring pitfall is treating resilience as a technology project that can be completed and filed away. Services change, suppliers change, user behaviour changes, and attackers and failure modes change with them, so a recovery plan written for last year service may describe a service that no longer exists.

Resilience therefore behaves more like an ongoing discipline than a delivery. Mapping is refreshed when the service changes, tolerances are revisited when harm changes, and testing is repeated so that lessons from one test or incident alter the next plan. A firm that reports resilience as finished has usually stopped looking, and the next disruption is the first thing that will notice.

The EU regime under DORA, Regulation (EU) 2022/2554, sets digital operational resilience requirements for financial entities, and it applies from 17 January 2025. The UK regime under FCA PS21/3 and PRA PS6/21 sets its own operational resilience expectations, with its own policy statements and dates, and the two regimes should not be merged into one set of duties.

A reader comparing them should check, for each claim, which regime it comes from and which firms it covers. DORA speaks in terms of ICT risk and digital resilience testing, while the UK regime speaks in terms of important business services and impact tolerances. The language differs, but the underlying discipline is recognisably similar: name the service, understand its harm, and show that it can recover.

A useful check is to pick one service and ask whether its owner, its users, its dependencies, its harm limit, and its last test can all be named without a search through old documents. If any answer is vague, that gap is the work, and it belongs to the firm that owns the service, even where a supplier or group function does the day to day work.

This guide is educational only and does not give advice for a particular firm. The supporting guides in this cluster explain the distinctions, the harm concept, the scenario work, and the governance questions that sit behind the short answer given here, each in its own terms.