Ransomware Recovery Plan for a Small Business

A ransomware recovery plan is a written sequence for containing the attack, deciding what must return first, restoring from clean backups, and checking that the business can operate safely again. Your plan should name the decision owner, critical systems, offline communication method, backup location, and test record before an incident happens. If those details live only in one technician's head, an outage will slow every decision when time matters most.

What happens before you start restoring data?

Separate affected devices from the network and coordinate with the person leading the incident response. Preserve evidence needed for investigation and confirm the attacker no longer has an active path into the environment. Restoring into an infected or still-accessible system can put the recovered data at risk again. CISA's ransomware guide starts with identifying impacted systems and isolating them, then moves into analysis, remediation, and recovery. Your recovery plan should connect to that broader incident plan without trying to replace it.

CISA's StopRansomware guide provides the response checklist and backup recommendations.

Which systems should your business restore first?

Rank systems by the work they enable, not by who complains first. Email and identity may be needed before anyone can use other apps. Your line-of-business database, phones, payment system, or customer portal may have different priorities. Write down dependencies so you do not restore an application before its server or identity service. For each critical system, name its owner, acceptable data loss, acceptable downtime, and a temporary manual process if the restore takes longer.

How do you know a backup is clean and usable?

Check the date of a candidate restore point, verify that the backup was protected from the attacker, and test the data in an isolated environment before reconnecting it. A backup dashboard showing success is not the same as opening the restored files and running the application. CISA recommends offline, encrypted backups and regular integrity tests. Keep at least one restore test that covers a full business workflow, not just a single file.

Who makes the recovery decisions?

Name one incident lead and backups for that person. The technical team decides whether a system is safe to rebuild, while business leaders choose service order and approve customer communication. Keep vendor, insurer, legal, and law-enforcement contacts in a place you can reach without your normal email or network. Define who can authorize a restore that may overwrite current data, and who confirms that staff can return to the system afterward.

How do you test and improve the plan?

Run a tabletop exercise for the first hour of a ransomware event, then perform a real restore test for one critical workload. Record what took longer than expected, which credentials were missing, and whether your recovery time and data-loss goals were met. NIST recommends planning, realistic test scenarios, and learning from each exercise. Update the plan whenever a key system, provider, or person changes. A plan that was tested last year against a different environment is not enough for your current business.

NIST's Guide for Cybersecurity Event Recovery explains planning, testing, and improvement.

What belongs on the recovery runbook's first page?

Put the incident lead and backup contacts at the top, with phone numbers reachable when company email is unavailable. List the authority to isolate devices, approve restoration, notify customers, and contact the insurer or outside response team. Next, identify the location of the backup inventory, recovery credentials, and current system-dependency map. The runbook should be accessible offline but protected from unauthorized access. A long technical manual is useful later; the first page should tell people who makes the next decision and where to find the information needed to make it.

How do you rebuild without bringing the attacker back?

Work with the incident lead to identify the entry path and the systems that can no longer be trusted. Rebuild or reimage affected machines from known-good sources, rotate compromised credentials, and close the access path before connecting restored data. Choose a backup point from before the malicious activity where the available evidence supports it. Test the restored application in an isolated environment and inspect its dependencies, such as identity, database access, and connected services. Only then return it to users in stages, watching for unusual activity. A clean file restored onto an unsafe server is not a clean recovery.

How should the business manage work during restoration?

For each critical process, note the temporary way to serve customers while its system is unavailable. That may mean a verified phone line, a manual intake record, or an agreed pause on transactions that cannot be handled safely. Name who tells employees which tools are approved and who updates customers on timing. Keep a record of manual work that must later be entered into the recovered system so it is not lost or duplicated. The broader continuity plan should define these temporary processes; the recovery runbook needs the handoff point at which the restored service takes over.

What does a useful recovery exercise measure?

Choose a business workflow, such as opening a customer record and sending an invoice, not only a server image. Time how long it takes to find the backup, obtain the right approvals, restore the application, verify permissions, and complete the workflow. Compare the result with the downtime and data-loss goals the business approved. Record any missing contacts, inaccessible credentials, software dependencies, or backup gaps, assign owners, and set a retest date. A tabletop helps people practice decisions; a technical restore proves whether the data and systems actually work. Use both.

What might a restore order look like?

A small business might first restore a clean identity service and administrator access, then the network and application dependencies needed for a customer database, then the database itself, and finally the staff devices used to work in it. Another business may need phones or a point-of-sale system earlier. Write each dependency beside the service it supports, the owner who can verify it, and the condition for moving to the next step. This prevents a common false finish: a server is running, but employees still cannot sign in, reach the data, or complete a transaction. Use your own workflow map to set the order.

How should backups be protected before an incident?

Keep backups separated from everyday user access, restrict who can change or delete them, and maintain a copy or recovery path the attacker cannot easily reach from a compromised workstation. Review whether backup credentials are shared with normal administrators and whether alerts would reveal an interrupted job or deletion attempt. CISA recommends offline, encrypted backups and regular integrity checks as part of ransomware preparation. Document where recovery credentials are held and how an authorized responder obtains them when the main network is down. Protection that nobody can access in an emergency is another kind of recovery failure.

Read how a broader business continuity plan keeps work moving during an outage.

See the separate steps for containing and investigating a cyber incident.

See how managed backup and recovery planning works.