The backup dashboard is green. Every scheduled job says “successful.” Then someone asks a harder question: can the agency restore Tuesday’s client folder, open the files, confirm the right version, and put the folder back into controlled use?
That answer affects more than IT. Producers may need policy documents. Account managers may need endorsements and correspondence. Claims staff may be waiting for material that supports a time-sensitive response. A backup that exists but cannot be found, decrypted, or opened does not help any of them.
CISA recommends offline, encrypted backups and regular tests of backup availability and integrity in a disaster-recovery scenario.[1] NIST’s Cybersecurity Framework 2.0 states the outcome plainly: backups are created, protected, maintained, and tested.[3] A small agency can start proving that outcome without staging a full disaster.
This exercise is a recovery test, not a compliance determination or a request to interrupt production. The system owner and IT provider should approve the test method, location, sample data, and cleanup steps. If the agency is subject to regulatory, contractual, carrier, or records-retention requirements, the responsible legal or compliance adviser should decide how those requirements apply.
Choose one useful recovery target
Do not begin with “restore everything.” Pick one representative folder or small data set whose business owner can recognize the contents.
A good test target might contain a fictional training account or a sanitized copy of ordinary agency work: a PDF policy document, a spreadsheet, an email exported in its normal format, and a file with version history. Do not create a fake customer inside a live policy-management system. Use approved test data or a controlled copy that cannot be mistaken for an active record.
Write down four facts before anyone restores it:
- the system and backup set that should contain the target;
- the date and version to recover;
- the person authorized to inspect the restored content;
- the clean destination where the test copy will go.
Keep the test destination separate from the live folder. Restoring over production data turns a simple check into a change event and can destroy the version you were trying to compare.
Define success before selecting restore
“The job completed” is not a useful pass condition. The agency needs to know what usable recovery looks like.
For this test, success means the team can locate the requested recovery point, restore it to the approved test location, open the expected file types, verify the contents with the business owner, confirm access is restricted, and remove the test copy according to the agreed cleanup plan.
Add a time expectation. NIST defines a recovery time objective as the maximum time a resource can remain unavailable before the outage causes an unacceptable effect on other systems or business processes.[2] A small agency does not need to borrow a federal template, but it does need an honest answer about timing. If client documents are needed within four hours, a restore that depends on a vendor call scheduled for next Tuesday misses the business need.
Record the starting time when the authorized tester begins looking for the recovery point. Stop the clock when the business owner has opened and checked the restored files, not when the backup console first reports completion.
Watch the handoffs
The restore button is usually not the difficult part. Trouble appears between people and systems.
The operations manager may know which client folder matters but not its storage path. The managed service provider may control the backup console but lack permission to inspect client content. A cloud administrator may restore the folder yet leave it visible to the wrong group. The business owner may be available to check a PDF but not the specialty file created by an agency application.
Run the test with the people who own those handoffs:
- The business owner identifies the target, date, and expected contents.
- The system owner confirms that the test will not overwrite live data.
- The backup operator finds the recovery point and restores it to the approved location.
- The authorized business reviewer opens the files and compares them with the expected record.
- The system owner checks permissions and removes or retains the test copy under the approved procedure.
NIST describes testing as a way to validate recovery capability and exercises as a way to find planning gaps.[2] Treat every awkward handoff as a finding. Do not quietly help the team past a missing account, stale phone number, or undocumented approval and then mark the test successful.
Check the restored data, not just the file names
A folder can reappear while still being unusable.
Open a sample from each expected file type. Check that a PDF renders, a spreadsheet opens without repair warnings, and an exported message includes its attachment when one should be present. Compare file dates and a small number of known values with the test description. If the workflow depends on an application, confirm that the restored material can be read by the approved application in the test environment.
Look at permissions too. A restore may inherit access from the destination rather than preserve the original restrictions. Confirm that only the approved tester and business reviewer can reach the recovery copy. Do not put client or employee records in a shared test folder for convenience.
If the recovery point is missing, incomplete, or unreadable, preserve the evidence from the test. Record the backup set, requested date, messages shown by the tool, files that failed, and who is investigating. Avoid repeatedly changing settings until the first failure is understood.
Test the path you would use during ransomware recovery
A routine restore and a ransomware recovery are not identical. A live administrator account, connected backup repository, or normal network path may not be trustworthy during an incident.
CISA warns that ransomware may delete or encrypt accessible backups, which is why it advises keeping backups offline.[1] Its recovery guidance also calls for restoring from offline, encrypted backups according to the priority of critical services.[1] The agency’s test should therefore answer two questions separately: can we restore a file during an ordinary mistake, and can the designated recovery team reach a protected copy when normal accounts or systems are unavailable?
Do not simulate ransomware on production equipment. Walk through the alternate access path instead. Confirm where the protected copy lives, who can authorize its use, how recovery credentials are obtained, which clean device or environment would receive the data, and how the team would check for continuing compromise before reconnecting restored systems.
That conversation may expose a circular dependency. The password vault may require the unavailable email account. The vendor’s emergency number may be stored only in the down system. The restore instructions may sit inside the repository nobody can access. Move the minimum recovery information to an approved, protected location that remains available during an outage.
Keep a one-page proof record
Finish with a record someone outside the test can understand. Include:
- the date, scope, backup source, and recovery point tested;
- start time, end time, and who performed each step;
- the files or functions checked and the result;
- access-control and cleanup verification;
- failures, workarounds, owners, and due dates for corrections.
Do not attach restored client files to the test record. A file list, sanitized screenshot, ticket reference, or confirmation from the authorized reviewer may provide enough evidence without duplicating sensitive information.
Repeat the same small test after a backup product, cloud tenant, managed provider, encryption key process, or critical application changes. NIST says a contingency plan should remain a living document that is updated as systems and organizations change.[2] Rotate the target so the agency eventually checks more than one storage system and file type. A full recovery exercise still has value, but one clean folder is a practical place to learn whether the recovery path works at all.
The green dashboard can tell you that a job ran. A restore test tells you whether the agency can get usable work back, within the time the business expects, without opening the recovered data to the wrong people.
For practical guidance on cyber risk and safer AI use, subscribe to Cyber & AI Insights.
If your agency wants an independent review of its backup and recovery test process, schedule a conversation with Your Data Guardian.
Sources
[1] https://www.cisa.gov/stopransomware/ransomware-guide — CISA #StopRansomware Guide
> “It is important that backups are maintained offline, as many ransomware variants attempt to find and subsequently delete or encrypt accessible backups to make restoration impossible unless the ransom is paid.”
> “Reconnect systems and restore data from offline, encrypted backups based on a prioritization of critical services.”
[2] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf — NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
> “Testing validates recovery capabilities, whereas training prepares recovery personnel for plan activation and exercising the plan identifies planning gaps; combined, the activities improve plan effectiveness and overall organization preparedness.”
> “Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD.”
> “The plan should be a living document that is updated regularly to remain current with system enhancements and organizational changes.”
[3] https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf — NIST Cybersecurity Framework 2.0
> “PR.DS-11: Backups of data are created, protected, maintained, and tested”