At 7.18am on a Monday, staff at a growing Irish professional services firm could not open shared documents, access line-of-business applications or connect reliably to their cloud files. A message on several servers demanded payment in cryptocurrency. This ransomware recovery case study examines what happened next: not as a dramatic technical rescue, but as the operational test it was for a business with 70 staff, two offices and little tolerance for downtime.
The organisation is anonymised, and some details have been adjusted to protect confidentiality. The lessons, however, are representative of the decisions Irish businesses face when ransomware interrupts normal operations.
The incident: a business problem before it was an IT problem
The initial signs were confusing. A member of staff reported that project folders had changed names. The finance team then found that a core application was unavailable. Within minutes, file servers were displaying a ransom note and users were being logged out of key services.
The immediate risk was not simply lost data. The firm had client deadlines that day, payroll activity due later in the week and teams working across two sites. If systems remained unavailable, staff would be unable to serve clients, issue invoices or access the information needed to make decisions.
The business had several safeguards in place. Microsoft 365 accounts used multi-factor authentication, endpoint protection was deployed and backups ran to a separate backup platform. However, an attacker had gained access through a compromised user account and used that access to move laterally through parts of the network. The backup platform was not directly accessible from the affected servers, which proved decisive.
Ransomware recovery case study: the first two hours
The first priority was containment. Attempting to restart affected machines or immediately restore files can make an incident worse, particularly if the attacker still has access. The response team isolated affected servers and endpoints from the network, disabled potentially compromised accounts and preserved relevant logs for investigation.
That created a difficult but necessary trade-off. Isolating systems stopped further spread, but it also prevented some staff from working. The alternative – leaving systems connected in the hope of maintaining productivity – risked encrypting more data and compromising recovery points.
At the same time, management needed clear information in plain English. The key questions were practical:
- Which systems are affected?
- Is customer or employee data at risk?
- Can staff work safely in another way?
- What will be available today, tomorrow and later this week?
A short incident call was established with the managing director, operations lead, finance representative and IT response team. This prevented conflicting messages and ensured decisions could be made quickly. Staff were asked not to reconnect devices, open unusual emails or use personal storage services to move business files.
The team also contacted the organisation’s cyber insurance provider and sought appropriate legal and data protection advice. Whether a breach must be reported depends on what information was accessed, the likelihood of harm and the evidence available. It is not sensible to make assumptions in the first few hours.
Establishing a clean route back
Recovery does not begin with restoring everything. It begins with confirming what is safe to restore.
The technical investigation identified the likely point of entry, reviewed account activity and checked whether administrative credentials had been exposed. Passwords were reset, multi-factor authentication sessions were revoked and privileged access was restricted. A clean management workstation was used to administer recovery, rather than relying on a device that might have been compromised.
Backups were then assessed against three questions: were they available, were they recent enough, and were they clean? The team found an immutable backup copy from the previous evening, alongside earlier restore points. A sample of data was restored into an isolated environment and scanned before the full recovery began.
This validation stage can feel slow when staff are waiting to work. It is still essential. Restoring infected files or rebuilding servers with compromised credentials simply creates a second incident. A recovery time objective only has value if the recovered environment can be trusted.
The firm chose not to pay the ransom. Paying does not guarantee a working decryption key, does not prove that stolen data has been deleted and can leave an organisation exposed to further demands. There are exceptional cases where organisations face severe consequences and seek specialist advice, but ransom payment should never be treated as a recovery plan.
Restoring the services that mattered most
Rather than attempting a full return to normal in one step, the recovery was sequenced around business priorities. Email and Microsoft 365 collaboration were confirmed as safe and made available first, allowing management to communicate with staff and clients. The core line-of-business application followed, then shared files, print services and less critical internal systems.
This order was agreed with department leads, not decided in isolation by IT. For example, the finance team needed access to a limited set of records before it needed older archive folders. Client-facing teams needed current project documents before legacy material. Those choices reduced the time to meaningful productivity.
By late afternoon on the first day, staff could communicate securely and access the most urgent applications. The second day focused on rebuilding affected servers, restoring validated data and checking that endpoint protection, patching and access controls were correctly applied before users reconnected.
The final stage was not glamorous, but it mattered. Users confirmed that their applications worked as expected, permissions were checked, shared folders were tested and business owners signed off critical processes. Technology can appear available while a missing permission, printer queue or integration still stops a team doing its work.
What made the difference
The firm was not protected because it had a single security product. It recovered because several practical controls worked together: separated backups, usable restore points, multi-factor authentication, clear escalation routes and people who knew who could make decisions.
The biggest gap was visibility. The business had monitoring, but its incident procedures had not been exercised as a full management scenario. Technical teams knew how to restore systems; senior leaders had not previously rehearsed how they would prioritise services, communicate with customers and keep staff informed during a sustained outage.
That distinction matters. Backup and disaster recovery are often discussed as technical purchases. In reality, they are continuity arrangements. The questions that matter are commercial: how much data can we afford to lose, how long can each service be unavailable, and who decides what comes back first?
Improvements made after recovery
Once operations stabilised, the organisation avoided treating the incident as finished. A structured review led to stronger identity controls, tighter administrative access and improved monitoring of unusual account activity. The backup programme was also expanded to include more frequent recovery testing and a documented check that recovery data remained isolated from production systems.
The business introduced a simple incident playbook for managers. It set out contact roles, decision authority, supplier details, client communication templates and a prioritised list of systems. This was deliberately written for people who are not cybersecurity specialists. During an incident, a useful plan is one that can be followed under pressure.
It also scheduled recovery exercises. A test should include more than restoring a file. It should test whether the organisation can recover a server, validate an application, reconnect users and operate core processes within the agreed timeframe. The answer may expose a need for additional backup capacity, better documentation or a different recovery design.
For organisations with hybrid staff or multiple locations, it is worth testing how people would work if the office network were unavailable. Cloud applications can help, but only where identity, devices and data access have been properly secured. A cloud service does not remove the need for recovery planning.
Questions every Irish business should ask now
A ransomware incident is a poor time to discover that backups have never been restored, that a former employee still has privileged access or that the only person who understands a critical system is on holiday. Management should be able to answer where backups are held, how quickly systems can be restored and whether the recovery process has been tested recently.
They should also understand the difference between a backup and a complete recovery capability. A backup may contain the data, but recovery requires clean infrastructure, secure accounts, sufficient storage, documented configuration and someone accountable for bringing services back in the right order.
For businesses without a large internal IT team, an experienced managed service partner can provide the monitoring, maintenance and recovery planning that is difficult to maintain alongside day-to-day operations. LANCAST helps organisations plan, implement and test the infrastructure controls that support business continuity, while providing practical guidance when priorities need to be made clear.
The most useful outcome from this case study is not a fear of ransomware. It is a decision to test recovery before the business is forced to rely on it. A planned morning spent restoring a critical service is far less costly than an unplanned week wondering whether it can be recovered at all.