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 this as a story about single points of failure and national connectivity dependence. It is that. But for board directors and executives in SOCI-regulated sectors, the more uncomfortable story is this: rail networks stopped. Traffic management systems failed. Eftpos payments went down. All because a Telstra timekeeping server failed for five hours. If your sector was affected, and you have a SOCI-compliant critical infrastructure risk management program sitting in a board paper somewhere, you need to ask what it actually 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 that lists “upstream telco dependency” as a managed risk is not the same as having a viable fallback when that dependency fails. Rail operators did not have one. Traffic management systems did not have one. Payment terminals did not have one.
This is not a criticism of those operators for missing something obscure. Telstra connectivity is, for many of these systems, so foundational that treating it as a genuine failure scenario feels almost academic — until it isn’t. That is precisely the problem. SOCI compliance programs have been built around risks that feel manageable, not risks that feel unthinkable. The unthinkable ones are the ones that matter.
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 cross-sector coordination mechanism through the Department of Home Affairs. What it has not produced is a serious, tested answer to cross-sector cascade failure. Wednesday was not a cyber attack. It was not a sophisticated threat actor. It was a timekeeping server. If the resilience architecture cannot absorb a five-hour outage from a single upstream provider in peacetime, it will not absorb a sustained, targeted disruption.
Regulators will not say this plainly because their institutional interest is in defending the framework they administer. Vendors will not say it because they sold the compliance programs. We will say it: the cross-sector dependency mapping that SOCI was supposed to produce has not translated into cross-sector resilience planning that would survive a real test.
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. It should be asked now.
The answer is not a technical exercise. It is a governance one. It requires boards to distinguish between compliance — the act of satisfying a regulatory obligation — and resilience — the operational capacity to maintain or restore critical functions under adverse conditions. These are related but they are not the same, and Wednesday demonstrated the distance between them.
Boards in affected sectors also need to examine their incident response posture honestly. Five hours of outage affecting train movements and payment infrastructure is not a minor disruption. The question of whether your organisation’s response to Wednesday was adequate, or whether it revealed capability gaps your compliance program assumed were covered, deserves a candid internal review — not a post-incident report designed to demonstrate composure.
What This Means for Your Next Board Cycle
SOCI compliance reviews are now a standing item on most regulated sector board agendas. The framing of those reviews needs to change.
The right question is not: are we compliant? It is: does our compliance program reflect how our operation actually fails? Those are different questions, and in too many organisations they have different answers.
Specifically, boards should be requiring management to table a dependency map that goes one level upstream from their own assets — identifying which external operators, networks and services, if unavailable for four to eight hours, would compromise the organisation’s ability to deliver its critical functions. That map should drive scenario testing, not just risk register entries.
If that work has not been done, the compliance program is incomplete regardless of what the attestation says. Wednesday is not a prompt to do more documentation. It is a prompt to test whether the documentation reflects reality.
The Telstra outage will be reviewed, reported on, and eventually cited in an updated guidance note from Home Affairs or the ASD. That is the regulatory cycle. The operational cycle is different: the next failure will not wait for the guidance note.