At 8:15 on a Monday morning, staff at a growing NSW wholesale business could not open customer orders, invoices or job files. File names had changed, a ransom note appeared on shared drives, and the office manager was fielding calls from employees who could no longer work. This ransomware recovery example shows what a controlled response can look like when a business has the right support, backups and decisions in place.
The business in this scenario is fictional, but the situation is representative of what many small and medium-sized organisations face. The company had 45 staff, a mix of office and warehouse workers, Microsoft 365, a cloud accounting platform and a local file server that held operational documents. It had cybersecurity controls and backups, but an employee’s credentials had been compromised after a convincing phishing email.
The ransomware recovery example
The first sign was not the ransom note. It was an alert from endpoint security software showing unusual file-encryption activity on a staff member’s computer shortly after 7:00 am. The monitoring system isolated that computer from the network automatically. This limited the attacker’s ability to spread further, but several shared folders had already been affected.
By the time staff arrived, the business had a real operational problem. Warehouse picking slips could not be printed, the accounts team could not access current customer records, and a manager worried that the attacker may have accessed confidential information before encrypting files.
The goal was not simply to get files back quickly. The goal was to restore operations safely, understand what had happened, and avoid putting the attacker straight back into a rebuilt environment.
The first hour: stop the spread and keep control
A ransomware incident creates pressure to act immediately. Some actions are useful; others can destroy evidence or make recovery harder. In this case, the IT response began by disconnecting affected devices and restricting access to shared storage. The team did not start deleting files, rebooting every computer or communicating with the attacker.
They then confirmed which systems were affected, which accounts had recently logged in, and whether the infection had reached cloud services, backup platforms or other sites. Remote access services were temporarily disabled while administrator accounts and privileged passwords were secured.
The business owner was given a plain-English briefing: what was known, what was still being checked, which functions were unavailable, and the next expected update time. That communication mattered. When people have no information, they often take matters into their own hands by reconnecting devices, forwarding suspicious emails or using personal accounts to keep work moving.
The company also contacted its cyber insurance provider and sought legal advice about notification obligations. Whether a business needs to notify customers, regulators or other parties depends on the information involved and the circumstances. If personal information may have been accessed, organisations should assess their obligations under the Notifiable Data Breaches scheme rather than assuming encrypted data alone tells the full story.
Why paying the ransom was not the recovery plan
The ransom demand was visible on the affected server. Paying it was discussed, as it often is when a business is losing money by the hour. But payment does not guarantee a working decryption key, complete data recovery or deletion of any copied information. It can also expose the business to further demands.
In this ransomware recovery example, the business had a better option: verified backups that were separated from day-to-day systems. That distinction is critical. A backup that is online, accessible with the same administrator account, and never tested may be encrypted or unusable when it is needed most.
The recovery team checked backup logs, reviewed the most recent clean restore point and performed a controlled test restore in an isolated environment. The previous evening’s backup was intact, and an earlier copy was also available. The business would lose some recent document changes, but not weeks or months of data.
Restoring safely, not just quickly
Restoration started only after the team had contained the incident and rebuilt the affected server from a known-clean configuration. Restoring files directly onto an infected system can reintroduce malware or leave a back door in place.
The process was staged according to business impact. First, the team restored the folders needed for warehouse operations and customer orders. Next came finance documents, project records and departmental shared drives. Staff were gradually returned to access as each area was checked.
At the same time, the team reset passwords for affected users, enforced multi-factor authentication where it was missing, reviewed mailbox rules and removed unauthorised access. This mattered because ransomware is often the final stage of an attack, not the beginning. An attacker may spend days or weeks using stolen credentials, looking for valuable data and weakening defences before launching encryption.
Microsoft 365 was reviewed separately from the local server. The team checked audit activity, mailbox forwarding rules, administrator roles, SharePoint and OneDrive changes, and sign-in locations. Cloud platforms reduce some risks, but they do not remove the need for security monitoring, strong identity controls and independent backup planning.
By late on the second day, the warehouse and customer service teams were operating normally. Finance had access to restored records, although staff needed to recreate a small number of transactions from emails and paper notes. On day three, the business completed a detailed check of its systems and formally closed the immediate recovery phase.
There was downtime, cost and stress. But the incident did not become an existential event because the business had a practical recovery path and people who could coordinate it.
What made the difference
The technology mattered, but the outcome was not down to a single product. It came from several decisions made before the incident.
First, the business had monitored endpoint protection that identified suspicious behaviour and isolated a device quickly. Without that early containment, more servers and computers may have been encrypted.
Second, its backup approach included protected copies and regular checks. The often-cited 3-2-1 principle is a useful starting point: keep multiple copies of important data, use different storage types, and retain a copy away from the main environment. For many businesses, an immutable or otherwise protected backup adds another layer of assurance. The exact design depends on the systems you use, how quickly you need to recover, and how much data loss your business can tolerate.
Third, the company had clear responsibilities. The office manager knew who to call, the leadership team knew who could approve major decisions, and employees received straightforward instructions. A recovery plan that sits unread in a folder is not enough. People need to know how to activate it under pressure.
Finally, the business accepted that recovery is not only an IT task. It affects customer service, payroll, contracts, reputation and staff wellbeing. The best response brings technical, operational and leadership decisions together.
Turn this example into a plan for your business
A useful question is not, “Could ransomware happen to us?” It is, “What would stop working first, and how long could we operate without it?” For a construction business, that may be plans, estimating software and site communications. For a professional services firm, it may be client files, email and practice management systems. For a manufacturer, it could be production systems and inventory data.
Start by identifying the systems that keep revenue flowing and the information you cannot afford to lose. Then confirm how those systems are backed up, where the backups are held, who can access them, and when they were last restored successfully. A backup report is helpful, but a test restore provides far stronger evidence that recovery will work.
Your incident response plan should also include current contact details for IT support, cyber insurance, legal advisers and key decision-makers. Set out how staff should report suspicious activity, who communicates with customers, and how you will keep operating if email or phones are affected.
For great Aussie businesses across the Central Coast, Newcastle and Sydney, this preparation does not need to be overly complicated. It does need to be realistic, tested and maintained as your systems change. A trusted IT partner such as Innov8 IT can help assess the gaps before an incident forces the issue.
The best time to test a recovery plan is when nobody is staring at a ransom note. Schedule a backup restore test, walk through your response with the people who would be involved, and fix the weak points while there is still time to choose the pace.
