The Security of Critical Infrastructure Act has a way of arriving on an executive agenda suddenly. A contract asks for evidence of compliance, a regulator letter lands, or the board reads about penalties and asks where the organisation stands. Then someone discovers the Act is long, the definitions are technical, and most of the commentary is written by lawyers for lawyers.
Here is the plain-English version: what the regime covers, what it asks of the organisations it captures, and where the practical work usually sits. It is a starting map, not legal advice; whether your assets are captured is a question worth confirming properly.
Who the Act captures
SOCI does not apply to sectors wholesale. It applies to specific classes of critical infrastructure assets, and to the responsible entities that own or operate them. The sectors it draws from are broad: energy, water, communications, transport, health care, food and grocery, financial services, data storage and processing, higher education and research, defence industry and space. But within each sector, the Act defines particular asset classes, and obligations attach when your asset meets a definition, not simply because you operate in the sector.
That distinction matters in both directions. Organisations assume they are out of scope because they do not think of themselves as critical infrastructure, then discover their data centre arrangements or their role in a supply chain captures them. Others burn energy preparing for obligations that do not apply to them. Establishing which side of the line you sit on is step one, and it is usually a quicker exercise than people fear.
What captured entities actually have to do
The obligations arrive in layers, and not every layer applies to every asset.
- Register your asset. Responsible entities report ownership and operational information to the Register of Critical Infrastructure Assets, and keep it current.
- Report cyber incidents fast. Significant incidents must be reported within hours of becoming aware, with tight timeframes that assume you can detect and escalate quickly. If your incident process cannot get the right facts to the right person inside a day, that is a gap in itself.
- Run a risk management program. For many asset classes, the centrepiece obligation is a critical infrastructure risk management program: an ongoing, board-signed program that identifies and manages material risks across four hazard domains, cyber and information security, personnel, supply chain, and physical and natural hazards. An annual report on the program goes to the board for approval.
- Enhanced obligations for the most critical systems. A small set of assets declared systems of national significance carry additional requirements, such as incident response planning and exercises.
The cyber component of the risk management program is where most of the technical work concentrates, and the rules let you anchor it to an established framework, with the Essential Eight, ISO 27001 and equivalent frameworks among the recognised paths. If your security uplift is already aligned to one of these, SOCI compliance is largely about evidencing it. If it is not, the obligation is the forcing function.
Where organisations actually struggle
Having watched this play out, the hard parts are rarely the paperwork. They are the questions underneath it.
Personnel risk means knowing who has access to critical systems, whether their access matches their role, and whether it is removed when they leave. That is an identity governance question, and organisations without mature joiner, mover and leaver processes cannot answer it credibly.
Supply chain risk means knowing which vendors can touch your environment, including the remote access pathways into operational systems that were set up years ago for maintenance and never reviewed. In our OT and IoT work we put it as a board question: if you asked for a list of every vendor with remote access to your operational systems today, could anyone produce it?
And the cyber hazard domain increasingly runs through operational technology, the building systems, sensors, controllers and plant equipment that sit outside the corporate IT estate and outside most security programs. We wrote about that gap in more detail in why OT and IoT security can no longer sit outside your identity program.
In other words, a defensible risk management program is mostly built from disciplines that are valuable anyway: identity and access governance, vendor access control, asset visibility and a security uplift aligned to a recognised framework. SOCI turns them from good practice into obligations with board accountability attached.
A sensible sequence
For organisations starting from a letter, a contract clause or a board question, the path that works looks like this. Confirm whether your assets are captured and which obligations apply. Baseline your current state against the four hazard domains honestly, including the OT estate. Rank the gaps by consequence, then close them in a sequence your board can fund and follow, using the compliance deadline as the schedule rather than the strategy.
Move FWD works with organisations navigating exactly this: establishing what is connected, who and what has access, where the material risks sit, and what a board-ready program looks like. If SOCI has landed on your agenda and you want the practical version of where you stand, talk to us.