OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 13 - Business continuity and disaster recovery / Guide

Continuity for Manual Workarounds

Manual workarounds explained: when paper and process fallbacks help a service, what controls they need, and how their later reconciliation is planned.

Published 26 October 2026Checked against the regulation text on 26 October 2026Regime-dependent: EU under DORA, UK under FCA/PRA, labelled in the guide

The short answer

A manual workaround is a planned way of doing service work without the normal system, using paper forms, spreadsheets, telephone checks, or a simplified process that staff can follow safely. It can keep a service usable while technology is restored, but only if it was designed, practised and controlled in advance. 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 regime should be labelled where duties are cited. A workaround invented during disruption, with no agreed limits and no plan for later reconciliation, can create fresh errors that outlast the original outage.

Where do manual workarounds help?

Workarounds help most where the service step is simple, the volume is manageable, and the risk of error can be checked. Taking a customer request, recording it accurately, and giving a clear next step may be suitable for manual handling. Complex calculations, large payment batches, identity decisions with serious consequences, or work that depends on real-time balances may not be. Planners should therefore assess each service step separately, rather than declaring that a whole service can go manual. The question for each step is practical: can staff do this work accurately, at the volume disruption will produce, with the information they will actually have, and can the work later be checked against the system of record.

What limits should a workaround have?

Consider an illustrative branch or contact service for a savings provider. If online systems are unavailable, staff might record customer instructions on controlled forms, verify identity through agreed alternative checks, and give customers a written record of what was requested. That approach can reduce anxiety and preserve customer intent, provided staff know which instructions may be accepted manually and which must wait. Instructions that would move large sums, change account ownership, or close an account may need to wait for system checks to return. A workaround that accepts everything, without limits, may feel helpful in the moment and create serious problems later, when staff must untangle instructions that should never have been taken manually.

How are manual workarounds controlled?

Controls around manual work deserve as much attention as the workaround itself. Forms should be numbered or otherwise traceable, entries should be checked by a second person where the risk warrants it, and customer records should capture what was done, by whom, and on what information. Data protection matters too: paper records, photographs of forms, and personal notes taken during disruption need secure handling and a defined route back into the system. A workaround that protects service continuity but leaves sensitive records in uncontrolled locations has traded one risk for another. Planners should therefore design the full lifecycle of manual work, from capture through checking to reconciliation and secure disposal or filing.

What happens when systems return?

Reconciliation is the part most often neglected. When systems return, manual work must be entered, matched and checked, and discrepancies must be investigated rather than overwritten. That work takes time and skilled staff, and it should be planned as part of recovery, not discovered as an afterthought. Customers should be told, where relevant, that their instruction was captured manually and will be processed or confirmed once systems return, so they are not left uncertain about whether their request exists. If reconciliation reveals errors, the firm should correct them and learn from the pattern, rather than treating each error as an isolated slip by an individual under pressure.

How is a workaround practised and stopped?

Practise is what separates a real workaround from a paragraph in a plan. Staff should perform the workaround in a test, at realistic volume, with the forms and checks they would actually use, and with the time pressure disruption creates. That test often reveals that a form is out of date, that a check depends on a system that is also unavailable, or that nobody knows where completed forms should go. Those findings are valuable, provided they change the workaround. A workaround should also have a clear stopping point: the conditions under which manual work ends, the person who decides, and the communication that tells staff and customers that normal processing has resumed. Without that stopping point, manual work can drift on long after systems return, creating a parallel record that nobody fully controls.

Primary sources on the record

Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.

Follow the service map

Line 13 - Business continuity and disaster recovery Business Continuity and Disaster Recovery Why service continuity starts from tolerance and works back to restoration order, data, people and testing, rather than from a building evacuation plan alone. Line 13 - Business continuity and disaster recovery Continuity Testing Without Disrupting Customers Testing continuity without harming customers: tabletop, walkthrough and controlled exercises that expose gaps while keeping live service safe for each important service. Line 13 - Business continuity and disaster recovery Continuity After a Cyber Incident Continuity after a cyber incident: balancing containment with service recovery, checking data integrity, and returning in phases rather than rushing to restore.