At 08:17 on a Monday, a finance administrator opened a convincing invoice attachment. By 09:02, shared folders were inaccessible, production paperwork could not be printed and a message demanding cryptocurrency appeared on several screens. This ransomware case study follows a realistic, anonymised UK mid-market business and shows why recovery depends on decisions made well before an attack starts.
The organisation had around 85 staff across an office, warehouse and small manufacturing operation. Like many growing businesses, it relied on Microsoft 365, a line-of-business application hosted on a server, shared files and remote access for a handful of staff. IT had generally worked well, but security improvements had been handled around daily operational pressures rather than through a clear, tested plan.
The outcome was positive: the business restored priority services without paying the ransom. It still lost valuable trading time. More importantly, it learned that ransomware resilience is not one product or one policy. It is a combination of sensible technical controls, prepared people and an incident response process that works under pressure.
The ransomware case study: what happened
The initial email appeared to come from a regular supplier. Its branding was credible, the sender name looked familiar and the attachment was described as an amended delivery charge. The recipient opened the file and was asked to sign in to view it. Those credentials gave the attacker a foothold.
Over the next 45 minutes, the attacker used the compromised account to identify accessible systems and shared folders. They attempted to move laterally through the network, then deployed ransomware to encrypt files on the main file server and several endpoints. The attack was detected when staff reported that documents would not open and the IT provider saw unusual authentication activity.
There was no single dramatic failure. Several ordinary gaps combined: multi-factor authentication was not enabled for every account, local administrator rights were broader than necessary, a legacy remote access route remained available, and backup success had been checked but full restoration had not recently been tested. None of these issues is unusual in a busy business. Together, they made an otherwise containable incident more disruptive.
The first four hours mattered most
The immediate priority was containment, not investigation. The incident team disconnected affected devices, disabled the compromised account, blocked remote access routes and separated key systems from the wider network. Staff were asked not to restart machines, connect personal devices or attempt to move files themselves.
That can feel counterintuitive. When operations are under pressure, people naturally want to get back to work quickly. However, reconnecting a device before it is checked can give ransomware another route into restored systems. Clear communication prevented well-meaning actions from extending the outage.
The business also took practical steps to keep trading. Customer service teams used agreed manual processes for urgent orders. The warehouse worked from a controlled list of priority despatches. Finance paused payment runs until it could verify that bank details had not been altered. Directors were given timed updates based on known facts rather than speculation.
This is where an incident response plan earns its place. A useful plan does not need to be a large technical document. It should make clear who can make decisions, who contacts the IT partner and insurer, what services must be restored first, and how colleagues, customers and suppliers will be updated. In this case, those decisions had to be agreed during the incident because they had not been fully documented beforehand.
Why paying the ransom was not the answer
The ransom note set a deadline and threatened to publish stolen data. That pressure is designed to make payment seem like the fastest route back to normal. It rarely provides certainty.
Paying does not guarantee a working decryption key, complete data recovery or deletion of copied information. It may also create legal, insurance and reputational complications. Whether data has been exfiltrated, the nature of the business, the quality of backups and advice from insurers and specialist responders will all influence the response.
In this case, the organisation did not pay. Its backups were isolated from the live environment, and forensic checks found no clear evidence that the attacker had accessed the most sensitive business systems. The business engaged its insurer and followed appropriate reporting and legal advice. The decision was not based on optimism. It was based on evidence, available recovery options and a disciplined assessment of risk.
Recovery was a business exercise, not just an IT task
The team first rebuilt the identity environment and security controls rather than restoring every server immediately. Passwords were reset, multi-factor authentication was enforced, privileged access was reviewed and affected endpoints were rebuilt from known-good images.
Next came the services that allowed the organisation to operate: email, telephone access, the core business application and priority shared files. Less critical archived material followed later. This order reduced downtime where it mattered most, even though a complete return to normal took several days.
A backup is only useful if it can be recovered within the time your business can tolerate. The company had backup copies, but the restoration process exposed two uncomfortable facts. First, the recovery sequence had not been documented in enough detail. Second, some large file sets took longer to restore than expected because bandwidth and storage performance had not been considered in the recovery plan.
That distinction matters. Recovery point objective, or how much data you can afford to lose, is different from recovery time objective, or how long a service can be unavailable. A business that backs up every night may accept up to a day’s data loss, but it may not be able to wait two days for its systems to return. The right design depends on the cost of interruption, not on a generic backup setting.
What the business changed afterwards
The post-incident review was deliberately blameless. The employee who opened the attachment had made a mistake, but the organisation recognised that security cannot depend on every person spotting every sophisticated email. The aim was to reduce the chance of recurrence and limit the damage if another attempt succeeded.
The changes were practical. Multi-factor authentication was rolled out across all relevant services, with conditional access rules for higher-risk sign-ins. Endpoint protection and monitoring were improved, and devices were brought under consistent patching and management. Administrative rights were reduced, while separate accounts were introduced for tasks that genuinely required them.
The network was also segmented so that a compromised user device could not freely reach every system. Remote access was simplified and secured. Backups were reviewed against a 3-2-1 approach: multiple copies of important data, held on different media, with one copy kept separate from the main environment. Crucially, the business scheduled restoration tests, not just backup checks.
Staff training changed too. Instead of an annual compliance presentation, the company introduced short, regular awareness sessions based on the emails and risks people actually encounter. Colleagues learned how to report a suspicious message quickly and without embarrassment. That reporting culture gives technical teams the opportunity to act before a single click becomes a business-wide event.
Questions every leadership team should ask
A ransomware discussion is often treated as an IT matter until systems are unavailable. It is better handled as an operational resilience issue owned by leadership and supported by technical specialists. Four questions can reveal where attention is needed:
- If email, files or core applications were unavailable tomorrow, which functions must be restored first?
- Can you prove that backups are isolated, complete and recoverable within an acceptable timeframe?
- Are multi-factor authentication, patching and access controls applied consistently rather than only to selected systems?
- Does every colleague know how to report a suspicious email or device issue, and who leads the response?
The answers may differ for an engineering firm, a legal practice or a financial services business. A firm handling time-sensitive client matters may prioritise document access and communications. A manufacturer may need production systems, stock data and connectivity restored first. There is no one-size-fits-all recovery plan, but every plan needs an agreed order of priorities.
Turning concern into a workable plan
The strongest next step is a focused review of the systems your business cannot operate without. Map where their data sits, who can access them, how they are backed up and what happens if a device, account or site is compromised. Then test the answer with the people who would actually manage the disruption, including operations, finance and customer-facing teams.
A managed IT partner can provide technical monitoring, security controls and recovery support, but accountability for business priorities should remain shared. At Blowfish Technology, that means discussing technology in terms of downtime, risk and growth plans, not just licences and alerts.
Ransomware may begin with one click, but it becomes a crisis when small weaknesses are allowed to accumulate. A clear plan, tested recovery and straightforward support give your team a far better chance of responding calmly when it matters.
The Blowfish Technology team. Managed IT, cloud services, software development and connectivity for North West businesses since 1999.