Stress-test shared cloud dependencies across different suppliers

Three suppliers have separate contracts, different support teams and different recovery plans. All three rely on the same cloud layer. A disruption there could remove several services at once, including the tools the organisation expects to use to coordinate recovery.

Counting supplier names does not establish diversification. The useful question is which failure conditions would affect those suppliers together, and whether their alternatives remain available under those conditions.

APRA and ASIC's 27 August 2026 roundtable insights highlight shared dependencies as a source of wider disruption. The exercise below is an original scenario method, not a claim that a particular cloud provider is unsafe or that every common dependency must be removed.

Specify the shared layer

“Cloud outage” is too broad to produce a useful discussion. An unavailable application environment, a regional infrastructure disruption and a failure of management or identity services may have different effects.

Ask the technology owner to describe the dependency in terms the service owners can use. Which functions rely on it during normal operation? Which rely on it only when changing configuration, adding capacity or recovering? What is known, and what is still a supplier assertion?

The Australian Signals Directorate's cloud computing resources provide guidance on cloud security roles and responsibilities. Use the relevant material alongside service-specific architecture and test evidence. A generic cloud assurance statement does not describe every customer's configuration.

Work a fictional three-supplier scenario

A fictional financial institution uses Supplier A for a customer workflow, Supplier B for document access and Supplier C for incident coordination. All depend on a common infrastructure layer in the scenario. No real supplier, architecture or incident is represented.

The customer-workflow provider has a recovery environment in another region. The document provider stores backups separately but needs its management tools to restore them. The coordination provider offers a web-based incident workspace.

The initial claim is that each supplier has a continuity plan. The exercise tests a more precise proposition: can the institution maintain its required service and coordinate recovery when the shared layer is unavailable to all three?

Begin by separating confirmed facts from assumptions. If the team does not know whether Supplier B's restore process depends on the affected layer, that uncertainty is part of the exercise result. Do not quietly assume independence to keep the scenario moving.

Use two variants rather than one sweeping failure

In the first variant, the scenario removes a defined regional service. Ask which suppliers remain usable, which recover elsewhere and what has been tested for the relevant configuration.

In the second variant, keep some running systems available but remove a shared administrative dependency needed to start recovery or change access. This tests whether a geographically separate environment still depends on a common management or identity path.

These are illustrative variants. The technology team should validate their plausibility for the actual services before presenting them as evidence about the institution's exposure.

A useful result may be that one variant causes little disruption while another blocks recovery. That distinction is more informative than labelling the whole cloud provider a single point of failure.

Trace combined consequences

Assess each supplied service, then assess the combined effect. Supplier A's outage may stop new work. Supplier B's outage may prevent staff from retrieving documents needed for the manual process. Supplier C's outage may remove the place where the incident team normally assigns actions.

Taken separately, each workaround might look adequate. Together, the workarounds may compete for the same people or depend on another affected service.

Ask the service owners to walk through a single customer case using the proposed alternatives. Where is the information obtained? Who records the decision? How does the next person receive it? How will the work be reconciled later?

Keep approved critical-operation tolerances and obligations in view. This exercise informs the organisation's CPS 230 work; it does not establish a new universal outage threshold.

Compare options by feasibility

The team may identify several ways to reduce exposure. Compare them against the failure being tested.

A separate region may help with a regional disruption. Check the dependencies required to reach, operate and recover there; do not assume geography creates full independence.

A second supplier may provide an alternative service. Check whether it uses the same affected layer and whether people, data and contractual capacity are ready for an actual switch.

A limited manual process may maintain a defined part of the operation. Check capacity, access to information, controls and reconciliation. A spreadsheet stored in the unavailable environment is not an independent fallback.

An offline coordination method may help the incident team communicate and assign actions. Check that contact details, decision authority and necessary records can be accessed securely when normal tools are unavailable.

Accepting a constrained dependency may be the available decision for a particular exposure. That decision needs clear consequences, accountable review and any required mitigation; it does not mean the dependency has been removed.

Multi-cloud designs can introduce cost, complexity and new dependencies. Assess those trade-offs rather than treating the label as proof of resilience.

Use a scenario worksheet that records evidence

For each variant, record:

1. The exact shared component or capability assumed unavailable.
2. The suppliers and internal services affected, with evidence for each link.
3. The customer or operational consequences, including combined effects.
4. The fallback steps and the people, access and information each requires.
5. The test evidence supporting those steps, including configuration and date.
6. The unanswered questions, their owners and the decision they affect.
7. The proposed improvement and how it will be demonstrated.

This is an editorial worksheet. It should be adapted to the institution's architecture and decision process rather than completed as a generic form.

Test the smallest consequential gap

In the fictional exercise, the incident team discovers its alternative coordination plan is stored only in Supplier C's workspace. The immediate action is to establish an approved, securely accessible alternative and test it during a controlled loss-of-access exercise.

A separate action goes to Supplier B to clarify the restore dependency. The team does not claim the backup is unusable; it records that the relevant recovery path has not yet been demonstrated.

That separation matters. One finding can be resolved locally, while the other requires supplier evidence and perhaps a wider design decision. Keep both visible until their acceptance criteria are met.

For a different form of correlated exposure, the supplier-cohort example examines how multiple small providers can be affected by the same disruption.

For a first exercise, choose a shared dependency you can describe accurately. Ask what fails together, then test whether the fallback still has the people, access and information it needs.