OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 01 - Operational resilience foundations / Guide

Operational Resilience Glossary

Plain language explanations of the terms used across operational resilience: important services, tolerances, mapping, scenarios, and the evidence that ties them together.

Published 26 October 2026Checked against the regulation text on 26 October 2026Regime-dependent: EU under DORA, UK under FCA/PRA, labelled in the guide

The short answer

This glossary explains the working vocabulary of operational resilience in plain language, so that a reader can follow the other guides in this cluster without being misled by jargon. The central terms are important business service, impact tolerance, intolerable harm, mapping, severe but plausible scenario, and evidence, and each term describes a piece of the same discipline rather than a separate programme.

The discipline can be summarised in one sentence using those terms: a firm names an important business service, maps its dependencies, sets an impact tolerance that marks intolerable harm, tests the service against a severe but plausible scenario, and keeps evidence of what changed as a result. A reader who can follow that sentence can follow the rest of the cluster.

What is an important business service?

An important business service is a service whose disruption would cause serious harm to users or to the wider market, judged by the firm under the regime that applies to it. Importance is therefore a judgement about harm, not a judgement about revenue, system size, or internal prestige, and a service can be important even if it is technically modest.

The UK regime uses the language of important business services and impact tolerances, while DORA uses related language around ICT risk and digital resilience for financial entities. The labels differ by regime, and this guide keeps them separate, but both point to the same idea: some services matter enough that their recovery deserves explicit attention.

What is an impact tolerance?

An impact tolerance is the maximum level of disruption to an important service that a firm is willing to accept, expressed in terms of the harm users would suffer, such as how long they are left without the service and how widely they are affected. It is set in advance, with reasoning, so that recovery during an incident can be judged against a decision made calmly rather than improvised under pressure.

Intolerable harm is the point beyond that tolerance, where the harm becomes unacceptable. The two terms belong together: a tolerance without a sense of intolerable harm is an arbitrary limit, and a discussion of harm without a tolerance gives no guidance for recovery order or escalation.

What do mapping and scenarios mean?

Mapping means tracing an important service end to end, from the user through channels, processes, systems, data, suppliers, and people, so that the firm can see what the service actually depends on. A map is useful when it reveals a dependency that a system list would hide, such as a supplier that supports both a service and its backup.

A severe but plausible scenario is a demanding but imaginable disruption used to test that mapped service, judged by whether the service recovers within its tolerance. Scenario testing is therefore not a generic disaster rehearsal. It is a service specific test, and its value lies in the owned changes it produces, not in the reassurance of having run it.

What counts as evidence?

Evidence, in this context, means records that show a decision, a test, or a change for a particular service, rather than general programme documents. A service map, a tolerance with its reasoning, a scenario result with owned actions, and a follow up record showing those actions completed together form a chain that a reviewer can follow from service to outcome.

Evidence also includes incident records, where a real disruption shows what actually happened against the tolerance and what changed afterwards. A firm whose evidence consists only of policies and plans, with no test or incident learning attached to a service, has described an intention rather than demonstrated resilience.

What should a reader check next?

When a new term appears in a resilience document, ask which service it refers to, what harm it concerns, and what evidence would show it. If the term cannot be tied to a service in that way, it may be jargon filling a gap where a service judgement should be.

This glossary is educational and does not define legal terms for any regime. Where a regime gives a term a specific meaning, the regime source should be checked, and the label for that regime kept with the term when it is used.

Primary sources on the record

Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.

Follow the service map

Line 01 - Operational resilience foundations What Is Operational Resilience A plain explanation of operational resilience: what it means for an important service, how harm and recovery are judged, and why a patched system can still fail users. Line 01 - Operational resilience foundations How Regulators Test Resilience How supervisors test operational resilience in practice: through service maps, tolerances, scenario evidence, and follow up, rather than through policy documents alone. Line 01 - Operational resilience foundations Resilience Maturity Without Maturity Theatre How to judge resilience maturity honestly: by recovery evidence for named services, not by levels, colours, or programme dashboards, and by whether recovery improves over time.