Identifying Important Business Services

An important business service is a service whose disruption would cause serious harm to customers, to markets, or to the wider financial system. Identification is therefore a judgement about harm, made service by service, before tolerances are set, before maps are drawn in detail, and before testing begins. A small service used by people with no ready alternative can matter more than a large service whose users can switch easily, and a service that looks routine inside the firm can be the point on which customers depend when they need money, cover, or access to an account. The firm that provides the service makes the judgement, documents the reasoning, and revisits it when the service, its users, or its dependencies change.

Start from the outside and work inward. Picture the service stopped, degraded, or producing wrong results, and ask who feels that first, what they cannot do as a result, and what happens next if the problem lasts. A customer who cannot pay a bill, reach savings, or report a loss is harmed in a direct and practical sense. Harm can also spread: a merchant who is not paid cannot pay staff or suppliers, a market participant who cannot settle a trade faces knock on exposures, and a widely used service that fails at a sensitive moment can shake confidence well beyond its own customer base. The test therefore looks at the kind of harm, the people affected, whether they have an alternative, and how the harm grows over time. Under DORA, which applies from 17 January 2025, the EU framing is digital operational resilience; under the UK regime, FCA PS21/3 and PRA PS6/21 set the equivalent starting point. The labels differ, so this guide keeps them apart rather than blending them into one set of duties.

Naming everything as important is a common first mistake. It spreads attention so thinly that tolerances, maps and tests become generic, and the services that truly matter receive no sharper treatment than the rest. Naming only the flagship product is the opposite mistake. It leaves quiet services unprotected, even though customers may depend on them at exactly the moment of stress, for example when they need to contact the firm, prove identity, or access money already held. Both errors come from starting with internal structure rather than with user harm. An organisation chart, a product catalogue, or a revenue ranking will produce a list that looks tidy and misses the point.

Identification decides where the rest of the resilience work goes. An identified service gains a named owner, a mapped set of people, systems and third parties it depends on, a tolerance that states what level of disruption is intolerable, and a testing programme that rehearses severe but plausible scenarios against that tolerance. A service that is not identified still needs sound operations, but it does not carry that full apparatus, and that distinction is the point of doing the exercise at all. Identification also forces choices about boundaries, covered in a companion guide: whether account access and payments from that account are one service or two, and whether a shared login function is part of each service or a service in its own right. Those choices should be recorded with reasons, because a later reader, auditor, or new owner needs to see why the line was drawn where it was, not merely where it falls.

A service list is a snapshot, and snapshots age. New products, new channels, migrations to new platforms, changes of supplier, and shifts in who uses a service can all move a service across the threshold in either direction. Incidents and tests are equally important sources of correction: if a disruption harmed people through a service that was not on the list, the list was wrong, and the review should say so plainly. Keep one inventory, keep the harm reasoning beside each entry, name an owner for each service, and review the list whenever a material change is planned, not only on a calendar cycle. This guide is educational only and does not give advice for any particular firm; the regimes named here should be read in their own texts, with UK and EU expectations kept separate.

Read a service list as a sceptic. For each entry, ask whether the harm is described in concrete terms a non specialist could understand, whether the users are named rather than assumed, and whether the service could be tested in a rehearsal without further translation. Ask what was left off, and why, because the reasoning for exclusion is often more revealing than the reasoning for inclusion. Ask who owns the list and when it was last challenged, since a list that no one has questioned recently is likely to reflect last year's business rather than this year's.