Continuity Testing Without Disrupting Customers

Continuity testing should expose weaknesses without becoming a disruption in its own right. That balance is achieved by choosing the right form of test for the question being asked, by controlling scope, and by protecting live customers and live data throughout. A discussion-based test can challenge decisions and reveal unclear roles, while a walkthrough can check contacts, access and sequences, and a controlled technical test can check restoration in isolation. 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, testing expectations should be labelled by regime, because the frameworks are not identical. The aim in every case is learning that changes the plan, not a performance that confirms it.

Different tests answer different questions, and confusing them weakens both. A tabletop exercise is good for decision making: who activates, who communicates, what degraded service customers receive, and when normal service resumes. It is poor evidence that a system can be restored, because nobody actually restores anything. A walkthrough is good for sequence and access: can the named people find the plan, reach the data copy, contact the supplier, and follow the steps in order. A technical restore test is good for system and data recovery, but it should be separated from live service so that a failed test does not become a customer incident. Choosing the test to match the question keeps testing honest and keeps customers safe.

Safeguards should be designed before a test begins. Test planners should state what is in scope and what is explicitly out of scope, which systems and data are involved, how live customer journeys will be protected, and how the test will be stopped if something unexpected happens. That stop condition matters: a test that cannot be halted safely is a risk, not a control. Communication also matters, even for internal tests, so that staff who notice unusual activity do not mistake a test for a real incident, and so that customer-facing teams are not caught unprepared if a test produces a visible effect. A short, clear test briefing, with roles and stop criteria, prevents much of the confusion that testing can otherwise cause.

Consider an illustrative pension payments service. A tabletop exercise might explore what happens if payment processing is unavailable close to a payment date, forcing decisions about customer communication, degraded service and reconciliation. A separate walkthrough might check that the team can locate the recovery sequence, identify the data copy, and contact the payment supplier through an alternative route. A technical test, in a separate environment, might restore the payment data and check its integrity without touching live payments. Each exercise teaches something different, and together they give a fuller picture than any single large exercise that tries to test everything at once and risks affecting the very service it is meant to protect.

Testing should include people who are often left out. Customer-facing teams can reveal how a degraded service will actually be explained, suppliers can reveal where their recovery assumptions differ from the firm's, and second-line reviewers can challenge whether a test was demanding enough. Vulnerable customers deserve particular attention: a test should ask how customers who rely on telephone contact, who have limited digital access, or who need additional support will be helped if the usual route fails. A test that only involves technical teams may prove that systems return, while leaving the customer experience of disruption completely untested. That gap only becomes visible when real customers are affected.

Learning is the point, and learning should be tracked. A test report should record what was tested, what failed or surprised the team, what changed as a result, and when the changed step will be tested again. Findings that are filed without an owner and a follow-up date tend to fade, especially when the next operational priority arrives. Firms should also be honest about tests that were too easy: a scenario with no ambiguity, no missing information and no competing demands may reassure participants while teaching little. Gradually increasing realism, while keeping safeguards in place, builds capability without turning testing into a source of customer harm. That steady progression is what makes continuity credible over time.