A backup is not a business continuity plan. A backup is one component of a recovery capability. The difference becomes clear when an office must decide what to restore first, who is authorized to act, how customers will be served, and whether the restored data can be trusted.
CISA recommends maintaining offline or otherwise protected backups of critical data and regularly testing their availability and integrity. Its ransomware guidance also emphasizes recovery planning, system prioritization, and tested procedures. See https://www.cisa.gov/stopransomware/ransomware-guide.
This exercise is intended for a small Central Florida office and can be completed in 60 to 90 minutes. It is not a substitute for technical testing, legal advice, cyber-insurance requirements, or a full disaster-recovery program.
Choose a realistic scenario
Use a scenario that affects business decisions without requiring dramatic storytelling:
“On a Monday morning, staff cannot open shared files. Several workstations display unusual file names. Microsoft 365 sign-ins are generating alerts, and the office’s technology provider is investigating. The business cannot assume that every backup is clean or that ordinary administrator credentials remain trustworthy.”
Do not assume the cause, attacker, ransom amount, or extent of data theft. Those details are uncertain until investigated. The exercise should test decisions, not predict a specific incident.
Part 1: Stabilize the business
Ask the group:
- Who declares an incident?
- Who can disconnect affected devices or accounts?
- Which systems must be isolated immediately?
- How will staff communicate if email is unavailable?
- Who contacts the technology provider, insurer, attorney, bank, and law enforcement?
The first objective is to limit spread and preserve options. Staff should not repeatedly restart systems, delete suspicious files, negotiate with unknown contacts, or restore data before the response team establishes a safe sequence.
CISA’s ransomware materials advise organizations to implement incident response and business continuity plans and to contact law enforcement when appropriate. See https://www.cisa.gov/sites/default/files/publications/Ransomware_Executive_One-Pager_and_Technical_Document-FINAL.pdf.
Part 2: Define the minimum operating service
List the activities the business must perform during the first day, first three days, and first week. Examples include:
- Answering customer or patient calls.
- Scheduling appointments or field work.
- Processing payroll.
- Receiving payments.
- Accessing contracts or job documents.
- Submitting required reports.
- Communicating with employees and vendors.
For each activity, identify a manual or alternate process. A paper appointment list, known phone numbers, printed emergency contacts, preapproved payment procedures, and offline copies of essential forms may provide temporary resilience. These workarounds must be protected and kept current; a forgotten paper process is not automatically a usable process.
Part 3: Establish the recovery sequence
The recovery sequence should reflect business impact, not technical convenience. A typical order might be:
- Identity and administrator recovery.
- Network and endpoint management.
- Core line-of-business application.
- Financial and payroll systems.
- Shared files and records.
- Secondary applications and archives.
For each system, record the owner, provider, dependencies, clean recovery point, expected restoration time, validation step, and fallback process. Recovery time and recovery point objectives should be business decisions. If the office has never set them, the exercise has found an important gap.
Part 4: Prove the backup is usable
Ask the backup owner to demonstrate:
- The most recent successful backup.
- The location and protection of backup copies.
- Whether ordinary production credentials can delete or alter them.
- The process for restoring a file.
- The process for rebuilding a system.
- How restored data is scanned and validated.
- Who can authorize production use.
CISA warns that ransomware variants may attempt to delete or encrypt accessible backups, which is why offline or protected copies matter. A successful job log proves that a backup process ran; it does not prove that the office can restore the right data within an acceptable time. See https://www.cisa.gov/stopransomware/ransomware-guide.
Perform at least one real restoration test after the tabletop. Restore a representative file or system to an isolated location, confirm permissions and dates, and document the result. If the office uses a cloud service, verify what the vendor’s native retention covers and what it does not cover.
Part 5: Test communications and authority
Prepare two communication paths: one for staff and one for customers or partners. The message should be accurate, limited, and approved by the person responsible for legal and business decisions. Do not claim that data was not accessed merely because files were encrypted. Do not claim that recovery is complete merely because systems are online.
Also document payment authority. Ransomware response may involve financial, legal, sanctions, insurance, and law-enforcement considerations. No employee should make an independent payment decision during pressure.
Confirmed versus uncertain
Confirmed: protected backups, restoration testing, incident response planning, and business continuity planning are recommended by CISA and other federal guidance. Confirmed: recovery should consider both technical systems and business operations.
Uncertain: no checklist can establish whether a backup is free of malware, whether data was exfiltrated, whether a particular ransom payment is lawful, or whether a specific notification is required. Those questions require qualified incident-response, legal, insurance, and regulatory guidance based on facts.
Turn findings into assigned work
End the exercise with a short action register:
- Finding.
- Business impact.
- Owner.
- Due date.
- Evidence required.
- Retest date.
Common findings include an untested restore, missing offline protection, no alternate communication method, unclear administrator recovery, outdated vendor contacts, and no manual process for essential work.
Repeat the exercise at least annually and after major technology, staffing, location, or vendor changes. A recovery-ready office is not one that owns a backup product. It is one that can explain what happens next, restore trusted systems in a deliberate order, and keep essential work moving while uncertainty is resolved.