A ransomware message on a shared drive is not just an IT problem. It can stop orders, lock staff out of email, interrupt EFTPOS, and leave customers wondering whether their information is safe. This guide to ransomware recovery sets out how a business should respond in the first hours, restore services without reintroducing the threat, and make the next incident far less disruptive.
The right response is deliberate, not improvised. Fast action matters, but so does preserving evidence, protecting unaffected systems, and making sound decisions about customers, insurers and regulators. The goal is not simply to get files back. It is to return the business to safe, dependable operation.
First, contain the attack without losing control
Ransomware often spreads through connected devices, shared folders, administrator accounts and cloud synchronisation tools. A device that appears to be the source may not be the only affected system. Treat the incident as wider than the first ransom note until investigation proves otherwise.
Immediately isolate suspected computers and servers from the network. Disconnect their network cable or disable Wi-Fi, but do not switch them off unless your incident response adviser directs you to. Memory, running processes and logs can help establish what happened. If a site is affected, consider temporarily separating it from other locations and restricting remote access until accounts and connections have been checked.
At the same time, protect the systems needed to run the response. This normally includes your backup platform, identity provider, domain administration, firewall management, email administration and payment environment. Change privileged passwords from a known-clean device, revoke active sessions where possible, and enforce multi-factor authentication. Do not use a potentially compromised laptop to reset credentials.
Your first-hour priorities are best kept simple:
- isolate affected devices and stop suspected spread;
- preserve evidence, including ransom notes, log files and screen photographs;
- secure privileged accounts, remote access and backups;
- notify the people who own incident response, cyber insurance and key operational decisions; and
- record every action, decision and timestamp.
A written incident log avoids confusion when several people are under pressure. It also supports insurance claims, forensic work and any notification obligations that may follow.
Establish what has happened before restoring
Ransomware recovery can fail when a business restores too soon. If the attacker still has access through a stolen account, unpatched remote service or compromised management tool, fresh systems can be encrypted again. Investigation and recovery therefore need to run together.
Start by answering a few practical questions. Which systems are encrypted? When was the earliest suspicious activity? Which accounts were used? Has data been copied before encryption? Are cloud drives, backup repositories or virtual servers affected? Is the attack confined to one location, or has it reached other sites and home workers?
Your managed security provider or incident response specialist should review endpoint alerts, firewall and VPN logs, identity sign-in records, email activity and server logs. They should also identify the ransomware family where possible. This can reveal known behaviours, such as data theft, attempts to disable backups or persistence mechanisms that survive a reboot.
Do not assume that encrypted files are the full impact. Modern ransomware groups commonly steal information first, then threaten publication to increase pressure. That changes the response from a service outage to a potential data breach. Legal, privacy, contractual and regulatory requirements depend on the information involved and the jurisdictions in which you operate. Seek appropriate advice early, rather than waiting until a deadline is close.
Should you pay the ransom?
Paying is a business, legal and risk decision, not a recovery plan. A payment does not guarantee a working decryption key, complete data return or deletion of stolen information. It may also encourage further demands. Some organisations face exceptional circumstances where safety, critical operations or the absence of viable backups affect the decision, but it should be taken with specialist legal, insurer and incident response advice.
We've got your back
Whether payment is considered or not, preserve all communications and do not allow a single employee to negotiate on behalf of the business. Keep decision-making centralised and documented.
A guide to ransomware recovery: restore in a safe order
The best recovery point is not necessarily the newest backup. It is the newest clean backup, taken before the attacker gained access or began tampering with systems. Backup dates alone cannot prove that. Review logs, scan backup copies where practical, and validate the proposed restore point against the incident timeline.
Restore into a controlled environment first. A clean network segment, separate recovery tenant or isolated virtual environment allows your team to test systems without reconnecting them to production. Rebuild compromised devices from trusted installation media or standard images rather than attempting to clean them in place. For servers, confirm operating system patches, endpoint protection, configuration baselines and administrative access before restoring business data.
Recovery order should reflect what keeps the business operating, not what is easiest to rebuild. For many SMEs, that means identity services and secure networking first, followed by core line-of-business applications, file services, communications and payment-related systems. A retailer may need tills, internet connectivity and payment processing ahead of a less urgent archive. A professional services firm may prioritise client management, email and secure document access.
Bring systems back in stages and test each stage with real users. Check that staff can sign in, applications can reach required services, permissions are correct and backups are running again. Monitor closely for unusual authentication attempts, new administrator accounts, unexpected scheduled tasks or outbound connections. A service that starts successfully is not automatically a service that is safe.
Communicate clearly during this period. Staff need plain instructions about which systems are available, how to work safely and where to report problems. Customers and suppliers need proportionate updates where service levels, deliveries, appointments or data may be affected. Be honest about what is known, avoid speculation, and give the next update time even if there is no major change.
Backups are only useful when recovery is proven
A backup strategy should withstand the same event that takes production systems offline. Copies stored only on a permanently connected network share may be encrypted alongside the files they are intended to protect. Cloud backup can improve resilience, but only if access controls, retention settings and deletion protection are correctly configured.
A practical approach uses separate backup copies, ideally with one copy isolated or immutable so it cannot be changed during its retention period. It also needs clear ownership. Someone must receive backup failure alerts, investigate them and confirm that critical systems are covered as the business changes.
Most importantly, test restores. Test a file restore, an application restore and a full recovery scenario at intervals that match the cost of downtime. Record how long each takes and what dependencies were missed. Recovery time objectives should be realistic: restoring several terabytes over a limited connection takes time, and a business with multiple sites may need a staged plan rather than an assumption that everything returns at once.
Reduce the chance of a repeat incident
The recovery process should lead to specific improvements, not a general promise to be more careful. Close the route the attacker used, whether that was a phishing email, weak password, exposed remote access tool, unpatched server or supplier account. Review who has administrator rights and remove access that is no longer required.
Layered protection matters because no single control catches every attack. Managed firewalls, endpoint monitoring, email security, multi-factor authentication, password management, patching and security awareness training each address different points in the attack path. For businesses handling card payments, keep payment systems appropriately separated from general office devices and maintain the controls required for the relevant payment environment.
This is also where a single accountable technology partner has value. Connectivity, network security, devices, cloud services and support affect one another during an incident. When they are managed in isolation, teams can spend valuable hours deciding whose fault it is. Vetta coordinates those layers, with 24/7 monitoring and human support focused on restoring safe operations rather than passing the problem between suppliers.
A ransomware incident is difficult, but it also exposes the gaps that routine operations can hide. Use the recovery to build a tested plan, cleaner access controls and backups you can trust. The result is not just faster restoration next time, but a business that is harder to interrupt in the first place.
