SOCI Act Compliance Gaps: Building Operational Readiness

Through our work supporting organisations operating critical infrastructure environments, we have seen a consistent pattern: many operators have completed the required SOCI documentation, but have not tested whether their people, processes, and technology can perform when an incident occurs.

Then an incident happens, and the 12-hour clock starts – and it becomes clear, in real time, that nobody had actually rehearsed who calls whom, what “becoming aware” means for a distributed OT environment, or how a plant engineer’s phone call to a shift supervisor is supposed to turn into a report to the ASD before the deadline passes.

This is the gap that matters under SOCI: not the gap between what’s written and what’s true, but the gap between what’s documented and what’s operational. And it’s usually invisible until the moment it’s tested.

If you already understand the SOCI Act requirements and want to quickly assess your current position, you can skip ahead and go straight to the SOCI Act Readiness Check →. For those looking to understand the gaps behind the checklist, the following sections provide the context and practical guidance based on our experience.

The Hidden Risks Behind SOCI Compliance: What We See In Practice

SOCI obligations are frequently treated as a compliance project with a finish line – register the asset, write the CIRMP, file it. In practice, the Act imposes a standing operational capability, not a one-off deliverable, and the two are not the same thing.

That gap has just become more consequential. As we cover in our piece on Australia’s Enhanced CIRMP Rules (2026), the updated rules that commenced in June 2026 shift CIRMP from a principles-based framework to one requiring structured, evidence-based controls across cyber, personnel, supply chain, and physical security, with energy operators facing some of the heaviest impact, including a mandated AESCSF maturity uplift. A CIRMP that was defensible under the old regime won’t automatically clear the new bar.

This changes the stakes of the risk patterns below. A capability gap that was previously a soft finding under a principles-based regime is now a gap against specific, prescriptive requirements – the kind a regulator can point to directly.

Through our work supporting critical infrastructure operators, three risk patterns show up consistently in operators who look compliant on paper:

Reporting capability that only exists in theory. A CIRMP can specify a 12-hour critical incident reporting obligation and a 72-hour significant incident obligation without anyone having tested whether the organisation can actually detect, triage, and escalate a real OT event inside those windows. The obligation is a capability requirement disguised as a timeframe.

For example, a critical infrastructure operator can have a documented incident escalation process and clear SOCI reporting timeframes defined within its CIRMP. However, during a tabletop exercise involving a simulated OT network compromise, it often becomes clear that the reporting pathway relied on assumptions rather than tested processes. Organisations we have worked with often seem to have a reporting procedure – but not yet a rehearsed reporting capability that holds up under the pressure of an actual event.

A CIRMP written for the auditor, not the asset. Generic risk management programs that address cyber security in isolation – without personnel, supply chain, and physical/natural hazard risk specific to the actual asset – satisfy the letter of the obligation while leaving the operator unable to answer basic questions when a regulator or incident responder asks them.

In our SOCI Act & AESCSF Compliance for Critical Energy Infrastructure engagement, an integrated energy operator running generation, wind, and storage assets across multiple sites had OT environments that had evolved organically over time – inconsistent architectures, limited documentation, and uneven cyber maturity from one site to the next. On paper, governance existed. In practice, the risk framework hadn’t been built around what each site actually looked like operationally. Several sites didn’t even have accurate, current network diagrams – meaning the organisation couldn’t reliably see device connectivity or communication pathways, let alone assess risk against them. A CIRMP produced without that site-specific grounding can satisfy a checklist while leaving genuine questions – “what’s actually connected to what, and what happens if it fails?” – unanswerable when it counts.

OT blind spots hiding behind IT assurance. Boards and executives often receive assurance based on IT security posture, while the OT/ICS environment – the actual critical infrastructure – has limited segmentation, limited logging, and no real anomaly detection. The Register lists the asset; the risk sits in the control system running it.

For instance, the same operator had multiple stakeholder groups: IT, OT, Asset Management, and Cyber Security, each holding a partial view, with competing priorities that made it hard to align operational reality with regulatory obligation. Assurance reported upward often reflected IT security posture, while the OT/ICS layer running the physical plant sat with far lower visibility. Bringing these teams into a single, unified OT architecture was itself a core part of the remediation, underscoring how easily a board can be told “we’re secure” based on IT metrics while the control systems actually running turbines, storage, and generation assets remain a governance blind spot.

Each of these is a finding that costs nothing to have – until the day it’s needed and isn’t there. Regulators and incident responders don’t discover these gaps in an audit; they discover them in the middle of an incident, which is the most expensive possible time to learn about them.

Building Operational SOCI Readiness

Closing this gap means treating SOCI as an operating discipline rather than a documentation exercise. That shift shows up in a handful of concrete strategic choices:

Build evidence continuously, not retrospectively. Operators that can produce an annual CIRMP compliance report inside statutory timeframes are the ones who have been logging decisions, reviews, and exceptions as they happen – not the ones reconstructing a year of activity under deadline pressure.

Calibrate the CIRMP to the asset, not the template. A risk management program should reflect the actual dependencies, failure modes, and operational constraints of the specific critical infrastructure asset it governs — including personnel and supply chain risk, which are frequently the weakest and least examined parts of an otherwise cyber-focused program.

Rehearse the reporting pathway before you need it. The single highest-leverage readiness activity most operators skip is a tabletop exercise that walks a realistic OT incident scenario from detection through to a completed regulatory report, with the people who would actually be involved. It exposes ambiguity in escalation ownership faster than any policy review.

Tie classification and CIRMP review to change, not the calendar. New systems, new sites, and changes to ownership or operational structure should trigger a documented reassessment of asset classification and risk posture – not wait for the next scheduled annual review.

Extend the same rigour to OT as to IT. Asset inventory, network segmentation, and anomaly monitoring in the OT/ICS environment are not optional extensions of a SOCI program – for most registered critical infrastructure assets, they are the program.

A Practical Approach to SOCI Readiness

Practically, this means running readiness as a structured, evidence-based process rather than a document review:

Baseline against the real environment. Assess actual asset classification, CIRMP coverage, reporting capability, and OT visibility – not the intended state described in policy, but what would actually happen today.
Close governance and technical gaps in parallel. A CIRMP rewrite without OT segmentation and monitoring improvements leaves the technical risk untouched; technical controls without governance leave the organisation unable to evidence them.
Rehearse, then repeat. Run the incident reporting pathway as a live exercise, fix what breaks, and re-run it on a cadence – readiness decays without practice.
Keep it current. Treat every material operational, ownership, or architectural change as a trigger for reassessment, so the CIRMP never drifts far from the environment it describes.

This is the same underlying model Tier Sixteen applies across OT and critical infrastructure engagements: establish strong governance, secure the environment, maintain accurate asset visibility, and build the operational muscle to meet obligations under pressure — not just describe them on paper.

Where does your organisation actually stand?

Based on recurring readiness challenges identified across critical infrastructure environments we built a 15-point SOCI Act Readiness Check that scores your organisation across asset registration, incident reporting, your Risk Management Program, enhanced obligations, and OT-specific readiness – in about 90 seconds. No contact details required. Take the SOCI Act Readiness Check →