Check supplier recovery beyond the system restart

The provider announces that its platform is available again. Staff can log in. The incident dashboard turns green. Yet some transactions remain in an uncertain state, a queue has built up and customer teams cannot confidently explain which requests have completed.

Technical restoration is an important recovery milestone. Business recovery also depends on the work, records and decisions needed to deliver the service. A useful exercise tests the hand-off between those milestones rather than stopping at the login screen.

This guide offers an original recovery-acceptance checklist using a fictional service disruption. It is not a prescribed APRA test, a universal recovery target or a substitute for your organisation's continuity and incident plans.

Agree what “recovered” means for the operation

Start with the operation's approved tolerances and the actual service boundary. Identify what the provider restores and what your organisation must do afterwards.

CPS 230 addresses critical-operation tolerances and continuity capability. Use those requirements and your approved arrangements as the basis for the assessment. Do not replace the operation's tolerances with a supplier's technical recovery objective simply because the latter is easier to measure.

A recovery objective is a target for a defined recovery activity. An observed test result concerns what happened in a particular test. The organisation's tolerance describes the disruption it is prepared to withstand for the operation. Record each with its scope so they are not treated as interchangeable numbers.

For this exercise, define the customer outcome and the evidence that would demonstrate it. If records are available but work cannot be completed reliably, identify which part of recovery remains unfinished.

Fictional example: the platform returns with an uncertain queue

A fictional insurer uses an external workflow platform. During an outage, some requests were received by the insurer but not confirmed by the provider. Staff recorded additional work through an approved alternative process.

When the platform returns, the insurer has three populations to reconcile: work completed before the disruption, work with uncertain status and work recorded through the alternative process. The provider's availability notice does not identify which requests fall into each population.

The operations owner therefore needs a controlled reconciliation before deciding how to resume normal processing. Otherwise, resubmitting uncertain requests could duplicate work, while assuming they completed could leave requests unattended.

The example is deliberately about operating questions rather than a specific system design. The safe technical method depends on the service and should be established with the responsible specialists.

Prepare the evidence before the exercise

Ask what records each party can produce and how they relate. Useful inputs may include timestamps, request identifiers, status histories, exception logs and records from the alternative process.

Check that the identifiers can be matched across systems. If the provider uses one reference and your team uses another, establish the mapping before relying on it during disruption. Also identify time-zone differences and what each timestamp actually represents.

Use synthetic or appropriately controlled test information where possible. A recovery exercise should not create unnecessary exposure of personal or confidential information. Apply your organisation's information-handling and access rules to test evidence as well as live records.

Use a recovery-acceptance checklist

The following checklist is a starting point for discussion with operations, technology and the provider. It is not a complete technical runbook.

Record unresolved items rather than hiding them behind a single recovery status. Different parts of the service may recover at different times.

Test the hand-offs, not only the components

In the fictional exercise, the provider supplies a restored status file. The insurer's team must interpret it, match it to its own records and decide which uncertain requests need investigation. That hand-off is part of the exercise.

Ask whether the people involved can perform the work using the procedures available to them. A specialist explaining the missing step during the exercise may help the team progress, but the gap should be recorded. It is not evidence that the documented process already worked independently.

Also test escalation. If the two parties disagree about a request's status, who can resolve it? What information is needed? Which work should pause while the disagreement is examined? Establish those decisions through the approved response arrangements.

Measure the backlog as work, not only volume

A queue count is useful, but it can conceal different types of work. Some items may be straightforward; others may need investigation or a decision only a small number of people can make.

For the exercise, describe the queue's composition and the assumptions behind the clearance estimate. Identify whether staff availability, system performance or a provider dependency limits progress. Do not turn an optimistic estimate into a demonstrated recovery result.

Where prioritisation is needed, use the organisation's approved approach and relevant customer obligations. Record who makes the decision and how exceptions are escalated. Avoid inventing a universal rule that the oldest or largest item must always go first.

Report what the exercise actually showed

CPG 230 provides guidance on continuity testing and its findings. A useful report for this exercise distinguishes observed results from assumptions and work not performed.

Record the service and scenario covered, the evidence observed, the unresolved records, the backlog position and the effect on the operation's tolerance assessment. Note any manual intervention or assistance required beyond the planned process.

If the exercise demonstrates platform restoration but not reconciliation, say so. If it demonstrates reconciliation for a limited sample or scenario, preserve that boundary. A narrower, accurate conclusion is more useful than an unsupported statement that recovery was fully successful.

Give the remaining work a clear owner

The fictional insurer's next actions might include improving the status mapping, clarifying the retry procedure or ensuring that alternative-process records can be reconciled. Each action needs a closure condition that addresses the observed gap.

Keep incident restoration and remediation closure separate. A service can return while improvements remain necessary. Use the remediation closure workflow to track those improvements without rewriting the exercise result.

The claims-disruption exercise provides a worked setting for testing these queue, workaround and reconciliation questions together.

The practical endpoint is a recovery decision supported by the service's actual state: systems available, records understood, outstanding work controlled and responsibilities clear for anything still unresolved.