A backup test is complete when the business can use the restore

Agree what a usable restored service must do before running a backup test. Then retain evidence that the restored data, application configuration, access controls and selected business transactions meet that definition. A successful backup job or a server that starts does not, by itself, show that the business can resume its critical work.

Australia’s ASD Essential Eight maturity model addresses backups of data, applications and settings, including testing restoration to a common point in time during disaster recovery exercises. The acceptance record below is our suggested implementation aid. It does not demonstrate compliance with every Essential Eight measure or make the model a universal legal obligation. 1

Set the recovery objective with the service owner. Test a safe, authorised restoration and the business outcome. Record what was excluded so that a narrow success is not reported as complete organisational recovery.

Name the service, the recovery scenario and the selected restore point. Specify the evidence needed to establish completeness and consistency. Where several systems exchange data, explain how their restore points will be reconciled. An order record and its related fulfilment record may both exist but still represent different moments.

Define the allowed amount of data loss and the target recovery time in operational terms. These are business choices informed by obligations and dependencies, not numbers to copy from another organisation. Distinguish the time taken to restore files from the time required to validate and release the service for use.

Have authorised recovery specialists establish the test boundary and rollback arrangements. Use a controlled environment and appropriate handling for any sensitive restored data. Prevent test transactions from reaching real customers, suppliers or payment routes. Confirm that credentials, permissions and monitoring remain appropriate; a convenience exception can invalidate a reassuring test result.

The operating team should know who can stop the exercise. If a required isolation or access control is missing, hold the affected test until the specialist resolves it. This guide deliberately does not prescribe commands for production recovery or changes to backup protections.

Assume a fictional Australian distributor restores its order application within its chosen target time. A business user can sign in, but several restored orders reference attachments that were stored elsewhere and not recovered. Infrastructure restoration has succeeded while the selected order-processing task has failed.

The team records the missing attachment dependency, identifies the source and owner, and plans a controlled retest. It does not change the acceptance criteria after seeing the failure. When reporting the result, it separates measured restore duration from the unresolved ability to process complete orders. No actual organisation or tested product outcome is represented here.

Fictional test record; no restoration was performed. The scenario defines a four-hour service recovery objective starting at 09:00 and a 30-minute data-loss objective measured against the stated interruption time.

Reporting “restored within target” would conceal the missing dependency. The technical duration is measured to a different finish event from business acceptance. The record should show the attachment source, restoration responsibility and agreed retest criteria, with business acceptance still pending.

The 20-minute data age also does not prove every transaction is present or consistent. Other dependent systems may have different restore points; reconcile them and validate the selected service before drawing a conclusion.

These figures are invented training inputs, not a suggested RTO or RPO. The example does not establish backup integrity, full Essential Eight maturity or successful production recovery. Any real execution requires the authorised test boundary and protections described above.

Retain the test version, authorised participants, selected records, timestamps and acceptance decisions. Avoid collecting unnecessary personal data in screenshots or exercise reports. Link detailed evidence through restricted locations rather than circulating a complete restored dataset.

State exactly what passed and what did not. Record whether the service owner accepted the result and who is authorised to accept any remaining exposure. Feed unresolved dependencies into owned actions and escalation, then schedule a retest when the relevant corrective work is ready. A tabletop and a restore test can inform each other, but neither automatically substitutes for the other.

It is useful technical evidence within its scope. Business acceptance still needs checks tied to the selected service, data and dependencies.

Choose proportionate coverage and record exclusions. Do not generalise one component’s result to a complete end-to-end service.

This worksheet cannot support that claim alone. Evaluate applicable requirements and the wider control environment with qualified reviewers.

AI assisted research and drafting. This article is general information; verify current requirements and obtain competent advice for consequential decisions.

1. ASD Essential Eight maturity model — Regular backups section: restoration of data, applications and settings to a common point in time is tested in disaster recovery exercises. Guidance applicability depends on context.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.