A ransomware recovery plan gives a small business a calmer, safer way to respond when files are encrypted, systems are unavailable, or data may have been stolen. This reusable runbook covers what to prepare before an incident, what to do during the first hours, how to validate backups and restore services, and which controls to review afterward.
Overview
Ransomware recovery is not only a file-restoration exercise. A complete response must limit further damage, preserve useful evidence, protect accounts, restore the right services in the right order, and record decisions. The goal is to return to a known-clean operating state without allowing the original access path to remain open.
Assign responsibility before an incident occurs. A small business may combine roles, but someone should be designated to coordinate the response, someone should make technical decisions, and someone should handle staff, customers, suppliers, and other communications. Keep an offline or separately accessible copy of these contacts because the normal file server, email system, or password manager may be unavailable.
Preparation should include an inventory of critical systems, business owners, dependencies, backup locations, recovery credentials, and vendor contacts. Record which services are essential for the first day of operations and which can wait. For example, identity services, email, internet access, line-of-business applications, file storage, and payment or scheduling systems may have different recovery priorities.
Backups should be protected from the same administrative accounts and network paths used by production systems. Maintain more than one recovery option where practical, and test restoration rather than assuming that a successful backup job means the data is recoverable. A backup that has never been restored is an unverified assumption.
For broader endpoint preparation, see the small business antivirus policy template and the comparison of antivirus and EDR for small business.
Checklist by scenario
Before an attack: build the recovery baseline
- Assign decision roles: name an incident coordinator, technical lead, communications owner, and business approver. Include alternates.
- List critical assets: record endpoints, servers, cloud applications, identity providers, network equipment, databases, and third-party services.
- Define recovery priorities: specify which systems must return first, the maximum tolerable downtime for each, and the data loss that the business can accept.
- Document dependencies: note whether an application requires a database, domain services, a license server, a particular network share, or an external provider.
- Protect backups: use access controls that are separate from everyday workstation administration. Keep at least one recovery copy inaccessible from routine production credentials or networks when feasible.
- Test restoration: restore representative files and, where possible, a complete system into an isolated environment. Confirm that applications open the restored data and that business users can perform essential tasks.
- Prepare clean administration: maintain a trusted device or recovery environment for password resets, console access, and investigation. Do not rely on a potentially compromised workstation.
- Keep a contact pack: include security-tool vendors, managed IT providers, cloud providers, backup providers, insurance contacts, legal counsel, and relevant authorities or regulators where applicable.
- Practice the plan: run a short tabletop exercise. Ask who can authorize isolation, where the backup console is located, and how the business will operate if email is unavailable.
During the first minutes and hours: contain the incident
- Declare an incident: start a timeline with times, observations, actions, and the person who approved each action.
- Isolate affected devices: remove suspected endpoints from wired and wireless networks. If central security tooling supports network isolation, use it where appropriate. Avoid actions that destroy evidence or spread the threat.
- Protect unaffected systems: temporarily restrict lateral movement, review unusual administrative activity, and separate critical servers or backup infrastructure from affected networks if it can be done safely.
- Do not reconnect backups: pause automated synchronization and backup jobs if they could copy encrypted or malicious files into recovery data.
- Preserve evidence: save ransom notes, suspicious messages, filenames, alert details, relevant logs, and screenshots. Do not delete files or reimage every device before determining what happened.
- Identify the scope: look for affected users, endpoints, servers, cloud accounts, shared drives, and signs of data theft. Treat an apparently isolated computer as a lead, not proof that it is the only affected asset.
- Protect identities: from a trusted device, reset compromised or suspected accounts, revoke active sessions and tokens where supported, review administrator accounts, and require stronger authentication. Include service accounts, remote-access accounts, API keys, and backup-console credentials in the review.
- Communicate carefully: tell employees how to report symptoms and which systems to avoid. Do not speculate publicly about the cause, scope, or payment decision before the facts are established.
After containment: recover in a controlled sequence
- Confirm the entry point is addressed: investigate exposed remote access, stolen credentials, vulnerable software, malicious email, browser activity, or unmanaged devices. The exact cause may remain uncertain, but recovery should not proceed as if access is automatically safe.
- Establish a clean recovery environment: rebuild or verify systems using trusted installation media, known-good configurations, and current security controls. Do not treat an encrypted machine as clean merely because the ransom note is gone.
- Validate the backup: check its date, completeness, integrity, and separation from the incident. Scan or inspect restored data in an isolated environment before introducing it to production.
- Restore identity and core infrastructure first: recover the services required to authenticate users and operate securely, then restore essential applications and data. Keep systems segmented while confidence grows.
- Restore a limited pilot: bring back one controlled group or service, verify logs and security alerts, and confirm that users can complete critical workflows. Expand gradually rather than reconnecting every device at once.
- Monitor for recurrence: watch authentication, endpoint, network, cloud, and backup activity for renewed encryption, suspicious logins, persistence, or unusual data transfers.
- Record business impact: document downtime, unavailable data, affected systems, decisions, costs, and communications. This record supports later improvement and any professional or legal advice the business may need.
If a single Windows computer is affected and the broader environment appears safe, use a focused process such as the Windows malware-removal checklist. A suspected ransomware event involving shared storage, multiple accounts, or servers should be treated as a wider incident rather than a routine cleanup.
What to double-check
- Backup coverage: confirm that backups include cloud data, configurations, databases, critical laptops, and application-specific records—not only a primary file share.
- Backup isolation: test whether a compromised administrator could delete, encrypt, or alter every recovery copy. If the answer is yes, improve separation and access controls.
- Restore order: verify that the written sequence matches real dependencies. Restoring an application before its identity service or database may create confusing failures.
- Credential reach: review privileged accounts, remote-access tools, password vaults, email forwarding rules, OAuth applications, API keys, and backup credentials.
- Cloud recovery: confirm retention settings, version history, recycle-bin behavior, export options, and the provider's administrative recovery process. Cloud storage is not automatically a complete backup.
- Evidence retention: decide who stores logs, images, notes, and suspicious files, and protect those records from accidental alteration.
- Legal and contractual duties: identify in advance which customer, employee, partner, insurance, or regulatory notifications may apply. Obtain qualified advice for the specific jurisdiction and incident.
- Security tooling: verify that endpoint protection, EDR, email security, DNS filtering, and browser controls are deployed to the systems employees actually use. Tools that are purchased but not enrolled do not provide meaningful coverage.
Common mistakes
Wiping everything immediately. Reimaging can remove useful evidence and may leave the original access route undiscovered. Isolate first, document the state, and decide what must be preserved.
Trusting a successful backup job. A job can complete while excluding important data, retaining corrupted files, or failing to provide a usable application restore. Perform test restores on a schedule.
Restoring before resetting identities. If an attacker still controls an administrator, mailbox, remote-access account, or backup console, restored systems can be compromised again.
Reconnecting too quickly. Bring back a clean, limited pilot and monitor it. A staged recovery is slower than a single switch-on, but it makes recurrence easier to detect and contain.
Using the affected environment to investigate itself. Logs, credentials, and administrative tools may be unreliable. Use a trusted recovery device and preserve original records when possible.
Assuming ransom payment equals recovery. Payment does not remove the need to contain the intrusion, protect accounts, assess data exposure, and restore from a trusted state. Any decision involving payment should receive appropriate professional advice.
When to revisit
Review this ransomware recovery runbook at least before major seasonal planning cycles and whenever workflows, tools, staff responsibilities, or cloud services change. Also revisit it after a security incident, a failed restore test, an office or network redesign, a new remote-access method, or a significant change to Microsoft 365, endpoint management, or backup architecture.
Use this practical maintenance cycle:
- Quarterly: restore a representative file and one critical application component; verify that recovery credentials and contact details still work.
- Twice a year: run a tabletop exercise covering a locked-down file server, unavailable email, and compromised administrator credentials.
- Annually: review asset owners, recovery priorities, vendor contacts, retention settings, legal contacts, and the assumptions behind recovery time and data-loss targets.
- After every change: update the diagram and checklist when adding a cloud application, backup platform, remote-access tool, identity provider, or major business system.
- After an incident: conduct a lessons-learned review, close the gaps that allowed access or delayed recovery, and retest the revised plan.
Keep the final runbook short enough to use under pressure, but link it to detailed platform procedures where needed. Pair it with a current endpoint policy, a tested backup plan, and clear ownership. For Microsoft environments, the Microsoft Defender for Business deployment guide and practical setup checklist can help confirm that protective controls are actually deployed before recovery is needed.
