Recovery depends on clean, tested backups and a rehearsed order for restoring services.Many organisations describe their ransomware plan with one sentence: “We have backups.” That statement leaves the hardest questions unanswered. Are the backups isolated from compromised administrator accounts? Has anyone restored a complete service from them? Which system must return first? How will the team know that the restored environment is clean?
A credible ransomware plan begins with the ability to restore essential operations safely. Prevention remains necessary, but recovery planning forces the organisation to understand its systems, data, dependencies and decision-making before an attacker creates the deadline.
Ransomware is an operational crisis
Modern ransomware may combine encryption with data theft and extortion. Even when decryption is possible, the organisation may face unavailable services, exposed personal data, damaged trust, legal duties and difficult communications. CISA’s StopRansomware guidance therefore treats preparation, prevention, response and recovery as connected work.
The objective is not merely to recover files. It is to restore a trustworthy business service while preserving evidence, containing the attacker and avoiding reinfection.
Define what must return first
List the services that the organisation needs to deliver its mission: identity, email, payments, customer records, production systems, communications and regulatory reporting. For each service, record its owner, supporting applications, infrastructure, vendors, data sources and authentication dependencies.
Agree two practical targets. The recovery time objective expresses how quickly the service should return. The recovery point objective expresses how much recent data the organisation can tolerate losing. These are business decisions informed by technology, not numbers the IT team should invent alone.
Design backups for hostile conditions
- Keep protected copies: maintain offline or otherwise isolated, encrypted backups of critical data and configurations.
- Separate control: backup administration should not depend entirely on the same identity system and privileged accounts used in daily production.
- Protect deletion: use immutability, object locking or equivalent safeguards where suitable, with carefully controlled retention settings.
- Include more than data: retain clean system images, configuration, infrastructure-as-code templates, software installation resources and required licences.
- Monitor the backup system: a successful scheduled job does not prove the content is complete, clean or restorable.
Test a service, not just a file
Opening one recovered document is a useful check, but it is not a recovery exercise. Select a critical service and restore it into an isolated environment. Confirm that applications start, identity works, data is consistent, integrations connect safely and authorised users can complete a business process. Record the time, missing dependencies, manual steps and decisions.
Exercises should include the possibility that production credentials, documentation and communication platforms are unavailable. Keep an accessible offline copy of the response plan and essential contacts. Define an out-of-band communication method so the response team does not reveal its actions through an environment an attacker may still observe.
The first response actions
- Activate the incident lead: give one person authority to coordinate technical, legal, operational and communication work.
- Isolate affected systems: contain spread while considering the need to preserve volatile evidence. If many systems are affected, coordinated network-level isolation may be required.
- Preserve evidence: collect relevant logs, system images and timelines before rebuilding removes useful traces.
- Assess scope: identify affected identities, devices, cloud resources, data and third parties. Treat the initial visible encryption as one symptom, not proof of full scope.
- Use clean administration: begin recovery from trusted devices and credentials that are not part of the compromised environment.
- Restore by priority: rebuild foundational services first, validate each stage and monitor for renewed malicious activity.
People and decisions belong in the plan
Name the incident lead, technical recovery owner, executive decision-maker, legal and privacy adviser, communications lead, insurer contact and external response support. Record who may disconnect systems, engage specialists, contact authorities, communicate with customers and approve restoration.
Ransomware can involve personal-data breach duties. The privacy team should assess notification requirements early, while the technical team preserves facts about affected data and systems. Avoid confident public claims before evidence supports them.
A useful quarterly exercise
Choose one critical service and assume its production environment and primary administrator account are unavailable. Ask the team to locate the plan, contact the right people, retrieve a protected backup, build an isolated recovery environment and demonstrate a real business transaction. Finish with named corrective actions, owners and deadlines.
The practical conclusion
A backup product is not a recovery capability. Recovery is a tested system of people, priorities, clean credentials, protected copies, technical dependencies and decisions. Organisations that practise restoration before an incident replace assumptions with evidence—and gain the ability to recover without improvising every critical step under pressure.
