Thought Leadership
On Wednesday 8 July 2026, a software defect in Telstra's time-synchronisation infrastructure took the network down for the best part of twelve hours. Regional trains in Victoria stopped running. EFTPOS terminals failed for tens of thousands of businesses. Court hearings were missed, EV chargers went dark, and millions of devices dropped to SOS-only mode. By the time engineers had traced and isolated the fault, the disruption had already reached well past Telstra's own customer base and into the operations of organisations that may have not listed a telco outage as their most pressing risk.
That's the detail worth building a response around. None of the organisations hit hardest - a rail operator, a payments processor, a courts system - are telcos, and none of them can fix a fault sitting in someone else's data centre. What they can control is how their own teams behave in the minutes after that fault lands.
The question worth asking isn't why Telstra failed
For business continuity and risk leaders, the instinct after a high-profile vendor failure is to pick apart what the vendor got wrong. That's a reasonable question for a regulator or a board to ask of Telstra directly, but it's not the question that improves your own organisation's position before the next outage, wherever it comes from. The more useful question is how cleanly your own teams absorbed the shock: whether payments failed over the way they were supposed to, whether customers got an accurate message before rumour filled the gap, and whether operational leadership could make a call in the first ninety minutes without waiting on a chain of approvals that assumed normal connectivity.
Australia's Security of Critical Infrastructure (SOCI) Act already asks organisations across eleven sectors to document exactly this kind of dependency risk. A Critical Infrastructure Risk Management Program is meant to cover cyber, physical, natural, and supply chain hazards, reviewed annually with the board accountable for its adequacy. An engineering fault in a third-party network sits squarely inside that scope. What the framework doesn't guarantee is that the organisation has ever tested its response to it, because the exercising obligations that come with SOCI are concentrated on cyber-driven scenarios. A dependency failure with no malicious actor behind it can be fully documented and still never have been rehearsed.
Capability, not just compliance
A compliance checklist tells you a risk has been identified and assigned an owner. It doesn't tell you whether that owner's team can execute under pressure, at short notice, while the root cause sits outside their control. Static, annual continuity plans tend to leave that gap wide open, because they're built to demonstrate coverage on paper rather than to prove a team can respond. The pressure of a real incident behaves differently to a slide-deck walkthrough: decisions have to be made fast, across functions that don't normally coordinate in real time, and with information that's incomplete.
Closing that gap means treating resilience as something an organisation practises, not something it files. Teams that have rehearsed a dependency failure together know, without needing to check a document, who talks to customers, who talks to regulators, and who has the authority to act while the cause is still unclear. That's not a function of how detailed the plan is. It's a function of how many times the team has run the scenario.
Turning the plan into response capability
Closing the gap between a documented risk and a rehearsed one doesn't require a large program to get started. It works best as a sequence, moving from individual practice to full team coordination.
Start with the dependency you don't control. Pull one item straight off your risk register: the third-party dependency with no mandated exercise attached to it, whether that's a telco, a cloud provider, or a payments platform. That's the scenario worth rehearsing first, precisely because nothing is currently forcing anyone to test it.
Run it solo before you run it as a team. A single-player Microsimulation puts one person through that scenario's decision points in a few minutes, with no scheduling or team coordination required. It's the fastest way for a new team member to get up to speed on the response playbook, or for an experienced leader to sharpen judgment before stepping into a live exercise.
Bring the cross-functional team in next. A multiplayer Microsimulation runs payments, communications, and operational leadership through the same live scenario together, so the handoffs between them get tested directly rather than assumed on paper. This is where the gaps a written plan can't catch, like who has authority to act while the cause is still unclear, could surface.
Repeat it on a cadence, not once a year. The coordination only becomes instinctive through repetition. A team that's run a dependency failure scenario multiple times responds differently under real pressure than one working from a document they read twelve months ago.
Nobody could have rehearsed the specific fault in Telstra's timing servers in advance. The pattern behind it, a documented dependency risk that had never been tested under real pressure, is the kind of gap worth closing before it shows up somewhere else in your own operation.
The easiest place to start is on your own. A single-player Microsimulation puts you through a realistic disruption scenario in a few minutes, no team coordination required, so you can see what the decision-making feels like before you bring the rest of your organisation into it.
Capability Building
Business Resilience
