The dependency test: what would stop your business first?
When every system is labelled critical, resilience work becomes difficult to prioritise. A simple dependency test can expose where one failure is most likely to interrupt the business first.
By Revelate Systems
When a major technology outage makes the news, attention naturally goes to the failed service. The more useful question for another organisation is different:
If one dependency disappeared tomorrow morning, what would stop your business first?
The July 2026 telecommunications disruption was a timely reminder that a software defect or supplier issue can create serious operational consequences without being a cyber incident. Telstra's own updates described mobile service impacts and a related issue affecting some Triple Zero calls. The lesson is not to speculate about one provider. It is to recognise how quickly a technical dependency can become an operational problem.
For many organisations, the difficult part is not identifying a risk. It is deciding which risk deserves attention first.
The problem with calling everything critical
Ask a room of system owners which services are critical and the answer can quickly become: all of them.
Email is critical. Internet is critical. The finance platform is critical. Shared storage is critical. Identity is critical. The phone system is critical. A production application is critical.
That may all be true in a broad sense, but it does not create a useful order of work.
A resilience programme needs a way to distinguish between an important system and a dependency whose failure immediately blocks several important systems at once.
That is where a dependency test helps.
A practical five-question dependency test
Take one business service at a time and ask five questions.
1. What stops if this service fails?
Do not start with the server, appliance or cloud product. Start with the work people are trying to perform.
If the internet connection fails, can staff still take orders, access cloud applications or communicate with customers? If identity services fail, which applications become inaccessible? If shared storage is unavailable, which teams stop producing work?
The wider the operational impact, the higher the dependency deserves to sit in the review.
2. What else depends on it?
The obvious service is not always the real point of failure.
A cloud application may be healthy while staff cannot reach it because the internet connection is down. A remote-access platform may be available while identity is unavailable. A backup may exist while the credentials, network path or target storage required for recovery are inaccessible.
Map the chain, not just the product.
3. How quickly would you know it had failed?
There is a material difference between a monitored failure and a failure discovered when a customer calls.
For each critical dependency, identify who receives the alert, what the alert actually proves and whether the person receiving it can act.
A green dashboard is useful only if it is measuring the condition that matters to the business.
4. What is the first workable fallback?
The fallback does not need to recreate normal operations perfectly. It needs to keep the most important work moving at an acceptable level.
That could be a secondary connection, a documented manual process, an alternate communications path, a recovery environment or a controlled way to redirect work.
The important question is whether the fallback is specific enough that somebody can use it under pressure.
5. Who decides to use the fallback?
This is the question that technical reviews often miss.
A workaround can exist and still be useless if nobody knows who is authorised to activate it. Teams can lose valuable time waiting for approval, debating whether the incident is serious enough or assuming another supplier owns the decision.
A recovery target without a decision owner is incomplete.
Score the gap, not the size of the system
A simple review can score each dependency against the five questions above.
| Dependency | Business impact | Dependency chain understood | Failure detected quickly | Fallback tested | Decision owner clear |
|---|---|---|---|---|---|
| Internet access | High | Partial | Yes | No | Partial |
| Identity platform | High | No | Yes | No | No |
| Shared storage | High | Yes | Yes | Partial | Yes |
| Cloud phone service | Medium | Partial | Supplier-led | Yes | Yes |
The table is not a compliance framework and it does not replace a formal business impact analysis. Its value is prioritisation.
The first work item may not be the biggest platform or the most expensive system. It may be the dependency with high business impact, several downstream services, weak detection and no tested fallback.
That is a much more useful starting point than a generic list of infrastructure improvements.
Backups need the same dependency thinking
Backup reports are a good example of why this matters.
A successful job tells you that a backup process completed. It does not, by itself, prove that the business can recover the service within the time it expects.
Recovery can depend on:
- access to the backup platform;
- administrative credentials;
- clean target infrastructure;
- network connectivity;
- available storage capacity;
- application knowledge;
- recovery order;
- a person authorised to make the call.
A useful recovery review follows those dependencies through to a tested outcome. If the restore path has not been exercised, the organisation has less evidence than the green backup report might suggest.
Cloud changes the chain, not the need to understand it
Australia's Whole-of-Government Cloud Computing Policy, which took effect on 1 July 2026, is written for Australian Government agencies. Private organisations are not bound by that policy simply because they use cloud services.
The broader operational lesson is still relevant: cloud decisions need clear ownership, risk visibility and an understanding of service dependencies.
Moving a workload to cloud infrastructure may remove one local hardware dependency while increasing reliance on identity, connectivity, provider access or a particular integration. That can be a good trade, but it should be a deliberate one.
The question remains the same: what stops if this dependency fails, and what happens next?
What to do with the result
Once the highest-risk dependency is visible, resist the urge to turn the review into a 40-item transformation programme.
Choose the smallest piece of work that materially improves the failure path. That might mean:
- documenting the dependency chain;
- fixing monitoring so the right person knows quickly;
- assigning a decision owner;
- validating the first fallback;
- testing one real recovery path.
Then repeat the test for the next dependency.
For organisations that want a structured view of these gaps, an Infrastructure Review can help establish the current state and practical priorities. Where the issue is ongoing visibility, documentation and operational control, Operational Services may be the more relevant next step.
Resilience becomes useful when it creates an order of work
Operational resilience is easy to discuss in broad terms. The harder and more valuable task is deciding what should be improved first.
Start with the dependency most likely to stop important work. Follow the chain. Check how quickly the failure would be detected. Confirm the fallback. Name the decision owner.
If those answers are unclear, you have found a practical place to begin.
Revelate Systems works with organisations across Brisbane, the Gold Coast and South East Queensland to review infrastructure dependencies, recovery readiness and the operating controls around critical technology. Start a conversation if you need a clearer view of where to focus first.