A ransomware message at 7.20am is not the moment to discover whether last night’s backup completed, whether anyone can access it, or who has authority to take systems offline. For a growing manufacturer, that was the reality behind this disaster recovery case-study. Production planning, stock records and customer communications were all at risk. The immediate concern was not the technical name of the attack. It was whether the business could continue trading.
The organisation in this example is representative of many established UK firms: around 80 users, a mix of on-site and cloud systems, a small internal management team, and no dedicated in-house IT department. Its experience shows why disaster recovery is not simply an insurance policy for servers. It is an operational plan for protecting revenue, customer confidence and the ability to make decisions under pressure.
The incident: a normal morning became a business interruption
The first warning was a call from an employee who could not open a shared production file. Within minutes, other colleagues reported the same problem. Files had been renamed and a ransom note had appeared on a network share.
The business had several systems that mattered in different ways. Its cloud email was still available, but the on-site file server held production schedules, technical drawings and commercial documentation. A line-of-business application used for stock control and order processing relied on a local database. Remote access had to be disabled quickly to prevent further spread, leaving some staff unable to work from home.
The initial decision was straightforward but difficult: isolate affected systems before trying to fix them. Keeping a compromised server online to preserve convenience can turn a contained incident into a wider outage. The managing director, operations lead and IT support team agreed to pause access to the affected environment, communicate clearly with staff, and establish a single point of contact for updates.
That early discipline mattered. People had a route to report issues, managers could prioritise work, and the technical response was not interrupted by conflicting requests.
Why the existing backup arrangement was not enough
The organisation did have backups. That is where many businesses stop the conversation, but backup and recovery are not the same thing.
Some data was copied overnight to a local device. A separate cloud copy existed for key files, but no recent full recovery test had been completed. Documentation explained what was being backed up, yet it did not set out the order in which systems should be restored, who owned each decision, or how staff would work while services were unavailable.
The business had to answer practical questions quickly. Which files were essential for today’s production? Could the stock system be recovered without restoring the whole server? Was the cleanest available backup genuinely free from compromise? How would customer orders be handled if the normal workflow remained unavailable?
A recovery plan turns those questions from a stressful debate into agreed actions. It also exposes trade-offs before an incident occurs. Restoring every system to the last minute is costly and, for some applications, unnecessary. Restoring a finance or order-processing database from four hours earlier may be acceptable if the team knows how to reconcile the missing transactions. Losing two days of drawings or production data may not be.
The recovery response: contain, verify, restore
The first phase focused on containment and evidence. Affected devices were isolated, remote access was reviewed, and privileged account credentials were reset. The team avoided the temptation to reconnect systems simply because they appeared to be working. A device that looks normal can still present a route back into the network.
Next came recovery validation. Rather than overwrite the affected server immediately, the technical team restored selected data into a separate environment. This allowed them to confirm the backup was usable, check dates and completeness, and scan for indicators of compromise before it returned to live use.
The recovery sequence followed business priorities rather than the order of the technology estate:
- communication channels and secure administrative access;
- production schedules, drawings and shared operational files;
- stock control and order processing;
- standard user devices and non-critical applications.
This distinction reduced wasted time. There was no benefit in restoring every desktop before the operations team could see the production schedule. Equally, there was little value in bringing back the stock application before the underlying database and access controls had been checked.
Within the first working day, managers had access to the latest verified production information and could coordinate work through a controlled temporary process. The business was not fully back to normal, but it had moved from uncertainty to managed disruption. Core systems were restored over the following 36 hours, with priority users brought back in stages once their devices had been checked and secured.
The commercial impact: downtime is wider than lost files
The direct cost of a cyber incident is often measured in hours of IT work. That misses the bigger picture. During the outage, the organisation had to reschedule production tasks, answer customers without its usual order history, and make careful decisions about deadlines. Senior people who should have been focused on customers and operations were managing an incident instead.
There were also reputational considerations. The business needed a clear, honest message for customers where delivery dates could be affected, without speculating about causes or making commitments it could not keep. Internally, staff needed reassurance that reporting a suspicious email or unusual behaviour was the right thing to do, not something that would attract blame.
A well-managed recovery protects confidence because it provides a credible rhythm of communication. People can accept disruption more readily when they know what is happening, what they should do next, and when the next update will arrive.
What changed after the recovery
The incident did not lead to a decision to buy every available security product. It led to a more useful outcome: a recovery approach based on what the business genuinely needed to keep operating.
First, the company defined recovery time objectives and recovery point objectives for its critical services. A recovery time objective sets how long a service can be unavailable. A recovery point objective sets how much data loss is acceptable. These are commercial decisions as much as technical ones. A system required within four hours needs different protection and investment from one that can wait until the next working day.
Second, backups were separated from the production environment and protected against deletion or alteration. More than one copy was retained, including an off-site copy, and access was restricted. Backup success notifications remained useful, but regular restore testing became the measure that mattered.
Third, the business documented a concise incident playbook. It named decision-makers, technical contacts, communication responsibilities, key suppliers and system priorities. It also included practical alternatives, such as how orders could be recorded safely if the main application was unavailable.
Finally, the company introduced planned recovery exercises. These did not need to be disruptive full-scale events every month. A focused quarterly test, such as restoring a critical folder or database into an isolated environment, gave the team confidence that backups were usable. An annual scenario session tested management decisions and communication routes.
A disaster recovery case-study is only useful if it changes behaviour
The lesson is not that every business needs identical infrastructure. A professional services firm may prioritise client documents, email and remote working. A manufacturer may place production schedules, technical files and stock systems first. A legal practice may have stringent requirements around matter data and confidentiality. The correct recovery design depends on the cost of downtime, the data involved and the commitments made to customers.
What should be consistent is the process. Identify the systems that keep the business moving. Agree the acceptable outage and data-loss limits with the people who run the business. Protect backups from the incident they are intended to solve. Test restores, document responsibilities, and make sure staff know how to escalate a concern.
For organisations without an internal IT team, a managed technology partner can bring structure to that work: assessing dependencies, setting realistic recovery objectives, managing backup monitoring and supporting the business through tests as well as incidents. The value is not merely having someone to call when something fails. It is making fewer high-pressure decisions for the first time during an outage.
The best time to test whether your recovery plan works is a calm Tuesday afternoon, not the morning every shared file becomes inaccessible.
The Blowfish Technology team. Managed IT, cloud services, software development and connectivity for North West businesses since 1999.