Operating in the Gap: Preparing UK Firms to Run Before Recovery Arrives

There is a period in every major incident that planning tends to skip. Impact has landed, the recovery team is engaged, and full service is hours or days away. In that gap the organisation must still pay people, settle trades, dispatch engineers, admit patients or process claims — using spreadsheets, phone calls and manual checks that steady-state automation has spent a decade removing.

Most continuity documentation is written for the moment of loss and the moment of restoration. The hours between them receive far less attention, even though that is where customers are lost and where regulators will later ask what the firm did, when, and on whose authority.

The 72-hour framing is a useful discipline because it mirrors obligations UK firms already carry. The ICO's personal data breach notification window runs to 72 hours. Supervisory expectations around incident reporting assume early, candid engagement rather than a polished post-mortem. And under the operational resilience rules that took effect in March 2025, impact tolerances for important business services are expressed in hours, not days — which means the design question is not whether the firm can recover eventually, but what it can keep doing in the meantime.

The gap is a different operating model

During the gap, the constraint is no longer infrastructure capacity. It is human decision-making under incomplete information. Systems that usually arbitrate — the ledger, the workflow engine, the reconciliation job — are silent, so people arbitrate instead, without the controls those systems were quietly providing.

Designing for this means accepting three things. Manual operation will be slower and will produce errors that need reconciling later. Authority must be delegated in advance to people who will be awake at 03:00. And every workaround needs a record, because the firm will have to explain it.

Decide in advance who decides

Ambiguity about decision rights is the most common failure mode in the first day. Establish, in writing and before anything happens:

• A single accountable incident director, with a named deputy and a defined scope of authority, including the power to suspend a service, invoke a manual fallback and authorise spend up to a stated limit.
• Pre-approved thresholds for invoking fallbacks, so activation is a reading off a matrix rather than a debate.
• The boundary between technology recovery decisions and business decisions, written down rather than negotiated mid-incident.
• Named deputies for every critical role, with rosters that survive annual leave, illness and the second day of a long event.

The test is simple: could a competent duty manager, woken at an unsociable hour, act correctly using only the documents in front of them?

Fallback procedures people can actually run

Fallback documentation fails for predictable reasons. It is written by people who understand the system for people who do not, it assumes access to tools that are themselves unavailable, and it has never been executed end to end.

Write procedures at the level of the person performing them. Specify the minimum viable service — what must happen, what can wait, and what will simply not be done for three days. Confirm that the tools required for the manual process are genuinely independent of the failed estate: if the workaround needs the same identity provider, network segment or file share, it is not a workaround. And set out the reconciliation path in advance, so the firm knows how manual entries will be validated and loaded once systems return.

Set a communications clock

In a multi-day incident, communication cadence is a control, not a courtesy. Publish a schedule — an initial notification, a two-hour update, then at fixed intervals through day one, day two and day three — with a named owner for each audience: regulators, customers, staff, suppliers, the board.

Fixed timing achieves two things. It prevents the internal update vacuum that breeds rumour, and it gives supervisors and customers a rhythm they can plan around. Prepare holding statements and escalation contacts in advance; drafting them during the event wastes the scarcest resource available.

Build an evidence trail that survives scrutiny

Post-incident reviews frequently stall because nobody can reconstruct the timeline. Build the record as the incident unfolds, not afterwards. A timestamped decision log capturing who decided what and on what information, preserved communications, the outputs of the manual processes, and the reconciliations performed at restoration.

This trail serves three audiences: internal reviewers, supervisory bodies who may ask for a factual account, and — where personal data is involved — the notification assessment that must be reached within 72 hours. Firms that cannot evidence their own timeline find that the reporting deadline drives the narrative rather than the facts.

Rehearse the first three days, not the failover

Failover tests prove that technology can move. They rarely prove that an organisation can operate. Run exercises that start with the assumption of unavailability and stay there: run a manual settlement cycle, take customer calls without the CRM, process one day of work on spreadsheets and reconcile it under supervision.

Make at least one exercise unannounced, and extend it beyond a single working day so that fatigue, shift handover and deputy coverage are genuinely tested. Then capture the findings as changes to procedures, thresholds and rosters — not as a lessons-learned slide.

The measure of readiness is unglamorous. On day four, the firm should be able to demonstrate a coherent account of the first three days: what it kept running, who was accountable, what it told people, and how the manual work was reconciled back into the systems of record.