Why AI is now a SOCI Act question
The Security of Critical Infrastructure Act 2018 (Cth) is Australia's framework for protecting the assets the country cannot function without: power, water, transport, hospitals, payment systems, food distribution, and data infrastructure. It is administered by the Cyber and Infrastructure Security Centre (CISC) within the Department of Home Affairs, and it imposes positive security obligations on the responsible entities that own or operate those assets.
None of the Act's core provisions mention artificial intelligence. They do not need to. The central obligation, the Critical Infrastructure Risk Management Program, is deliberately technology neutral: responsible entities must identify and manage each material risk to the availability, integrity, reliability, and confidentiality of their critical infrastructure asset. When an AI system schedules maintenance for a substation, triages patients, screens transactions, or optimises a water treatment process, that AI system is part of how the asset operates, and the risks it introduces are material risks the program must cover.
The same logic Australia's prudential regulator applied to banks and insurers in its April 2026 AI letter, that existing frameworks already apply to AI risk and boards are accountable for it, applies with equal force under the SOCI Act. The difference is that SOCI reaches sectors APRA does not: energy, water, transport, hospitals, universities, defence industry, space, and food and grocery.
What the SOCI Act requires
The Act applies to responsible entities for critical infrastructure assets across 11 sectors: communications, data storage and processing, defence industry, energy, financial services and markets, food and grocery, health care and medical, higher education and research, space technology, transport, and water and sewerage. Three positive security obligations do most of the work:
- Asset registration. Providing details of the asset, its operators, and its direct interest holders to the Register of Critical Infrastructure Assets.
- Mandatory cyber incident reporting. Critical incidents must be reported to the Australian Cyber Security Centre within 12 hours; other significant incidents within 72 hours.
- The Critical Infrastructure Risk Management Program (CIRMP). A written, board-approved program that identifies and manages material risks across four defined hazard vectors.
The CIRMP Rules (LIN 23/006) commenced on 17 February 2023. Responsible entities for the prescribed asset classes needed a written program in place by August 2023, and compliance with a recognised cyber security framework, such as the Essential Eight, ISO 27001, the NIST Cybersecurity Framework, or the AESCSF for the energy sector, by August 2024. The regime is now fully in its operational and enforcement phase: CISC has moved to a firmer compliance posture, has run audits, and civil penalties apply.
The four hazard vectors, and where AI enters each one
The CIRMP must establish processes to identify and manage material risks across four hazard vectors. AI has a concrete pathway into every one of them.
1. Cyber and information security hazards
AI cuts both ways here. AI-enabled attackers are raising the tempo and sophistication of intrusions against critical infrastructure, which is the threat side. But the exposure side is what the CIRMP owner controls: every AI system connected to the asset is new attack surface. Models can be poisoned, prompts can be injected, agentic AI tools can be manipulated into taking actions their operators never intended, and the credentials AI systems hold are targets. If an AI agent can read from or write to systems supporting the critical asset, the access it holds is part of the asset's cyber risk profile. Least-privilege discipline for nonhuman identities, covered in our guide to AI agent access control, is the practical control.
2. Personnel hazards
The personnel vector traditionally covers trusted insiders: vetting the critical workers who can access critical components. Staff use of ungoverned AI tools now belongs in the same analysis. An engineer pasting network diagrams into a public chatbot, an operations team adopting an unapproved AI assistant that retains prompts, or a contractor using a personal AI account for rostering all move sensitive information about the critical asset outside the entity's control. Shadow AI is a personnel hazard in exactly the sense the Rules contemplate: a pathway by which people with legitimate access create unauthorised exposure.
3. Supply chain hazards
This is the vector where AI concentration risk lands. Most AI capability arrives through vendors: foundation model APIs, SaaS products with embedded AI, integrators, and managed service providers. The CIRMP must identify material risks of disruption and unauthorised access arising through suppliers, and AI suppliers exhibit precisely the opacity regulators keep flagging: entities often cannot see what models a vendor uses, where inference runs, what data is retained, or how quickly a vendor-side change can alter system behaviour. A small number of upstream model providers sit beneath a large share of AI products, so a single upstream failure or compromise can propagate widely. AI vendors supporting the critical asset belong in the supply chain risk assessment with the same rigour as any other material service provider.
4. Physical and natural hazards
Where AI participates in operational technology, optimising load, controlling processes, scheduling physical maintenance, or informing dispatch decisions, a model failure can become a physical event. Unpredictable model behaviour in a control loop is not a hypothetical: it is the exact category of dynamic, hard-to-assure system change that traditional change management struggles with. If AI outputs feed decisions about the physical operation of the asset, the physical hazard analysis must account for the failure modes of that AI.
The board attestation is where AI risk lands
Under section 30AG of the Act, a responsible entity must give the regulator an annual report on its CIRMP within 90 days of the end of each financial year, and that report must be approved by the board or governing body. The report must declare that the program is up to date, disclose hazards that had a significant impact during the year, record variations made to the program, and assess whether the program was effective.
That approval is a personal accountability moment for directors. A board cannot honestly attest that material risks to the asset are identified and managed if nobody has inventoried the AI systems that touch the asset. The logic is identical to the expectation APRA set for financial services boards: at minimum, an inventory of AI tooling and use cases with named ownership across the lifecycle. For SOCI entities the inventory question is scoped by the asset: which AI systems, including vendor-embedded AI, can affect the availability, integrity, reliability, or confidentiality of the critical infrastructure asset, what can each one access, and who owns each one. Our guide to the AI inventory as a regulatory requirement covers how to build that artefact once and reuse it across regimes.
The 2024 and 2025 reforms tightened the frame
The Security of Critical Infrastructure and Other Legislation Amendment (Enhanced Response and Prevention) Act 2024 made three changes that matter for AI risk. First, it clarified that data storage systems holding business-critical data form part of the critical infrastructure asset, which pulls the data platforms that feed and log AI systems inside the protected boundary. Second, it gave the regulator power to direct an entity to remedy a deficient risk management program, converting a paper obligation into an enforceable quality standard. Third, telecommunications security was brought into the SOCI framework, with the Telecommunications Security and Risk Management Program Rules taking effect from 4 April 2025.
The direction is one way: broader asset definitions, firmer enforcement, and more explicit expectations that the risk management program reflects how the asset actually operates today, not how it operated when the program was first written.
Folding AI into the CIRMP: a practical sequence
- Inventory AI against the asset. List every AI system, including vendor-embedded and shadow AI, that can affect the critical infrastructure asset. Record owner, purpose, access, and data touched.
- Classify by material risk. For each system, assess severity, scale, and reversibility of failure against the asset's availability, integrity, reliability, and confidentiality.
- Map each AI risk to a hazard vector. Assign controls in the vector where the risk lives: access management and monitoring under cyber, acceptable-use and vetting under personnel, vendor assessment and concentration analysis under supply chain, and failure-mode analysis under physical.
- Update the supplier register. Add AI vendors and upstream model dependencies to the supply chain risk assessment, with contractual visibility into model changes, data handling, and incident notification.
- Control nonhuman access. Give AI systems and agents their own identities, least-privilege scopes, and revocation paths. Identity and access management built for humans does not automatically govern AI actors.
- Evidence it for the annual report. Keep the AI inventory, risk assessments, and control mappings current so the board can approve the annual attestation on an accurate record, and variations to the program are documented as the Act requires.
Where this intersects with the rest of the Australian frame
SOCI does not operate alone. An APRA-regulated bank or insurer that is also a responsible entity for a financial services critical asset answers to both regimes, and the artefacts overlap almost completely: an AI inventory, ownership and accountability, supplier risk visibility, and board-level reporting satisfy CPS 230, the APRA AI letter, and the CIRMP attestation from a single evidence base. The Voluntary AI Safety Standard's guardrails on accountability, risk management, and recordkeeping describe the same machinery. Building it once, well, is the efficient path, and it is the approach regulators are converging on: AI governance as an operating capability rather than a document set.
Primary sources: Security of Critical Infrastructure Act 2018 (Cth) | CISC CIRMP fact sheet | MinterEllison on the CIRMP Rules | KWM on CIRMP annual reports
