Recovery vs Business Continuity

Business continuity is about keeping an important service going through disruption, by working around a failure, switching to an alternative, or operating in a limited way until normal service can resume. Recovery is about bringing a service back, clean and trustworthy, after it has failed or been compromised. The two overlap, and a real incident will often need both, but they answer different questions. Continuity asks: how do we keep serving customers now. Recovery asks: how do we return to a service we can trust. Confusing them leads to plans that either keep a compromised service running or restore a service without ever having helped customers through the gap.

The distinction matters for planning as well as for language. A continuity plan that has no recovery sequence may keep customers served for a while, but it leaves the firm with no clean way back. A recovery plan that has no continuity thinking may restore a service eventually, but it leaves customers unsupported in the meantime. A firm needs both capabilities, planned together, with a clear understanding of where one ends and the other begins, and of how the firm moves from working around a failure to returning to normal service.

During an incident, business continuity provides the workarounds that keep customers served, or at least informed and supported, while the underlying problem is addressed. That may mean switching to an alternative system, operating manually for a limited set of journeys, directing customers to another channel, or prioritising the journeys that matter most. The aim is to reduce harm during the disruption, not to fix the underlying failure. Continuity measures are often temporary and imperfect, and they should be judged by whether they reduce harm, not by whether they replicate normal service.

Recovery adds the return to a trustworthy service. Where continuity works around a failure, recovery addresses it: understanding what was affected, choosing a clean starting point, restoring systems and data, checking the result, and deciding that the service is safe to use again. That work may happen while continuity measures are in place, and it may take longer than the continuity measures can comfortably sustain. The tension between those timescales is real, and it is why the two capabilities need joint planning rather than separate plans that assume each other away.

The two overlap in people, in governance, and in the early stages of an incident. The same service owner, the same coordination arrangements, and the same communication channels will often serve both. The same understanding of the service, its dependencies, and its customers underpins both plans. That overlap is a strength, provided the plans are written with it in mind, so that a team moving from continuity to recovery does not have to change its language, its leaders, or its record keeping mid incident.

Planning together means writing continuity and recovery as parts of one service story. The story starts with the service and its customers, moves through the disruption and the workarounds that keep customers served, and ends with the clean return and the evidence that supports it. Each part should reference the others: continuity measures should state how long they can sustain the service and what recovery needs from them, and recovery plans should state what continuity measures will be in place while restoration proceeds, and how the transition back will be managed.

A firm can judge whether it has both by asking, for each important service, two separate questions. First, if this service fails, how will customers be served, supported, and informed while it is down. Second, how will the service be brought back clean, in what order, on what evidence, and by whose decision. If the firm can answer both, with plans, with roles, and with recent testing, it has both capabilities in outline. If it can answer only one, it has a gap that the other capability cannot fill, however strong the answered part may be.

Under DORA, which applies from 17 January 2025, the EU frame is labelled separately from the UK regime under FCA PS21/3 and PRA PS6/21, with their own dates. Neither frame, in this guide, is presented as a single rule covering both capabilities identically. The practical judgement remains with the firm, with its ICT providers: does it have a way to keep customers served through disruption, and a way to return to a service it can trust afterwards. A firm that confuses those two questions may believe it is resilient because it has one answer, when resilience, for its customers, requires both.