The Ransomware Recovery Drill: Prove Your Office Can Keep Operating

A practical tabletop and restoration exercise for testing whether backups, contacts, decisions, and alternate work procedures are ready before ransomware disrupts the office.

Backups are only one part of recovery

Ransomware can interrupt access to shared files, email, accounting systems, scheduling platforms, phones, and customer records. A recovery plan must address more than restoring data. It must help the business decide what to stop, what to continue, who can authorize actions, and how to communicate.

CISA’s StopRansomware guidance recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. It also emphasizes documenting lessons learned and updating plans after exercises or incidents.

The following drill can be completed without encrypting a live system.

Define the scenario

Choose a realistic scenario, such as:

A staff member reports that shared files have unfamiliar extensions.
The accounting platform is inaccessible and a payment request appears altered.
Several Microsoft 365 users receive unexpected sign-in alerts.
A server or workstation displays a ransom note.
A critical cloud provider is unavailable during a busy period.

Do not use a real malware sample. The purpose is to test decisions and recovery steps, not to create risk.

Assign the exercise roles

Exercise leader: keeps the discussion moving.
Business decision-maker: approves downtime, communication, and spending.
Technology lead: explains isolation, investigation, and restoration.
Operations lead: identifies essential services and manual alternatives.
Communications lead: prepares employee, customer, vendor, and public messages.
Recorder: captures decisions, unanswered questions, and action owners.

Participants should know the exercise is a test. The goal is to uncover weaknesses, not assign blame.

Part one: the first hour

Ask the group:

Who receives the initial report?
How is the affected device or account isolated?
Which systems are considered potentially affected?
What evidence must be preserved?
Who contacts the managed service provider, insurer, counsel, and law enforcement?
How are employees told to stop using a system?
Who can approve a business interruption?

The answer should not depend on an employee remembering a phone number stored only in the affected email account. Maintain an offline contact list with vendor escalation details and policy information.

Part two: business priorities

List the functions that must continue within four hours, one business day, three days, and one week. Examples may include scheduling, payroll, patient communication, client deadlines, payment acceptance, dispatch, and access to contracts.

For each function, identify:

The system or information required.
The person responsible.
The manual or alternate process.
The maximum acceptable downtime.
The maximum acceptable data loss.
The communication obligation.

This converts vague urgency into recovery priorities.

Part three: backup and restore validation

Select one critical file repository and one important application or system. Confirm:

Where the backup is stored.
Whether it is isolated from ordinary administrator credentials.
Who can authorize restoration.
Whether encryption keys or configuration files are available.
How a clean restoration environment is created.
How restored data is verified before users return.

Perform a controlled restore in a test location. Record the start time, completion time, missing files, permissions issues, application dependencies, and user-verification steps.

A backup that restores only data but not permissions, configurations, or business workflow may still leave the office unable to operate.

Part four: communications

Prepare messages for employees, customers, vendors, and insurers. Avoid guessing about cause, scope, or affected information. Use language that distinguishes confirmed facts from investigation questions.

Employees should be told:

Which systems to stop using.
How to report suspicious activity.
Whether to disconnect a device.
Which alternate communication channel to use.
That they should not negotiate, delete evidence, or contact suspected attackers independently.

Customer communication may require legal review and may depend on facts that are not available during the first hour.

Part five: restoration decisions

Discuss the order of restoration. A common sequence may include identity administration, network controls, core line-of-business applications, shared data, workstations, and lower-priority services. The correct order depends on the business.

Before reconnecting restored systems:

Confirm the suspected access path is addressed.
Reset or rotate affected credentials when directed.
Verify administrative accounts and logging.
Apply current patches and security controls.
Test a small user group first.
Preserve a record of what was restored and when.

What is confirmed and what is uncertain

Confirmed: CISA recommends offline, encrypted backups and regular restore testing. Confirmed: ransomware can affect business operations, not only individual files. Uncertain: whether a particular backup is sufficient until a controlled restoration is tested.

Do not promise that paying a ransom will restore operations or prevent data disclosure. Do not assume cloud storage is an independent backup unless the provider’s retention, deletion, recovery, and administrator protections have been verified.

After the exercise

Create a corrective-action table with the issue, business impact, owner, due date, and evidence of completion. Repeat the exercise after major system changes, acquisitions, staffing changes, or a significant incident.

The best recovery plan is not the longest document. It is the plan that helps a small team make sound decisions when normal systems and normal assumptions are unavailable.