


05 Oct 26
A successful backup notification is reassuring. But it does not tell you whether your team could process an order, issue an invoice or access the right records after an outage. That is a different question, and it needs evidence from a recovery exercise.
October is Cyber Security Action Month. In its 1 October 2026 announcement, ASD’s Australian Cyber Security Centre encourages Australians and businesses to take practical security steps. Our suggestion for business leaders this month is to choose one important workflow and find out what restoring it would actually involve.
This is a starting exercise, not proof that your entire organisation can recover. Its value is making assumptions visible before an incident turns them into urgent decisions.
Choose a workflow whose loss would quickly affect customers, staff or cash flow. Be specific: “raise and send an invoice using the correct customer and transaction records” is easier to test than “restore finance”.
Ask the business owner to agree two limits with your IT provider: how long the workflow can be unavailable, and how much recent work the business could afford to lose. These are often called the recovery time objective and recovery point objective. They should reflect business needs and the capabilities you can fund, rather than a default setting in a backup product.
For example, a hypothetical business might accept restoring yesterday’s reference documents but need much more recent order data. Treat those as separate requirements. If your targets and current arrangements do not match, record the gap before promising a recovery time.
The files are only part of the picture. List the applications, identities, permissions, network connections, configuration and external services needed to complete the task. Note who can authorise recovery and how the recovery team would obtain access if normal sign-in or communications were unavailable.
ASD’s regular backups guidance covers important data, software and configuration settings. It also recommends coordinated restoration exercises and warns that spot checks can miss dependencies or synchronisation issues. A restored document alone is therefore a weak basis for claiming the business is ready.
Confirm what your backup arrangement actually covers. Do not assume that every cloud application, device or configuration is included because one dashboard looks healthy. Where a dependency belongs to another supplier, establish what they recover and what your team must do.
Have the technical team define a controlled recovery environment and the boundaries of the test. Protect live operations and recovered information. Restored applications should not accidentally send customer messages, process payments or overwrite current records.
Choose a recovery point and a scenario, such as losing access to the primary system. Record the assumptions: is the identity service available, are recovery credentials accessible, and are external suppliers participating? A test that assumes every supporting service is working answers a narrower question than a broader outage exercise.
Start with a manageable scope, then plan coordinated exercises that cover the full recovery requirement. The smallest test is useful for learning; it should not quietly become the only test you perform.
Once the technical team restores the environment, the person responsible for the workflow should check whether it is usable. Can an authorised staff member sign in? Are expected records present and sufficiently current? Do the necessary applications work together? Can the agreed task be completed safely?
Record actual elapsed time and the age of the recovered information. Capture missing dependencies, manual steps and permissions problems. A system that starts successfully but leaves staff unable to complete the task has not met that business outcome.
This distinction also appears in APRA’s June 2024 guidance on backup security and adequacy, which discusses testing the recovery of critical business operations as well as technology. That guidance addresses APRA-regulated entities; the practical lesson for other businesses is to measure recovery against an operational need, rather than assume those sector requirements apply universally.
Keep a concise record of the scenario, scope, recovery point, elapsed time, business validation and unresolved gaps. Give each gap an owner and a retest date. Include checks that backup access is appropriately restricted and that recovery remains possible when primary systems are affected.
Some fixes may be procedural: updating a contact list or documenting an overlooked dependency. Others may require different backup coverage, recovery infrastructure or investment. Prioritise them against the business impact and agreed targets. Revisit the exercise after material system changes as well as through your regular recovery programme.
Zarbtech’s backup and disaster recovery services cover tailored recovery planning, recovery infrastructure and cloud backup support. A useful first conversation is about the work your business needs to resume, the information it needs and the downtime it can tolerate.
Book a free consultation with Zarbtech to discuss your recovery priorities and an appropriate backup and disaster recovery approach. Bring your critical workflow, current arrangements and any known gaps so the discussion starts with the outcomes that matter.