Operational Resilience: Definition and Use in Compliance

What is Operational Resilience?

Operational resilience is a firm's ability to keep delivering its important business services through disruption, and to recover within limits it has agreed in advance. The shift from older thinking is subtle but real: instead of asking whether a system might fail, you assume it will, and you design around the consequences.

Regulators anchor the whole discipline on important business services. These are the services that, if interrupted, would cause intolerable harm to customers or threaten market integrity. For a retail bank that means access to deposits, card payments, and online banking. For a custodian it means settlement. The test is harm to the outside world, not inconvenience to the firm.

Each important service gets an impact tolerance. This is a hard number: the maximum disruption the firm can absorb before the harm becomes unacceptable. "Payments restored within four hours" is an impact tolerance. "We aim to fix things quickly" is not. The board owns these numbers and has to defend them to supervisors.

Take a mid-sized bank whose card authorization platform goes down on a Friday evening. Without resilience planning, the team scrambles. With it, they already know the tolerance is two hours, they know which vendor and which data feed sit underneath the service, and they have a tested failover. The difference shows up in whether customers can buy groceries that night. Operational resilience connects directly to a firm's risk appetite and its broader control environment, since the controls protecting a service determine how much disruption it can survive.

How is Operational Resilience used in practice?

In practice, resilience runs as a yearly cycle with continuous monitoring underneath it. Teams identify services, set tolerances, map dependencies, test against scenarios, fix gaps, and report to the board. Then they do it again as the business changes.

Mapping is where most of the hard work lives. For each important business service, the team documents every person, process, system, piece of data, and third party that the service depends on. A single payment service might touch a core banking system, a fraud engine, a sanctions screening tool, two cloud regions, and four vendors. Miss one dependency and your resilience picture is fiction.

Scenario testing is the proof. Firms run severe but plausible events: a prolonged cloud outage, a ransomware attack, the sudden failure of a critical supplier. The point is to find the dependency that breaks tolerance before a real incident does. A bank might discover its sanctions screening provider has no viable backup, which means screening stops the moment that vendor goes dark.

For compliance teams specifically, the work overlaps with transaction monitoring resilience. If monitoring fails, alerts queue, investigators fall behind, and regulatory filing deadlines come under pressure. One useful exercise: simulate 48 hours of monitoring downtime and count how many alerts and reports back up, then decide whether that volume is survivable. The honest answer often drives investment in redundancy.

Operational Resilience in regulatory context

The regulatory picture solidified fast between 2021 and 2025. The UK led with binding rules, the EU followed with DORA, and the Basel Committee set global principles. Firms operating across borders now juggle several overlapping regimes.

In the UK, the Bank of England, Prudential Regulation Authority, and Financial Conduct Authority published their final policy in March 2021. Firms had to identify important business services and set impact tolerances by March 2022, then prove they could remain within tolerance by March 2025. The FCA's policy statement PS21/3 lays out the requirements in detail.

The EU's Digital Operational Resilience Act applies from 17 January 2025. DORA is more prescriptive on technology, covering ICT risk management, incident reporting, resilience testing, and oversight of critical ICT third parties. It even brings major cloud providers under direct EU supervisory scrutiny, a first for the sector.

Globally, the Basel Committee on Banking Supervision issued its Principles for Operational Resilience in March 2021, aligning the concept with operational risk management. These principles cover governance, mapping, third-party dependency, and incident management.

There's overlap with adjacent regimes too. A firm's third-party risk management program and its business continuity plan both feed the resilience picture, and supervisors increasingly expect to see them joined up rather than run as separate silos.

Common challenges and how to address them

The hardest part of operational resilience is honesty about dependencies. Most firms underestimate how many systems and vendors sit behind a single service, and the gaps surface only during a real incident or a rigorous test.

Concentration risk is the sharpest example. When dozens of banks run on the same handful of cloud providers, an outage at one provider can take down multiple firms at once. The fix isn't simple, since rebuilding on a second cloud is expensive and slow. Practical responses include negotiating stronger exit and failover terms, holding offline backups of critical data, and stress-testing the assumption that a major provider can vanish for 24 hours. This connects directly to concentration risk and fourth-party risk, where your vendor's vendor becomes your problem.

Impact tolerances are the second trap. Teams set them too soft to avoid hard conversations, then discover during testing that they can't meet even the generous number. The answer is to set tolerances based on customer harm, validate them with real recovery data, and let the board feel the discomfort early rather than during a crisis.

A third challenge is treating resilience as a documentation exercise. A binder full of dependency maps means nothing if no one has tested it. Run tabletop exercises with the people who'd actually respond, inject surprises, and capture what broke. One bank found its incident bridge call had no compliance representative, so sanctions and reporting decisions stalled for hours during a simulated outage. They fixed the runbook before it cost them in reality.

Related terms and concepts

Operational resilience sits inside a web of related risk and continuity concepts, and understanding the neighbors sharpens the term itself.

The closest relatives are the building blocks regulators name explicitly. A critical business service (often called an important business service) is the unit resilience protects, and impact tolerance is the limit you commit to staying within. These two terms carry the regulatory weight; everything else supports them.

On the continuity side, disaster recovery and business continuity planning predate operational resilience and feed into it. Disaster recovery focuses on restoring technology after an event. Resilience is broader: it covers people, processes, and third parties, and it starts from the assumption that disruption will happen rather than treating it as an exception.

Incident handling links in through incident management, which governs how a firm detects, escalates, and resolves disruptions in real time. Strong incident management is how you actually stay inside an impact tolerance when something breaks.

Resilience also overlaps with the wider risk vocabulary. It connects to residual risk (what's left after controls), the three lines of defense governance model, and standards like ISO 31000 for risk management. For compliance leaders, the most useful link is to financial crime compliance, because a sanctions or monitoring system that goes dark is both a compliance failure and a resilience failure at the same time.