At 08:17 on a Tuesday, a professional services firm discovered that shared files were inaccessible, several staff had been signed out of Microsoft 365, and a ransom message had appeared on two servers. This ransomware recovery case study follows the first 36 hours of an anonymised, representative incident and shows what separates a controlled recovery from a costly, prolonged outage.

The business had 52 staff across two offices. Its systems held client records, finance documents, case files and correspondence. That meant the immediate problem was not simply encrypted data. It was the possibility that confidential information had been copied, the risk of reinfection, and the commercial pressure of staff unable to work.

The first hour: stop the spread, not the evidence

The firm’s first sensible decision was not to start restoring files. It was to contain the incident. The affected servers were isolated from the network, remote access was disabled, and potentially compromised user accounts were suspended. Staff were asked not to restart devices, delete files or forward suspicious messages.

That may feel disruptive, particularly when clients are waiting for a response. However, allowing potentially infected equipment to remain connected can give ransomware more time to encrypt backup locations, spread through shared folders or steal additional data. Equally, switching everything off without a plan can remove useful evidence about what happened and when.

The IT team recorded the initial symptoms, preserved logs where possible and established a clean communication route away from the affected environment. Senior management, the firm’s insurer and relevant advisers were briefed early. For organisations handling personal or legally sensitive data, this stage also starts the assessment of whether a report to the Information Commissioner’s Office may be required.

What the investigation found

The attacker had gained access through a compromised user account that did not have multi-factor authentication enabled. From there, they used legitimate remote tools and elevated privileges before deploying ransomware outside office hours.

This is a common and uncomfortable pattern. Ransomware is rarely just a file-encryption event. Criminal groups often spend time inside a network, identify valuable systems and seek out backups before making themselves known. Paying a ransom does not prove that stolen information has been deleted, that every system will decrypt correctly, or that the business will be safe from a further demand.

The investigation established that the firm’s main on-site file server, one application server and a number of user profiles were affected. Crucially, its backup design included protected copies held separately from the main network. The most recent clean restore point was from 22:00 the previous evening.

That created a manageable recovery point objective: the firm was likely to lose less than one working day of amended documents, rather than weeks or months of data.

The ransomware recovery case study: rebuilding safely

Recovery began in a separate, clean environment. The team did not reconnect old servers and hope that anti-virus software would make them safe. Core systems were rebuilt from known-good installation media, fully patched, and configured with new administrator credentials.

The protected backup was then scanned and tested before restoration. This validation matters. A backup can exist and still be unsuitable if it contains malicious files, is incomplete, cannot be restored within the required timeframe, or depends on a compromised account.

By mid-afternoon, priority services were available to a small group of users. This included email access through clean Microsoft 365 accounts, a secure location for urgent documents and access to the most time-sensitive client records. The firm did not attempt to return every user to normal at once. It restored the services that kept client commitments moving first.

During the evening, the IT team restored the file service and key application data, then checked permissions, document availability and audit logs with department heads. Staff changed passwords from clean devices, multi-factor authentication was enabled across all accounts, and old remote access methods were removed.

At 08:30 the following morning, most staff could work from restored systems. A small number of non-essential archives and individual workstation profiles were still being rebuilt, but client-facing work had resumed. By the end of the second day, the firm had returned to normal operations with a clear record of what had been restored, what data had been re-created manually and what follow-up security work remained.

The 36-hour outcome was not luck. It was the result of decisions made before the incident: maintaining separate backup copies, monitoring systems, documenting core services and knowing who had authority to make operational decisions.

Why the recovery was measured in hours, not weeks

The difference between a quick recovery and a long outage is usually preparation, not the brand of ransomware involved. The firm had several advantages, though none made the incident painless.

First, backups were designed for recovery rather than treated as a compliance exercise. There were multiple copies, including a protected copy outside the everyday network. Backups were monitored, and the business knew where its critical data lived. UK-hosted backup and disaster recovery services can be particularly useful where data location, resilience and support access matter to the organisation.

Second, the business had a workable order of priority. Email, client records, line-of-business applications, shared files and communications were not all equally urgent. Senior staff could decide which teams needed access first, rather than asking technicians to guess under pressure.

Third, the recovery was paired with security remediation. Restoring data without closing the original route in is a false economy. Password resets, multi-factor authentication, privilege reviews, patching and endpoint checks were all part of getting back to work.

There is a trade-off here. More frequent backups reduce potential data loss but require more storage, management and testing. Highly locked-down access controls can inconvenience users if introduced poorly. The answer is not to accept weaker security. It is to design controls around how people actually work, then support them properly.

The weaknesses the incident exposed

Even a successful recovery highlights gaps. In this case, the firm had assumed that strong passwords were enough for remote access. They were not. Multi-factor authentication was subsequently made mandatory, with conditional access controls to reduce risky sign-ins.

The business also found that its incident plan was too technical. It explained how to restore systems but gave limited guidance on who should update clients, speak to insurers, approve emergency spending or decide whether offices should remain open. A practical incident plan needs business owners, operations and communications roles as well as IT tasks.

Finally, the team identified that several older shared folders were no longer required. Removing stale data reduced both future storage costs and the amount of information exposed during any later security incident. Good cyber security is partly about protecting systems, but it is also about holding less unnecessary data in the first place.

What SMEs should test before an attack

A ransomware recovery plan should answer a few uncomfortable questions clearly. Can you restore a critical server into a clean environment? How long will it take in reality? Is there a backup copy that a compromised administrator cannot delete? Which applications must be back first, and who can make that decision at 7am on a weekend?

Testing does not have to mean taking the business offline. A planned restore test can validate a sample of files, a virtual server or a key application database. The important part is proving that the backup is usable and recording what was learned. Recovery time objectives and recovery point objectives should be agreed in business terms: how long the organisation can operate without a service, and how much recent data it can afford to lose.

For firms without an internal IT department, this is where a managed provider can add real value. The right support partner should know your systems, provide direct technical advice during an incident and be able to explain the recovery plan without hiding behind sales language. Keyhole IT Solutions helps UK SMEs bring backup, monitoring, Microsoft 365 security and practical disaster recovery planning into one accountable service.

A ransomware incident is never a good test of a business. But a rehearsed recovery plan gives you choices when time, client trust and cash flow are all under pressure. The useful question to ask this week is simple: if your main server failed tonight, what would be working by tomorrow morning?