SOCI Compliance Didn’t Protect You. Wednesday Proved It.
If your organisation operates in transport, banking, energy or communications, and you have signed off on a Security of Critical Infrastructure Act compliance program in the last two years, Wednesday’s Telstra outage is a direct challenge to what you thought that sign-off meant.
The Guardian’s reporting frames it as a story about single points of failure and national connectivity dependence, which it is. For directors in SOCI-regulated sectors there is a less comfortable version. A Telstra timekeeping server failed for five hours, and rail networks stopped, traffic management fell over and eftpos went down behind it. If your sector was in that blast radius and there is a SOCI-compliant risk management program sitting in a board paper somewhere, the fair question is what it bought you.
The Gap Between Attestation and Resilience
The SOCI Act and its associated rules require regulated entities to identify critical assets, assess risks, and implement risk management programs. The intent was genuine: to lift baseline resilience across the sectors Australians depend on. The execution has followed a predictable path.
Compliance programs get built to satisfy the obligation. Consultants are engaged. Registers are populated. Risk frameworks are documented. Board papers are tabled. Attestations are signed. The program exists, it is defensible, and leadership moves on.
What Wednesday exposed is that documentation is not architecture. A compliant risk register listing “upstream telco dependency” as a managed risk is not a fallback, and on the day, rail, traffic management and payment terminals all discovered they did not have one.
None of those operators missed something obscure. Telstra connectivity is so foundational to these systems that treating its absence as a live scenario feels academic right up until the morning it happens, and that is the actual problem. SOCI programs have been built around the risks that feel manageable. The unthinkable ones are where the exposure sits, and they are the ones nobody wants to model, because modelling them produces expensive answers.
Who Owns the Dependency Risk?
There is a governance question here that boards have not been asked clearly enough: when your critical operation depends on another SOCI-regulated entity’s infrastructure, who owns the resilience obligation?
Telstra is a regulated telecommunications carrier. Rail operators are regulated critical infrastructure. Payment systems operators are regulated critical infrastructure. Each of them has a risk management program. None of those programs, individually, required anyone to answer the question: what happens to my operation when the entity above me in the dependency chain fails for half a day?
The SOCI framework has sector-specific rules and a coordination mechanism through the Department of Home Affairs. What it has not produced is a tested answer to cascade failure across sectors. And remember what this was: not an attack, not a sophisticated actor, a timekeeping server. Resilience architecture that cannot absorb five hours of peacetime outage from one upstream provider will not absorb a sustained, deliberate disruption.
Regulators tend not to say that, having an institutional interest in defending the framework they administer, and the vendors who sold the compliance programs are unlikely to volunteer it either. So: the cross-sector dependency mapping SOCI was meant to produce has not turned into cross-sector resilience planning that would survive contact with a real event.
The Board Question Nobody Is Asking
Most boards in SOCI-regulated sectors received a briefing at some point in the last two years confirming that their organisation’s critical infrastructure risk management program was in place. Some received a second briefing confirming it had been updated. Very few received a briefing that answered this question: name the three upstream dependencies that, if they failed simultaneously or sequentially, would make our compliance program irrelevant.
That question should have been asked two years ago. It can still be asked at the next meeting.
Answering it is governance work rather than a technical exercise, because it turns on a distinction boards routinely collapse: compliance is satisfying a regulatory obligation, resilience is the operational capacity to keep critical functions running or get them back. Related, not the same, and Wednesday measured the distance between them fairly precisely.
There is a second, more awkward review to run. Five hours of disruption to train movements and payment infrastructure is not a minor event, and whether your organisation’s response held up — or quietly revealed capability gaps the compliance program assumed were covered — deserves a candid internal look rather than a post-incident report written to demonstrate composure.
What This Means for Your Next Board Cycle
SOCI reviews are a standing item on most regulated-sector agendas now. It is the framing of those reviews that needs to move: from “are we compliant?” to “does this program reflect how we actually fail?” In a surprising number of organisations those two questions have different answers, and only one of them gets asked.
In practice that means requiring management to table a dependency map one level upstream of your own assets, naming the external operators, networks and services that would compromise your critical functions if they were unavailable for four to eight hours. The map earns its keep by driving scenario testing, not by becoming three more rows in a register.
Until that work exists, the compliance program is incomplete whatever the attestation says. And the outage will duly be reviewed, reported on and cited in an updated guidance note from Home Affairs or ASD in due course. That is the regulatory cycle working as designed. The operational cycle runs on its own schedule, and the next failure will not wait for the guidance note.