Cyber Recovery after Ransomware and Outages

Cyber recovery after ransomware and outages is not the moment a system switches back on. It is the decision to bring a service back, and the work of bringing it back clean, so that customers can use it without the incident travelling with it. A service counts as recovered when the firm understands what was affected, has a copy of data it can trust, has rebuilt or restored the parts that were compromised, and has a named decision that the service is safe to use again. Availability alone does not meet that test, because a service can be reachable and still unsafe.

The distinction matters most after ransomware. Encryption or disruption may be visible, while the route the attacker used, the data that was changed, and the copies that were touched may not be. Restoring quickly from the same compromised source can therefore recreate the problem in a cleaner looking form. Recovery, in this sense, is slower and more deliberate than restart, and its pace is set by evidence rather than by pressure to return to normal.

Recovery starts with a single named service, not with a technology estate. A retail payments service, for example, is used by customers to pay, to check balances, and to receive confirmations, and each of those journeys depends on other systems, data stores, and providers. Naming the service makes the recovery question concrete. Which journeys must return, in what condition, and for whom, and what would count as a return that customers should not trust.

A clean starting point is a version of the service and its data that the firm has reason to believe is free of the incident. Finding one is rarely a matter of picking the most recent backup. The most recent copy may predate detection by only a short interval, yet still contain the intruder, altered records, or a configuration change that opened the route in. An older copy may be clean but may lose legitimate transactions that happened since it was taken. Recovery is the trade between those two risks, and the choice should be recorded with its reasoning.

Services rarely return all at once. Identity and access usually need to be sound before customer channels reopen, and core records usually need to be checked before transactions are allowed to change them. The order is a judgement about dependence and risk, not a list of systems in alphabetical order or in the order they failed. A sequence that restores a customer facing channel before the ledger behind it is trustworthy may look like progress while creating new errors that are harder to untangle than the original outage.

Under DORA, which applies from 17 January 2025, digital operational resilience includes the ability to restore ICT systems and data after disruption, and the regulation should be read as the EU frame for this guide. Under the UK regime, FCA PS21/3 and PRA PS6/21 set the operational resilience expectations for firms, with their own policy statements and dates stated separately. The guides in this cluster label the regime whenever a duty is described, so the two frames are never blended into a single invented rule. A firm in scope of one regime should follow that regime, and a firm in scope of both should be able to show where each expectation is met.

The recurring pitfall in this cluster is restoring quickly from the same compromised source and calling the service recovered, when the incident is still inside it. Speed is understandable during an outage, and customers, colleagues, and the press may all press for a return. But a fast return that has to be withdrawn damages trust more than a slower return that holds. A firm can manage expectations during a delay with clear communication. It cannot easily explain why a service it declared recovered had to be taken down again.

A second pitfall is treating recovery as a technology task with no service owner. Backups may restore, servers may restart, and yet no one may have checked whether customer records reconcile, whether pending payments were duplicated, or whether a vulnerable configuration returned with the system. Recovery evidence should therefore speak in service terms: which journeys were checked, what was found, what was limited, and who approved the return. If the evidence only lists systems restarted, it has described activity, not recovery.