A ransomware message appearing on a shared drive, finance system or staff laptop can stop a business within minutes. A considered ransomware recovery guide gives your team a clearer path through those first high-pressure decisions: contain the threat, protect evidence, understand the impact and restore services without giving attackers a second opportunity.
For small and medium-sized organisations, recovery is not simply a matter of retrieving files. Email, Microsoft 365, cloud applications, mobile phones, WiFi, remote access and on-site devices may all be connected. The priority is to bring essential operations back in a controlled order while preserving the information needed to understand what happened.
The first hour: contain the incident
The first response should focus on limiting further damage, not getting every user back online straight away. Ransomware can spread through shared folders, compromised accounts, remote-access tools and poorly segmented networks. A rushed restart or an attempt to remove the ransom note may overwrite useful evidence.
Take these immediate actions:
- Disconnect affected computers and servers from the network and internet, including WiFi and network cables where practical.
- Disable suspected user accounts, remote access sessions and shared drives that may be involved in the attack.
- Tell staff not to open unexpected emails, attachments or links, and not to use affected systems until instructed.
- Record what has been seen, when it was discovered, which systems are affected and any messages left by the attackers.
Avoid switching off every affected device unless your incident-response specialist advises it. A live system can contain valuable evidence about the attacker’s activity. Equally, do not reconnect a device just to check whether it is working. Isolation needs to be deliberate and documented.
If you have outsourced IT support, cyber insurance or a specialist incident-response provider, contact them early. Your insurer may have notification requirements and may appoint specific advisers. In a serious incident, legal advice can also help establish whether personal or sensitive data may have been accessed and what reporting duties apply.
Ransomware recovery guide: assess before restoring
Once the spread is contained, establish the true scope. The visible encrypted files are only one part of the incident. Attackers may have obtained credentials, created new administrator accounts, copied data, disabled security software or retained a route back into the environment.
Your technical team should identify the likely entry point. Common causes include a convincing phishing email, an exposed remote desktop service, a reused password, an unpatched device or compromised supplier credentials. It is not always possible to know the full answer immediately, but understanding the likely route determines what must be cleaned before recovery starts.
Create a clear picture of affected services. Separate systems into three groups: confirmed affected, suspected affected and currently unaffected. Then identify the business impact. Payroll, customer service, finance, clinical or pupil information, production, communications and access control will not all have the same urgency. A school, for example, may need safeguarding-related systems prioritised; a multi-site business may need connectivity and telephony restored to keep customer-facing teams operational.
It is also essential to check whether data has been stolen as well as encrypted. Many ransomware groups now use this double-extortion approach, threatening to publish data if a payment is not made. Encryption can be recovered from a clean backup. Data disclosure needs a separate assessment of confidentiality, regulatory obligations and communications.
Verify backups are safe and usable
Backups are often the difference between a difficult recovery and a business-threatening outage, but only if they are clean, available and tested. Do not assume that a backup completed successfully simply because a dashboard says so. Ransomware can sit undetected for days or weeks before encryption begins, and connected backup storage may also be affected.
Start by identifying backups that pre-date the compromise. Keep them isolated until they have been checked. Your recovery plan should consider more than server files: cloud data, Microsoft 365 mailboxes, configuration settings, virtual machines, line-of-business applications, network device configurations and security logs may all be needed.
A practical test restore is more valuable than a theoretical recovery time objective. Can the data be restored to a clean environment? Does the application open? Are permissions intact? Can users access the information they need? These questions often reveal gaps that are invisible in a backup report.
The right backup design depends on the business, but a useful principle is to maintain multiple copies, with at least one copy separated from the production network. Immutable or offline copies add protection, although they need proper planning and management. Cloud platforms can improve availability, but they are not a substitute for deciding what data is backed up and how it will be recovered.
Rebuild cleanly, then restore in priority order
Do not restore files onto systems that may still be compromised. Rebuild affected devices from known-good images, apply security updates, remove unauthorised accounts and reset passwords. Privileged accounts, such as administrator and service accounts, deserve particular attention because attackers commonly use them to move across an environment.
Where possible, introduce multi-factor authentication before bringing remote access, email administration and cloud services back into normal use. Review conditional access, forwarding rules, external sharing and remote-management tools. These controls may feel like additional work during an outage, but skipping them can turn recovery into reinfection.
Restore services according to the agreed business priorities rather than convenience. Communications may come first if your team needs to speak with customers and suppliers. Core identity services and secure connectivity often need to be in place before applications can be safely returned. Finance, operational systems and file access can then follow in stages.
Bring back a small group of users first and monitor closely. Check endpoint security alerts, sign-in activity, network traffic and application behaviour before expanding access. This phased approach takes longer than switching everything on at once, but it reduces the chance of spreading a remaining threat across the rebuilt environment.
Should you pay the ransom?
There is no simple answer, and payment should never be treated as a recovery plan. Paying does not guarantee a working decryption tool, full data return or deletion of stolen information. It may also expose the organisation to further demands. Sanctions, insurance conditions and legal considerations can apply, so decisions should be made with specialist advice.
The stronger position is to recover from clean systems and verified backups. Where that is not immediately possible, senior leaders need a documented decision process that considers operational harm, available recovery options, legal advice, insurer guidance and law-enforcement reporting. Avoid negotiating directly without qualified support.
Communicate with purpose
Silence creates uncertainty, particularly when staff cannot access email, mobile phones or key systems. Give employees a short, factual instruction on what they should and should not do. Provide an alternative contact method where necessary, and make sure front-line teams know how to respond to customers without speculating about the cause or scale of the incident.
External communication should be proportionate to the facts. Customers may need to know about service disruption. Suppliers may need to pause integrations or check for suspicious messages from your domain. If personal data may have been compromised, your organisation may need to notify the relevant regulator and affected individuals within required timescales. Keep a record of decisions, evidence and communications throughout.
Turn the incident into a better recovery plan
When core services are stable, hold a structured review. This is not about assigning blame to the person who clicked a link or spotted the issue late. It is about finding the controls, processes and dependencies that allowed a single event to cause disruption.
Review patching, email protection, multi-factor authentication, privileged access, endpoint monitoring, network segmentation and backup testing. Consider operational questions too: did staff know who to call, were supplier responsibilities clear, and could leaders make decisions quickly with the information available? A written incident plan that has never been tested is only a starting point.
For organisations without a large internal IT team, a managed support partner can help connect these areas rather than treating them as separate purchases. iData works with businesses across North Wales and the North West to align security, connectivity, cloud services and ongoing support around practical continuity requirements.
The most useful outcome from a ransomware incident is not simply restored data. It is the confidence that your business can identify an attack early, contain it calmly and recover essential services in a way that protects customers, staff and the organisation’s future.