Business Continuity and Disaster Recovery

Business continuity and disaster recovery means keeping an important service going through disruption, or bringing it back in a usable form before the harm from its absence becomes intolerable. The work starts with the service and its tolerance, not with a building. From that tolerance, a firm works back to the order in which parts of the service must return, the data those parts need, the people who must act, and the suppliers and systems they depend on. Under DORA in the EU, which applies from 17 January 2025, and under the separate UK regime in FCA PS21/3 and PRA PS6/21, the labels and duties differ, so a firm should keep the regimes apart in its own documents rather than blending them into one generic plan.

A plan written for premises answers a narrow question: how do people leave safely and where do they gather. That question matters, but it does not answer the questions a disrupted service raises. Customers may still be unable to pay, settle, claim or access money even when staff are safe and working from another location. A service plan therefore treats premises as one dependency among others, alongside people, technology, data, suppliers and communications. Consider an illustrative payments service. If its processing system is unavailable, moving staff to another office changes nothing for customers until the system, its data and its connections to settlement partners are restored in the right order. The building plan is a starting point for safety, never a substitute for service recovery.

Tolerance gives continuity work its direction. It describes, for a named service, the point at which disruption stops being manageable and starts causing harm that the firm regards as intolerable. That harm can take several forms: customers unable to complete essential transactions, obligations missed, records left uncertain, or confidence damaged because nobody can explain what is happening. Once that boundary is understood, planners can ask what must return earliest, what can wait, and what can be done manually for a time. Without that boundary, every part of a service looks equally urgent, recovery teams chase the loudest system rather than the most important service step, and a plan can claim success while the customer-facing step remains broken.

A usable plan reads like a sequence of decisions and actions, not like a description of an organisation. It names the service, the person accountable for it, and the person authorised to activate the plan when that person is unavailable. It lists dependencies in the order they must return, states what data each step needs and where a clean copy can be found, and identifies manual workarounds where they are genuinely possible. It also names suppliers whose failure would block recovery, and the alternative or degraded service that customers will receive while recovery continues. Where a plan instead lists committees, policies and generic responsibilities, responders must invent the sequence during the disruption, which is exactly when invention is hardest and mistakes are most likely.

Testing should resemble disruption, not document review. A tabletop discussion can expose unclear decision rights, a walkthrough can expose a missing contact or an inaccessible data copy, and a technical restore test can expose a dependency that was assumed to work. Each form of testing has value, and none proves the whole plan on its own. The strongest evidence comes when a test follows the recovery sequence under time pressure, with the people who would actually act, using the information they would actually have. Lessons should then change the plan, the tolerance discussion or the dependency map, and the change should be recorded against the service. A test that ends with praise and no amendments has probably not looked hard enough at the weak points.

The recurring failure is a plan that looks complete on paper and cannot be used when disruption begins. Nobody is sure who decides, nobody knows who calls whom, and the first restored step is unclear because the sequence was never rehearsed. That opening phase is unforgiving: customers notice silence, staff improvise in different directions, and early choices narrow later options. Avoiding that outcome takes rehearsal of decisions rather than familiarity with documents. If the decision maker, the caller list, the activation signal and the first service step can be stated without opening a long manual, the plan has a chance. If they cannot, the gap is not a formatting problem. It is the continuity work itself, and it should be fixed before the next test is booked.