A green backup dashboard is not a recovery test
Backup software can report that a job completed even when the organization would still struggle to resume operations. The files may be present but corrupted, encrypted, incomplete, inaccessible without a compromised identity system, or missing the configuration and application components needed to use them. A restore may also take far longer than leadership expects.
The FBI recommends maintaining offline, immutable backups and testing restoration. CISA advises organizations to keep critical backups offline and encrypted, test their availability and integrity in a disaster-recovery scenario, and prioritize the restoration of critical services. NIST emphasizes that recovery is not merely retrieving files; the organization must be able to trust the accuracy and integrity of restored data.
For a Central Florida organization, this capability supports more than ransomware resilience. The same recovery discipline can expose weaknesses before a hurricane, power disruption, equipment failure, accidental deletion, or vendor outage. The triggering events differ, but the operational questions are similar: what must return first, which dependencies are required, who has authority, and how long will it take?
This 90-minute exercise is intentionally narrow. It does not replace a full incident-response or disaster-recovery exercise. It gives a small or midsize organization a practical way to prove one important recovery path and turn assumptions into measured evidence.
Decide what the test must prove
Choose one meaningful service rather than attempting to restore the entire company. Good candidates include a shared department folder, a small application and its database, a virtual server, a Microsoft 365 data set covered by a separate backup product, or a workstation image used for a critical role.
Write a one-sentence objective before starting. For example:
> Restore the finance department's selected test folder and its permissions to an isolated location, verify the recovered files against a known-good reference, and document elapsed time without using production administrator credentials.
A useful objective identifies:
- The exact system or data set.
- The selected recovery point.
- The isolated destination.
- The validation method.
- The maximum acceptable recovery time.
- The people authorized to conduct and approve the test.
Do not use live sensitive data unnecessarily. Select a controlled sample, follow retention and privacy requirements, and avoid introducing restored systems into production during an exercise.
Know the two clocks: RPO and RTO
The recovery point objective, or RPO, describes how much recent data the organization can tolerate losing. If the RPO is four hours, the backup and replication design should support returning to a point no more than four hours before the disruption under the tested conditions.
The recovery time objective, or RTO, describes how quickly a service should return. It includes more than the file-copy duration. Detection, decision-making, obtaining clean equipment, identity recovery, network preparation, application installation, validation, and business approval all consume time.
Leadership should approve realistic objectives based on business impact. An objective copied from a vendor brochure is not a commitment the organization has demonstrated. Record the measured result from the exercise and compare it with the approved target.
Preparation before the 90-minute clock starts
The exercise coordinator should confirm:
- A current inventory identifies the data, application, owner, backup location, retention, and dependencies.
- The chosen recovery point predates any simulated corruption.
- The restoration destination is isolated from production and cannot overwrite live data.
- Backup administrators use separate, strongly authenticated accounts rather than ordinary daily accounts.
- Required encryption keys, certificates, recovery codes, licenses, and vendor contacts are available through an approved process.
- Monitoring and audit logs will record the exercise.
- The business owner can validate the recovered information.
- Stop conditions and escalation contacts are documented.
If the test cannot begin because no one can locate a recovery key or identify the application owner, that is already a valuable finding. Do not quietly work around it; document it.
The 90-minute recovery exercise
Minutes 0–10: declare the scenario
State that ransomware is assumed to have affected the selected production resource and that normal administrative credentials may be untrusted. Record the start time, participants, test scope, selected recovery point, and expected RTO and RPO.
The coordinator confirms that this is an exercise and that no one should connect the restored resource to production without authorization. If the organization has an incident-response plan, use its roles and communications path rather than inventing a separate structure.
Minutes 10–25: locate the recovery materials
Without relying on undocumented personal knowledge, identify the applicable backup, system image, configuration, credentials, keys, software, and recovery instructions. Confirm that the backup copy is protected from ordinary production access.
Record every dependency that is missing, stale, or available only through the system being restored. Common circular dependencies include:
- Backup-console access that relies on the same identity provider presumed unavailable.
- Recovery documentation stored only on an encrypted file server.
- Encryption keys held in an inaccessible password vault.
- Installation media or licensing available only through a departed employee.
- Network records that cannot be reached during an outage.
Minutes 25–55: restore into isolation
Restore the selected data or system into a clean, segmented test environment. Use the organization's documented procedure and current vendor guidance. Preserve logs and screenshots that show the selected recovery point, destination, start and completion time, and errors.
Do not assume the newest backup is clean. NIST notes that automated backups can preserve encrypted or corrupted data after an event. The response team needs monitoring and investigation evidence to choose an appropriate last-known-good recovery point.
If a restored system must be booted, keep it isolated until it is scanned, patched as appropriate, and approved. CISA cautions organizations to avoid reinfecting clean systems during recovery.
Minutes 55–75: validate integrity and function
A completed restore job is only an intermediate result. The data owner and technical team should verify:
- Expected files, records, and configurations are present.
- File counts, hashes, checksums, database checks, or other integrity measures match known-good evidence where available.
- Permissions and ownership are correct and do not grant excessive access.
- The application opens and completes a safe, representative transaction.
- Security tooling, logging, time synchronization, and monitoring function in the recovered environment.
- No production connection, scheduled task, webhook, email, or automation was unintentionally activated.
- The recovery point meets the RPO.
A user should validate business usability. IT may confirm that a database starts while the department discovers that a required attachment store, template, integration, or historical record is absent.
Minutes 75–90: measure and assign actions
Record the elapsed time for access, restore, validation, and business approval. Compare the result with the RTO. Capture failures without disguising them as informal observations. Each finding should have an owner, due date, severity, and retest requirement.
Conclude with an explicit disposition:
- Passed as designed.
- Passed with corrective actions.
- Failed because the selected data could not be restored or trusted.
- Inconclusive because the test environment or evidence was insufficient.
A failed exercise is safer and less expensive than discovering the same failure during an active ransomware incident.
What to test beyond the data copy
Backup isolation and immutability
Determine whether compromised production credentials could delete, encrypt, shorten retention, or alter backup copies. “Cloud” does not automatically mean isolated or immutable. CISA warns that accessible backups are targeted and that automated synchronization can propagate encrypted files.
Identity recovery
Document how designated personnel reach backup systems when ordinary identity services, multifactor authentication, email, or single sign-on are unavailable. Emergency access must be tightly controlled, monitored, periodically tested, and protected from routine use.
Configuration and application dependencies
Files alone may not restore operations. Include system configurations, application installers, supported versions, certificates, keys, service accounts, network settings, database schemas, and vendor instructions. CISA recommends maintaining updated golden images and necessary source code or executables where appropriate.
Clean recovery infrastructure
Identify where restored workloads will run if production hardware, virtualization, storage, or cloud accounts are unavailable or untrusted. Confirm capacity, networking, licensing, and security controls rather than assuming spare infrastructure will appear during the incident.
Communications and decision authority
Name who can declare an incident, isolate systems, contact counsel and insurance, engage a response provider, communicate with customers, and approve restoration. Keep essential contacts and procedures available through a protected offline method.
Questions for a managed service or backup provider
A customer should understand which responsibilities remain with the organization. Ask:
- Which systems and data are covered, and which are excluded?
- How frequently are backups created and how long are they retained?
- Are copies offline, logically isolated, immutable, or separately administered?
- Can production administrators delete or alter every backup copy?
- How are backup-platform accounts and encryption keys protected?
- What evidence confirms job completion and data integrity?
- How often are customer restorations tested, and who validates them?
- What restoration times have actually been measured for a comparable data volume?
- What costs, support tiers, or data-egress limits apply during a large recovery?
- How are provider personnel screened, authorized, logged, and reviewed?
- How will the provider communicate during a regional disruption affecting many customers?
- Can the customer export data and configurations if the relationship ends?
NIST's backup guidance for managed service providers stresses planning, maintaining, and testing backup files. A contract saying “backup included” is not a recovery design.
Add Central Florida realities to the plan
A ransomware incident may occur during hurricane preparation, a power disruption, or a period when staff and vendors are already stretched. Test assumptions about:
- Remote access when offices are closed.
- Internet and cellular availability at alternate work locations.
- Generator runtime, fuel, cooling, and safe physical access.
- Vendor response when many regional customers need help simultaneously.
- Equipment delivery delays and replacement capacity.
- Secure handling of portable media and paper procedures.
- Alternate communications when corporate email is unavailable.
- Manual workarounds for patient care, education, construction, professional services, or customer support.
Do not combine ransomware and hurricane scenarios merely for drama. Use the overlap to identify shared dependencies and single points of failure.
Evidence leadership should receive
A short after-action report should include:
- The service and recovery point tested.
- Approved RTO and RPO compared with measured results.
- Backup copy and isolation method used.
- Integrity and business-function validation performed.
- Missing dependencies or inaccessible recovery materials.
- Security and logging observations.
- Corrective actions, owners, and due dates.
- The planned retest date.
Repeat focused tests throughout the year and vary the system, recovery point, failure condition, and personnel. At least periodically, conduct a broader exercise that includes business leadership, communications, legal, insurance, critical vendors, and operational teams.
The central question is simple: can the organization restore a clean, trusted service within the time the business requires? Only a measured test can answer it.
Human-reviewed draft. This article provides general information, not legal, insurance, incident-response, or product-configuration advice. During an active incident, preserve evidence, follow the organization's response plan, and coordinate with qualified responders and appropriate authorities.