Continuity After a Cyber Incident

Continuity after a cyber incident is harder than continuity after a straightforward outage, because the firm must restore a service while also containing harm and avoiding a return of the problem. Systems may need to stay offline, data may be in doubt, and the usual recovery copy may itself be affected. The service plan therefore needs a cyber-specific path: how customers are helped while systems are checked, how clean recovery is decided, and how return happens in phases with checks at each stage. Under DORA in the EU, which applies from 17 January 2025, cyber resilience and incident handling are central, while the UK regime in FCA PS21/3 and PRA PS6/21 frames the same work within wider operational resilience. The regimes should be labelled separately.

The central tension is between speed and safety. Customers understandably want service back, and staff feel pressure to restore quickly. Yet restoring a compromised system, or reconnecting customers to data whose integrity is uncertain, can cause deeper harm than a longer outage. Service owners and technical responders therefore need a shared decision process, agreed before an incident, for judging when restoration is safe enough to begin. That process should include who can authorise return, what evidence is required, and what will happen if evidence is incomplete. Without that process, decisions are made under pressure, inconsistently, and without a record that later reviewers can follow.

Consider an illustrative wealth management service. After a cyber incident, clients may need information about their holdings, reassurance about their accounts, and a route to urgent transactions, even while trading or reporting systems remain offline for checks. Continuity planning should identify which client steps can be provided safely through alternative routes, which steps must wait until data integrity is confirmed, and how clients will be told about the difference without speculation. A holding message that promises a return date the firm cannot support, or that describes the incident in terms that later prove inaccurate, damages trust and creates fresh work when corrections are needed. Honest, limited communication is part of continuity, not a separate public relations task.

Data integrity is a particular challenge. Attackers may have altered, encrypted or exfiltrated data, and backups may include material created after compromise began. Recovery teams therefore need criteria for selecting a clean recovery point, even when that choice means losing recent legitimate work or accepting a longer recovery. They also need a plan for reconciling work done during disruption, for checking transactions that occurred around the incident, and for identifying customers who may need individual follow-up. Those tasks should be staffed and sequenced in the plan, because they are often discovered only after systems return, when attention has already moved on to normal operations.

Phased return helps manage risk. A service might return first to a limited group, a limited set of functions, or a read-only form, with monitoring and checks before wider return. Each phase should have entry criteria, a named decision maker, and a way to pause or reverse if problems appear. Staff should also preserve evidence during recovery, because restoring systems can overwrite material that investigators and reviewers later need. That preservation need should be built into the recovery sequence, not treated as an obstacle to it. A plan that restores quickly but destroys the record of what happened has solved the immediate problem at the cost of learning and accountability.

After service returns, continuity work is not finished. The firm should review what the incident revealed about dependencies, recovery copies, supplier support, communication and decision making, and should change the plan accordingly. It should also consider whether tolerance, impact analysis or recovery assumptions need revisiting in light of what actually happened. Customers who were affected may need follow-up, and staff who worked through the incident may need support and rest. A review that only records that service was restored misses the opportunity that a real incident provides: evidence, under real pressure, about which parts of continuity planning worked and which parts were only theoretical.