How to Keep Backup Restore Test Evidence for Cyber Insurance

Backup restore test evidence should answer three questions on a cyber insurance application: when the last real restore happened, what was restored, and how someone confirmed the result was usable. A green backup-job log can support that record, but by itself it normally shows only that a backup task reported success. Keep a dated record of scope, results and exceptions so the signer answers from facts rather than assumptions.

What does a cyber insurance application ask about restore testing?

It depends on the form, so read your exact wording. The Hartford's CyberChoice Underwriting Application is one real example, and it treats regular backups, offline or isolated storage, and recovery testing as separate questions.

That form (CB 00 H027 03 0824, copyright 2025, marked for businesses with revenue of $10M or more) asks:

• "Is your business' critical data regularly backed up?"
• "If yes, are backups stored offline and/or isolated from production systems?"
• "And, how often do the applicants test recovering data from the backup?"

The Hartford's FailSafe TERA application (FS 00 T001 00 0425, copyright 2025) asks the same recovery question and lists the choices: Never, At least monthly, At least quarterly, At least annually.

The recovery questions ask for a frequency. They do not list an evidence package, so do not read the record below as something The Hartford requires. Other forms differ. Question 27 of the Societies Insurance supplemental application (SI CM07 APP 2026.10.08) bundles several facts into one Yes/No: "Are backups kept offline or immutable, and tested at least twice a year?"

The record in this guide is an operational habit, not a carrier rule. It gives you something defensible when a form, broker, carrier, auditor, customer or manager asks for support.

Which result did your test actually prove?

Four results get reported as "we test backups," and each proves something different:

• Backup job completed: the product reported that a task finished. This says little about whether the data can be recovered.
• Restore operation completed: data was written to a target. This does not show that the data is complete or that anything works.
• Recovered data validated as usable: someone checked the result. NIST SP 800-34 describes data testing as confirming that files or databases "have been recovered completely and are current to the last available backup," and treats functionality testing as a separate step.
• Disaster-recovery exercise: a wider test. NIST SP 800-34 lists areas such as notification procedures, recovery on an alternate platform from backup media, connectivity, and restoring normal operations.

NIST SP 800-209 explains why the gap matters: many organizations have backups "but do not regularly check whether these backups can actually be used to restore the system." State which of the four results you achieved. A completed file restore is not a disaster-recovery exercise.

What backup restore test evidence should you keep?

Keep a dated record that ties one recovery point to one restore target and one validation result. Screenshots and vendor reports can support that record, but they do not replace it.

Record these fields for each test:

• Identity: test date and test ID or ticket number.
• Scope: the system, dataset, tenant or workload covered, and what was left out.
• Copy selected: backup copy, recovery point and retention tier.
• Restore target: preferably a safe non-production or isolated location.
• Timing: restore start and end times, and measured recovery time.
• Completeness: expected versus recovered files, records or objects.
• Validation performed: only the checks you really ran, such as opening representative files, starting an application and running a query, comparing record counts, comparing hashes where appropriate, or owner validation.
• Supporting artifacts: screenshots, console export, vendor report and logs.
• Exceptions: failed items, remediation owner and retest date.
• Acknowledgement: the tester and the business or system owner.

Store the record where the application signer can find it, and restrict access if it reveals system details.

A fictional worked example

This example is fictional. The company, dates and figures are invented.

A 60-person distributor tests its accounting database and finance file share under ticket RT-042.

• Copy: the previous night's recovery point from the 30-day repository.
• Target: an isolated virtual machine with no route to production.
• Timing: 09:05 to 11:40, or 2 hours 35 minutes.
• Completeness: 18,420 files expected and 18,417 recovered. The three missing items were reviewed and recorded as temporary files.
• Validation: the accounting application started, a trial balance report matched the source figures for that recovery point, and the finance manager opened ten sample files and signed off.
• Exception: a payroll export folder was not in the backup selection. The IT lead owns the fix, with a retest date recorded.

Honest summary: "Accounting database and finance share restored and validated on the test date. Payroll export folder was not protected at the time of the test. Other systems were not part of this test." That supports a statement about those workloads. It does not show that every critical system is recoverable.

How often should a backup restore test run?

No single cadence fits every business or form. The exact application, your recovery objectives, regulatory duties and risk determine what is appropriate.

Public references show the range. The Hartford's TERA choices run from Never to At least monthly. Societies' question names twice a year. NIST SP 800-209, written as security guidance for storage infrastructure and not as an insurance requirement, recommends testing "at least monthly for critical data."

Select the frequency your dated records support, not the one you plan to reach. If you test some systems more often than others and the form allows one answer, ask the broker or carrier how to respond.

What if the test was partial or failed?

Report the scope and the exceptions rather than turning a limited test into a blanket Yes. A failed test that was recorded and retested is still useful evidence of what happened, and hiding it creates a statement you cannot support.

Practical wording helps here:

• Partial test: name what was restored and what was not.
• Failed test: record the failure, the cause if known, the owner and the retest date.
• Never tested: say so where the form offers that answer, and schedule the first test. Describe future work as a plan.
• Ambiguous question: ask the broker or carrier in writing whether a file-level test satisfies the wording before anyone signs.

How do you test without creating new risk?

Producing evidence should not damage the thing being protected. Set these boundaries before you start:

• Do not overwrite production. NIST SP 800-209 describes restoring to a sandbox recovery environment for end-to-end tests and to an isolated staging environment for cyber-attack recovery copies.
• Do not expose sensitive data. A test copy needs the same access limits as the original, plus a recorded plan for removing it afterward.
• Do not weaken retention, lock settings or backup schedules to make a test easier.
• Do not delete a protected production copy merely to create evidence.
• Keep restored systems off the production network so they cannot collide with live services.

CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. A restore record is a separate fact from where the copy is stored, so document whether your copies are offline, isolated or immutable on their own evidence. If your files live in a sync service, also check whether OneDrive or Google Drive counts as backup under your form's wording.

Checklist before the signer answers

• The exact form question was read, and unclear terms were clarified with the broker or carrier.
• The last real restore date comes from a record, not from memory.
• The record states what was restored and what was excluded.
• Someone validated usability, and the checks are named.
• A job log is treated as support only.
• The selected frequency matches the dates in your records.
• Failed items and exceptions have owners and retest dates.
• The answer covers the same systems the question covers.

This is practical training, not legal, coverage or underwriting advice. No test record, cadence or product guarantees eligibility, pricing, coverage, renewal, limits or claim payment.

Sources

• The Hartford CyberChoice Underwriting Application, CB 00 H027 03 0824
• The Hartford FailSafe TERA application, FS 00 T001 00 0425
• Societies Insurance Cyber Liability Supplemental Application, SI CM07 APP 2026.10.08
• NIST SP 800-34 Rev. 1, Contingency Planning Guide
• NIST SP 800-209, Security Guidelines for Storage Infrastructure
• CISA #StopRansomware Guide