When Your Failover Fails: Business Continuity and the Mobile-Outage Trap

This morning a single fault at Telstra took out mobile and data for millions of Australians from around 4:30am. Regional Victoria’s entire V/Line train network stopped. Trains in NSW ran late, Eftpos terminals stopped taking payment, and some people could not get a call through to Triple Zero. Telstra traced it to a timekeeping fault in its network nodes, a time-synchronisation failure in servers at its Sydney and Melbourne data centres, and by around 10am it had roughly 90% of calls and data back (SBS News).

So here is the question worth sitting with. If that outage had hit your primary internet connection instead, what would you have switched to, and would this morning have taken that down as well?

The failover that wasn’t

When I review a continuity plan during an audit, the connectivity section nearly always says the same thing: if the fixed line or NBN drops, we fail over to mobile. On paper that reads like redundancy. It only works if the primary and the backup can fail separately, on their own, and a carrier-level outage is precisely the event that removes that separation. If your fixed line and your mobile backup are both Telstra, or both ride the same tower or the same upstream network, one fault takes both down in the same instant. You have two connections and one dependency.

We ran into the same shape of problem writing about cloud data, where owners assume their SaaS provider is also their backup: a backup that shares a dependency with the thing it is protecting is not much of a backup. Different resource this time, connectivity rather than data, but the same blind spot. An assumption no one had tested, until an outage tested it for them.

What a business continuity plan is

A business continuity plan is your written, tested answer to one question: when something you rely on fails, how do you keep the critical parts of the business running? The word there is when. A good plan does not try to prevent every disruption, because you cannot stop a data centre losing sync, but it keeps that disruption down to an inconvenience instead of a lost day of trade and an emergency call that will not connect.

Most businesses I see do have a plan. The gap is that the dependencies were never mapped in any real detail, and the failovers were never run. A plan that has sat untouched since it was written records what someone expected to happen. Whether it holds up is a separate question, and the morning of an outage is a poor time to go looking for the answer.

Map the dependencies you’d lose in an outage

This morning doubles as a checklist. Each of the things below stopped working for someone today because, out of sight, it leaned on the one carrier.

• Connectivity: your primary internet and its failover. Are they actually on different networks, or the same one twice?
• Payments: card and Eftpos terminals went down today. If you cannot take payment, can you still trade, and do staff know the manual fallback?
• Phones: VoIP and hosted phone systems run over your internet, so when it drops your main line goes with it. How do customers and staff reach each other then?
• Cloud apps: accounting, bookings, CRM, email. No connectivity, no access. What is the minimum you would need cached or offline to keep going for a few hours?
• People and access: whole train networks stopped today, so staff could not get in, and badge and door systems that phone home can fail the same way. How does the team operate if half of them are stuck?

Redundancy that survives a carrier outage

Real redundancy means a backup that does not lean on the component that just failed. A few options a small or medium business can afford:

• A second carrier on a different network, not a second SIM on the same one. If your fixed line is on one network, put the mobile backup on another, and check whose network your “different” provider is actually reselling.
• Satellite as a last resort. Services like Starlink never touch the terrestrial mobile network, which is the whole point of having them.
• An offline payment fallback: a manual card-imprint process, a documented “we will invoice you”, or a terminal on a different carrier’s SIM.
• Cached or downloadable critical data, so today’s bookings, job sheets and key contacts survive a few hours offline.
• A way to reach each other that does not depend on one network, because if everyone is only contactable on the same downed carrier, you cannot coordinate the response.

None of this is expensive. What matters is that the backup is independent of the primary, and that someone has run it at least once while things were calm.

Where ISO 22301 and ISO 27001 come in

Business continuity has its own international standard, ISO 22301, and it is built around this exact problem: work out which activities are critical, map what they depend on, decide how long you could last without each one, then put tested arrangements in place to recover inside that window. Two parts carry the weight, the business impact analysis and the testing. A plan you have never rehearsed is only a guess about how you would cope.

If you already hold ISO 27001, you have a head start. Availability sits alongside confidentiality and integrity as one of the three things information security exists to protect, and Annex A carries controls for business continuity and ICT readiness. The standard expects you to plan for keeping your information and services available through a disruption, and then to test that plan. This morning is the scenario those controls are written for. It follows the same line as the ACSC’s advice on protecting, reporting and recovering from incidents: settle your response before you need it.

The same shared-dependency problem now applies to AI. Several apparently separate agents may rely on one model provider, so one disruption can remove them all. See our practical guide to AI business continuity and AI-agent outages.

The takeaway from today

One time-sync fault this morning halted trains, stopped card payments and, for some people, blocked calls to Triple Zero. Something like it will happen again, to some carrier, at some point, and you cannot prevent that. What is in your hands is whether the failover you are counting on is real or only assumed. Try the test now rather than during the next outage: write down what you would switch to if the main connection died this second, then ask whether this morning’s fault would have taken that down too. If it would have, the second connection was never really a backup.

Talk to us about a continuity plan that has been tested

At Streamline we build business continuity into a company’s management system in a way that holds up. We map the dependencies that actually matter, design failovers that do not share a network, and run the independent internal audits (clause 9.2) that show the plan works before an outage puts it to the test. It sits within our cyber and information security advisory. Email hello@streamline.business, or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

Related: continuity is harder again when the disconnection is deliberate. ASD’s CI Fortify guidance asks critical infrastructure operators to be able to run isolated for three months, which has direct consequences for anyone supplying them.