Recovery readiness starts with a complete restore

A green backup dashboard answers one question: did the backup process complete? It does not answer the more important operational question: can the business service be restored to a usable state when it matters?

That distinction becomes critical during ransomware recovery, hardware failure, platform migration or a major infrastructure change. A file can be recoverable while the service around it is not.

Restore the service, not only the files

Australian Signals Directorate guidance treats recovery as more than copying data back from storage. The Information Security Manual calls for restoration of data, applications and settings to a common point in time to be tested as part of disaster recovery exercises.

That matters because a business service usually depends on several layers working together. The data may be intact while the application version is wrong. The application may start but fail because identity, certificates, licensing, name resolution, storage permissions or configuration data were not recovered with it.

Routine recovery of a deleted user file is valuable operationally, but it does not demonstrate that a complete system can be recovered after a serious disruption.

Test the dependencies that make the service usable

A recovery test should start by defining the service outcome that must return.

For one system, success may mean users can authenticate, open the application and access current data. For another, it may require storage, network paths, integration services, scheduled jobs, monitoring and external dependencies to return in a defined sequence.

The test should therefore answer practical questions:

• Which systems have to be restored together?
• Which configurations and credentials are required before the application can operate?
• Which dependencies can be rebuilt, and which must be recovered?
• What is the acceptable recovery point for the data?
• What evidence proves the service is usable, not merely powered on?

The exact answers vary by environment. The important point is that the recovery test follows the real service dependency chain rather than the boundaries of the backup product.

Use lifecycle deadlines to expose hidden recovery risk

Technology lifecycle deadlines are useful forcing functions because they make hidden dependencies harder to ignore.

Microsoft lists 12 January 2027 as the end of extended support for Windows Server 2016. Organisations that still rely on the platform have a finite window to understand what those servers do, what depends on them and how workloads will be migrated or replaced.

A recovery exercise can strengthen that work. It can reveal undocumented services, old authentication dependencies, hard-coded addresses, unsupported application components, certificates, local accounts or configuration files that a simple server inventory may miss. Where those dependencies are unclear, an Infrastructure Review can provide a structured way to document the current position before recovery or migration decisions are made.

The objective is not to restore an ageing platform forever. It is to understand the service well enough that recovery and migration decisions are based on evidence rather than assumptions.

Record what the recovery exercise actually proved

A recovery test should leave behind evidence that can be compared with the organisation's expectations.

Relevant evidence includes:

• the recovery point that was available;
• when restoration started and when the service became usable;
• which systems, applications and settings were restored;
• which dependencies had to be rebuilt or supplied separately;
• what validation was performed before users were allowed back in;
• which assumptions, missing documentation or access problems delayed recovery;
• which corrective actions were assigned after the exercise.

For APRA-regulated entities, this service-level view also aligns with CPS 230 Operational Risk Management, which is in force from 1 July 2026. The standard requires credible business continuity planning, disaster recovery planning for critical information assets, and systematic testing across critical operations using severe but plausible scenarios.

The broader lesson applies well beyond regulated industries: recovery should produce evidence about whether the service can meet the organisation's real operating needs.

Protect the recovery path itself

Recovery capability is valuable only if it survives the incident that creates the need for it.

Backup repositories, administrative access, recovery documentation and required credentials should be protected so a compromise of normal production access does not automatically compromise the recovery path as well. Access should be appropriately restricted, and recovery material should remain available when normal management tools are unavailable.

The controls need to fit the environment. The design goal is resilience and separation without creating an unmanageable parallel system.

What this means in practice

A backup and recovery review should be able to answer five questions clearly:

1. What business service are we trying to restore?
2. Which data, applications, settings and dependencies have to return together?
3. When was that complete restoration last tested?
4. What evidence shows the recovered service met the required recovery point and recovery time?
5. Which ageing or unsupported dependencies could prevent a successful restore or migration?

If those answers are unclear, the organisation may have backups without having dependable recovery capability.

Where professional input helps

Professional input is valuable where environments have accumulated legacy systems, undocumented dependencies, specialist applications or mixed on-premises and cloud services.

The work may include dependency discovery, backup and restoration design, recovery planning and structured recovery exercises. Where the findings require architecture or implementation changes, Infrastructure Design & Delivery can carry those changes through into a supportable target state.

The goal is straightforward: when a disruption occurs, the organisation should be working from a tested recovery capability rather than discovering the real dependencies for the first time.