Business Continuity Plans for Services

A business continuity plan for a service is a working document for one named service, written so that people under pressure can follow it without guessing. It states the service in customer terms, names its owner and the person who may activate it, and sets out the recovery sequence in the order customers need it. Under DORA in the EU, which applies from 17 January 2025, continuity expectations sit within digital operational resilience duties, while in the UK, FCA PS21/3 and PRA PS6/21 set a separate operational resilience framework. The regimes should be labelled separately in the plan, because their language, scope and supervisory expectations are not interchangeable. A plan that serves both regimes without distinguishing them risks confusing the very people who must act.

Many plans fail because they describe the firm rather than the service. Pages of governance, policy references and organisational charts give an impression of completeness while leaving the recovery sequence vague. A service plan reverses that emphasis. Its opening pages should answer practical questions: what service is disrupted, who is affected, who decides, who is called, what returns earliest, and what customers receive in the meantime. Supporting detail can sit behind that action sequence, in appendices or linked records, but it should not bury it. When a responder opens the plan during disruption, the useful test is simple. Can they find the next action within moments, without searching through background material?

Consider an illustrative card payments service used by small retailers. Its plan should begin with the customer journey: a retailer takes payment, the transaction is authorised, funds move, and the retailer can reconcile the sale. Each step depends on different technology, data and suppliers. The plan therefore orders recovery by that journey, not by system size or by which team shouts loudest. It might restore authorisation before reporting, because retailers need to trade before they need a perfect reconciliation file. It should also state what happens if a step cannot return quickly: whether payments can be accepted in a limited way, what records must be captured, and how those records will later be matched. That level of specificity turns a plan into a service commitment.

People, data and suppliers deserve the same attention as systems. A plan should name deputies for key roles, because disruption rarely respects working patterns or holidays. It should state where clean, usable data can be obtained, how its integrity will be checked, and what to do if the most recent copy is in doubt. It should also name suppliers that could block recovery, the service each supplier provides, and the contact route that works outside normal business channels. A plan that assumes staff availability, data integrity and supplier responsiveness without checking them is a list of hopes. A stronger plan records the check, the alternative, and the point at which the alternative itself runs out.

A plan is only as good as its last rehearsal. Activation should be practised with the people named in it, using realistic disruption stories that include ambiguity, missing information and competing demands. A rehearsal that only confirms that a document exists teaches little. A rehearsal that forces a decision, reveals a stale contact, exposes a workaround that no longer works, or shows that a data copy cannot be read in time has done its job, provided the findings change the plan. Firms should record what changed, who owns the change, and when the amended step will be rehearsed again. Without that loop, plans age quietly while services, suppliers and systems change around them.

Several traps recur. One is writing a single plan for the whole firm and calling it a service plan, which hides differences between services that customers experience very differently. Another is treating the plan as a compliance artefact, updated for an audit and then left untouched. A further trap is including workarounds that staff have never practised, or that depend on skills and access that have since changed. The remedy is service-level ownership. The service owner should be able to explain, in plain language, what the plan does earliest, what it deliberately leaves until later, and what it cannot do. If that explanation requires reading the plan aloud, the plan is probably too long, too vague, or written for the wrong audience.