At 8.12am on a Monday, staff at a growing professional services firm found they could no longer open shared documents, access their accounting system or print essential paperwork. This ransomware recovery case study shows why the first few hours of an attack matter, but also why recovery is decided well before criminals gain access.
The example below is an anonymised composite based on common ransomware recovery scenarios faced by small and mid-sized organisations. It is not about dramatic technical heroics. It is about sound preparation, calm decision-making and restoring the business in the right order.
The incident: a normal morning stopped
The firm had around 45 employees across one main office and a small satellite site. It relied on Microsoft 365 for email and collaboration, a cloud-hosted line-of-business application, local file storage for active client records and a VoIP phone system. Like many organisations, it had valuable data, limited internal IT resource and little appetite for operational downtime.
The attack began with a compromised user account. The criminal used valid credentials to access the environment, move through systems and encrypt a number of shared folders overnight. A ransom message appeared on affected devices shortly after staff arrived.
The first temptation was understandable: get everything switched back on as quickly as possible. That would have been the wrong move. Reconnecting devices or restoring data before understanding the scope of the compromise can give an attacker another opportunity to encrypt files or take information.
The immediate priorities were to isolate affected equipment, preserve evidence, confirm which services remained safe and maintain communication with staff and clients. Email was still available, but access controls were tightened while the incident was assessed.
What made recovery possible
The organisation was disrupted, but it was not without options. Several decisions made before the attack created a workable recovery path.
First, its backup strategy included protected copies that could not be altered by a compromised everyday user account. Backups are only useful if they are separate from the systems they protect and regularly checked. A backup connected permanently to the same network, accessible with the same administrator credentials, can be encrypted alongside production data.
Secondly, the firm had documented its key systems and dependencies. This meant the recovery team could identify what mattered most: secure identity services, core networking, client data, finance and communications. Without this information, businesses often lose valuable hours debating which server or application should be restored first.
Finally, leadership understood that recovery was a business decision as well as a technical one. A director was appointed to coordinate internal communication, client updates and commercial decisions. IT specialists could focus on containment and restoration rather than answering every individual query.
The first 24 hours of the ransomware recovery case study
The recovery team started by disconnecting affected devices from the network and reviewing sign-in activity. Compromised accounts were disabled, passwords were reset and multi-factor authentication was enforced where it had not already been in place. Remote access tools and administrator accounts received particular scrutiny.
At the same time, they checked whether the cloud services, backups and satellite office had been affected. This is a crucial distinction. Ransomware is not always limited to the files that display a ransom note. Attackers may attempt to access cloud storage, mailbox data, backup platforms and other systems before or during encryption.
The firm notified its cyber insurance provider and sought legal and specialist incident response advice. Whether an organisation must report an incident to the Information Commissioner’s Office depends on the nature of the data involved, the likelihood of risk to individuals and the facts established during the investigation. It should not be treated as an automatic administrative step, nor should it be ignored.
Staff were given a simple, consistent message: do not reconnect devices, do not use personal workarounds to send client data, and direct external queries to the nominated contact. Clear communication reduced confusion at a point when uncertainty could easily have created further risk.
Restoring services in the right order
The organisation did not attempt to restore every file and system at once. Instead, the team rebuilt a clean, controlled environment and restored services in priority order.
Identity and access came first. Before recovering data, the business needed confidence that the people signing in were genuine and that privileged accounts were secure. Network equipment and endpoint protection were then checked and reconfigured where necessary.
Next came communication and essential business applications. Staff could continue handling urgent client requests using approved cloud services while the local file environment was rebuilt. This was not perfect, but it kept critical work moving and avoided a complete shutdown.
The protected backups were scanned, tested and restored into the clean environment. The team selected recovery points from before the attacker’s activity, rather than simply choosing the latest available backup. Restoring the newest backup can reintroduce malicious tools or altered files if the compromise began earlier than expected.
Client files were recovered in stages, beginning with live matters and finance records. Department managers helped validate that data was complete and usable. Technical recovery is not finished when a server starts. The people who use the systems must be able to confirm that documents, permissions and workflows function as expected.
By the second working day, the firm had restored its core services and most staff were operating normally. A small amount of historical data required additional work, and a handful of devices had to be rebuilt entirely. Crucially, the firm did not pay the ransom. That decision depends on circumstances, legal advice and specialist guidance, but payment provides no guarantee that data will be returned or that stolen information will not be misused.
The gaps the incident exposed
The recovery succeeded, yet the attack revealed weaknesses that needed addressing. The initial account compromise showed that passwords alone were not sufficient protection. Multi-factor authentication became mandatory across email, remote access and administrator accounts.
The business also tightened its approach to privileged access. Administrator permissions were reduced, separate accounts were used for administrative work and access was reviewed more regularly. Limiting permissions does not prevent every attack, but it can reduce how far an intruder can travel through a network.
Endpoint protection was improved, alongside central monitoring and alerting. The goal was not to create unnecessary noise for staff, but to spot unusual sign-ins, mass file changes and suspicious activity sooner. Early detection can turn a major recovery exercise into a contained security incident.
Backup arrangements were reviewed as well. The organisation retained immutable or otherwise protected copies, set clear recovery objectives and introduced scheduled restore testing. This last point is often overlooked. A backup report saying “successful” is reassuring, but only a test restoration proves that the data is available, complete and usable within an acceptable timeframe.
Staff awareness also changed. The firm introduced short, practical training focused on suspicious sign-in prompts, unexpected attachments, password security and reporting concerns quickly. Training should not blame employees. It should make it easier for people to recognise risk and ask for help before a small issue becomes a business-wide incident.
What leaders should take from this case study
Ransomware resilience is not a single product or a once-a-year compliance exercise. It is the combination of secure identities, protected backups, maintained systems, sensible user access, clear procedures and expert support when pressure is high.
Every organisation’s recovery plan will differ. A school may need to prioritise safeguarding records, teaching platforms and communications with parents. A professional firm may place client records, financial applications and regulatory obligations first. A business with multiple sites may need to consider how each location continues operating if central services are unavailable.
The useful question is not simply, “Do we have backups?” It is, “If our systems were unavailable tomorrow morning, how would we operate, who would make decisions, and how quickly could we restore trusted data?”
A recovery plan should answer those questions in plain English, be tested before an emergency and reflect the way your organisation actually works. Elmdale IT Services helps organisations build that level of preparedness through tailored cyber security, backup, disaster recovery and managed IT support.
The best time to test whether recovery will work is when your staff can do so calmly, with expert guidance and without a ransom message on the screen.