At 06:45 on a Monday, a 40-person accountancy firm found its shared client folders renamed, its finance system unavailable and a ransom note displayed across several PCs. This ransomware recovery example shows why the first few hours matter more than the ransom demand itself. A rushed restart, an overwritten backup or an employee reconnecting an infected laptop can turn a contained incident into a complete business outage.
The firm held payroll records, tax returns, identity documents and years of correspondence. That made the incident both an operational emergency and a confidentiality issue. The aim was not simply to get files back. It was to contain the attack, preserve evidence, establish what had been accessed, recover clean data and return systems to service without bringing the attacker back into the network.
The first decision: stop the spread, not the business forever
The IT manager initially saw errors opening files on one shared drive. Within minutes, staff reported that file names had changed and extensions were unfamiliar. The correct immediate response was to isolate affected machines from the network. Wi-Fi was disabled, network cables were removed and remote access sessions were terminated. Staff were told not to restart, log in again, connect personal USB devices or attempt to open altered files.
That response had a cost. People could not work normally, and client deadlines were approaching. But leaving systems connected while investigating would have risked encryption spreading into backup storage, cloud synchronisation folders and less obvious servers. Containment is disruptive by design. It is still far less disruptive than losing every recoverable copy.
The firm also retained the ransomware note, recorded the time systems were discovered affected and photographed the messages on screen. These details can assist an incident response team, insurers and, where appropriate, law enforcement. More importantly, they help establish a reliable timeline. In a serious ransomware event, assumptions are dangerous. Evidence should be collected before machines are altered or wiped.
Ransomware recovery example: assessing what remains
The business had three possible sources of recovery: local server disks, a network-attached storage device used for backups and cloud-synchronised document libraries. None could be trusted immediately. A backup that appears present may contain encrypted files, while a cloud platform may have synchronised the damaged versions before anyone noticed the attack.
A forensic assessment began with copies of the affected storage rather than work on the originals. Technicians examined the type of encryption, the pattern of changed files, the ransomware note and system logs. They also checked whether the attackers had deleted shadow copies, altered backup retention settings or created unauthorised administrator accounts.
This stage answered several questions that are often overlooked in the panic:
- Which systems were encrypted, and which were merely inaccessible?
- Did encryption reach backup repositories or cloud storage?
- Was data likely copied out before encryption began?
- What was the last known clean point for each critical dataset?
- Could the company restore safely without preserving malicious access?
The findings were mixed. The main file server was heavily encrypted. The newest backup set on the NAS had also been affected because it remained permanently connected and writable from the network. However, an older immutable backup copy was intact, and the cloud platform retained previous versions of several active document libraries. A separate archive drive contained client records that had not been connected during the attack.
This is a realistic outcome. Ransomware recovery is rarely a single action. Different data sources have different recovery points, retention periods and risks. A business may recover 95 per cent of its files yet still need specialist work to reconstruct the remaining five per cent, particularly databases, virtual machines or documents changed after the last clean backup.
Why paying the ransom was not treated as the recovery plan
The attackers demanded cryptocurrency in exchange for a decryptor and threatened to publish client data. The firm considered payment because payroll processing was due that week. It is understandable that organisations under pressure look at the fastest apparent route back to work.
Payment, however, is not a guarantee of recovery. A decryption tool may be slow, unreliable or incapable of restoring every file correctly. The criminals may demand more money, retain copied data or use stolen credentials to return later. There may also be legal, insurance and sanctions considerations that require specialist advice before any decision is made.
In this case, viable clean recovery sources meant the firm did not depend on a criminal decryption key. The incident team concentrated on rebuilding access properly. The decision reduced uncertainty, but it did not remove the need to investigate possible data theft. Encryption and exfiltration are separate risks, and both need to be addressed.
Restoring data without restoring the infection
Recovery started in a clean environment. The affected server was not simply decrypted or placed back online. It was rebuilt, patched and protected before restored data was introduced. Administrator passwords were reset, multi-factor authentication was enforced where available, and suspicious accounts, scheduled tasks and remote tools were reviewed.
The clean immutable backup was restored first to a segregated environment. This allowed the team to check folder structures, test applications and scan the recovered data before reconnecting users. The cloud service supplied later versions of working documents, but each batch was checked against the incident timeline. Files saved after the suspected compromise date could be useful, or they could contain malicious changes.
The archive drive filled gaps in historic client records. For a small number of files that existed only on encrypted server volumes, specialist data recovery work was considered. Whether that is viable depends on the ransomware strain, the storage type and what occurred after encryption. Continued use of an affected drive can overwrite remnants of data and reduce the available recovery options, especially on SSDs where trim operations may permanently remove blocks.
For complex cases involving failed RAID arrays, NAS devices or damaged disks, a controlled laboratory assessment can be the difference between preserving the remaining evidence and making the loss worse. Data Recovery Lab handles media in a forensic-grade environment, with secure collection, confidential handling and a no-recovery, no-fee approach for suitable cases.
The point at which normal operations can resume
The accountancy firm restored priority services in stages. Payroll and active client work came first, followed by the document archive and less time-sensitive departmental data. Staff did not regain broad access until restored folders had been checked and security controls were in place. That was slower than switching everything back on, but it prevented a second outage caused by missed persistence or unverified data.
Clients whose information may have been involved were assessed through the firm’s incident and data protection process. Depending on the facts, this may involve legal advice, insurer notification and consideration of reporting obligations under UK GDPR. Communication should be factual and measured. Promising that no data was accessed before the evidence supports that conclusion can create a second problem.
The firm also documented what had failed: an online backup device had been reachable with ordinary domain credentials, backup alerts had not been reviewed promptly and some legacy accounts had excessive permissions. These are common weaknesses, not signs of unusual incompetence. Ransomware groups actively look for precisely these paths.
What this recovery example teaches businesses
The clearest lesson is that backups alone are not enough. A recoverable backup needs separation from the production network, protected credentials, retention that reaches back beyond the attack date and regular restoration tests. A backup that has never been restored is an assumption, not a recovery plan.
It also pays to define responsibilities before an incident. Employees should know who can isolate systems, who contacts the insurer or incident response provider, and who communicates with clients. IT teams need an inventory of critical systems and a sensible recovery order. Senior leaders need to understand that bringing systems back quickly is not the same as bringing them back safely.
For individuals, photographers and smaller firms, the same principle applies on a smaller scale. Stop using the affected device, disconnect it from networks and avoid downloading random decryptors or recovery utilities onto the original drive. Preserve the device and seek an assessment before attempting repairs. The files that matter most are often the files least easy to replace.
When ransomware strikes, calm, evidence-led action protects more than data. It protects client confidence, legal options and the chance of a clean recovery. The best time to test that process is before a ransom note appears on screen.
