What does the SOCI Act mean for AI systems and AI data stores?
The Security of Critical Infrastructure (SOCI) Act 2018 captures AI by function, not by name: any AI system or AI data store that supports a critical infrastructure asset, or that holds business-critical data connected to one, must be brought inside the responsible entity's all-hazards Critical Infrastructure Risk Management Program (CIRMP) and managed against cyber, personnel, physical and supply-chain hazards. AI is in scope the moment it underpins or endangers a critical asset.
The SOCI Act regulates 22 asset classes across 11 critical-infrastructure sectors - communications, data storage or 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. You can read the principal Act in full on the Federal Register of Legislation, and the regulator's guidance on the Cyber and Infrastructure Security Centre (CISC) website.
Like Australia's prudential standards, the SOCI Act is deliberately technology agnostic and never mentions "artificial intelligence". That neutrality is the point. A machine-learning model that controls grid balancing or water treatment, an LLM-powered clinical decision tool, a fraud-detection model in a payment system, or a vector database holding training data for any of these is captured the instant it materially supports a critical asset or stores business-critical data linked to one. The all-hazards CIRMP obligation - which commenced on 17 February 2023 with a grace period to 18 August 2023 - was never written for AI, but it now squarely governs it.
For a critical-infrastructure CISO or risk lead, the practical consequence is concrete: AI dependencies and AI data stores must appear in your asset register, your hazard assessment, your CIRMP, and your board-approved annual report - alongside the cyber framework you have adopted for the asset.
How did the 2024 SOCI amendments change the rules for AI data stores?
The Security of Critical Infrastructure and Other Legislation Amendment (Enhanced Response and Prevention) Act 2024 - which received Royal Assent on 29 November 2024, with most provisions commencing from 20 December 2024 - extended the SOCI Act to capture data storage systems that hold business-critical data, gave government power to direct remediation of seriously deficient CIRMPs, and broadened consequence-management and information-sharing powers. AI training corpora, vector stores and model artefacts can now sit inside the critical-infrastructure perimeter.
The amending Act is on the Federal Register of Legislation. Its most significant change for AI is the new treatment of data. A data storage system is now taken to be part of a primary critical infrastructure asset where the responsible entity owns or operates it, it is used in connection with the asset, and it stores or processes business-critical data.
Under the SOCI definition, business-critical data includes:
- personal information (within the meaning of the Privacy Act 1988) relating to at least 20,000 individuals;
- information about research and development in relation to a critical infrastructure asset;
- information about systems needed to operate a critical infrastructure asset; and
- information needed to operate a critical infrastructure asset - for example network blueprints, encryption keys, algorithms or schematics.
AI changes the gravity of this category. Training datasets, fine-tuning corpora, embeddings in a vector database, retrieval indexes and prompt/response logs frequently meet the 20,000-individual personal-information threshold or contain operational and R&D data about the asset itself. A poisoned training set, an exfiltrated embedding store, or a leaked system prompt is no longer merely a data-quality problem - it is a hazard to a critical-infrastructure asset that the CIRMP must address. The 2024 Act also lets the Minister direct an entity to remediate a CIRMP assessed as seriously deficient, and extended the Government-assistance and consequence-management regime beyond cyber incidents to all-hazard incidents affecting the availability, integrity, reliability or confidentiality of an asset.
How does the all-hazards CIRMP apply to AI - across cyber, personnel, physical and supply chain?
The CIRMP requires responsible entities to identify and minimise the material risk of each hazard vector - cyber and information security, personnel, physical and natural, and supply chain - and AI introduces concrete failure modes in every one. Treat each AI system and AI data store as an asset that must be assessed against all four vectors and signed off by the board.
The Security of Critical Infrastructure (Critical infrastructure risk management program) Rules and the regulator's CIRMP guidance structure the program around four hazard categories. Mapped honestly to AI:
Cyber and information security hazards
From 18 August 2024, the cyber component of a CIRMP must align to one of five recognised frameworks: the ASD Essential Eight at Maturity Level One, the NIST Cybersecurity Framework, ISO/IEC 27001, the Australian Energy Sector Cyber Security Framework (AESCSF), or the C2M2. AI expands this attack surface with prompt injection, model and data exfiltration, insecure integrations and supply-chain compromise of model weights - threats your chosen framework must be applied to.
Personnel hazards
The CIRMP must manage malicious or negligent insiders, including critical workers with access. For AI this means controlling who can deploy, fine-tune, prompt or connect models to production data, and managing privileged access to model configuration and AI data stores.
Physical and natural hazards
Where AI inference or training runs on critical compute, the physical security and resilience of that infrastructure - and of the data stores feeding it - falls within the CIRMP.
Supply-chain hazards
AI is rarely built in-house. Foundation-model providers, inference APIs, GPU and cloud suppliers, embedded AI features inside SaaS, and fourth-party model dependencies must be assessed for unauthorised access, misuse and disruption. The CIRMP must be reviewed at least annually, and a board-approved annual report submitted within 90 days of the end of the financial year - to the Department of Home Affairs, or to the Reserve Bank of Australia for entities operating critical payment systems.
Why is shadow AI a SOCI compliance risk for critical infrastructure?
Shadow AI - ungoverned use of public chatbots, copilots and embedded AI features by staff in a critical-infrastructure operator - creates SOCI exposure because business-critical data can leave the controlled environment without ever appearing in the CIRMP or the asset register. You cannot manage, report on, or remediate a hazard you have not discovered.
The 2024 amendments make this acute. If an operator's personnel paste operational data, network details, incident notes or personal information into an external AI tool, that flow can:
- move business-critical data into a data store the entity neither owns nor controls, defeating the in-scope-asset protections Parliament just legislated;
- create an undeclared supply-chain dependency on a model provider that is absent from the CIRMP supply-chain assessment; and
- introduce an unmanaged cyber and personnel hazard - exactly the categories the all-hazards program is required to minimise.
A defensible SOCI posture for AI therefore starts with discovery and inventory: an authoritative, continuously updated register of every AI system, embedded AI feature and AI data store in use, mapped to the critical asset it touches and the business-critical data it can reach. Without that inventory, the annual board-approved CIRMP report cannot honestly attest that AI hazards have been identified and minimised. For background, see our explainers on shadow AI and AI supply-chain security.
How does the SOCI Act interact with APRA, the Essential Eight and Australia's other AI rules?
The SOCI Act is the critical-infrastructure resilience layer and it sits alongside, not instead of, Australia's other regimes: APRA prudential standards for financial entities, the ASD Essential Eight as a recognised CIRMP cyber framework, the Privacy Act for personal information, and Australia's principles-based AI governance framework. A regulated AI deployment in a critical-infrastructure sector typically has to satisfy several of these at once.
Key intersections for an AI program:
- APRA CPS 230 and CPS 234. A bank, insurer or super fund is usually both a SOCI responsible entity (financial services and markets, and payment systems) and an APRA-regulated entity. The SOCI CIRMP and APRA's operational-risk and information-security standards must be aligned so AI dependencies are mapped once and governed consistently. See our CPS 230 and AI and CPS 234 and AI guides.
- Essential Eight and the ISM. The Essential Eight is one of the recognised frameworks an entity may adopt for the cyber component of its CIRMP; government and IRAP-assessed environments overlay the Information Security Manual (ISM).
- Privacy Act. Because business-critical data expressly includes personal information of 20,000-plus individuals, the Privacy Act and its automated-decision-making transparency reforms apply in parallel to AI data stores.
- AI governance baseline. Australia's AI rules remain principles-based: the Voluntary AI Safety Standard and the broader national AI governance framework are not yet a mandatory AI Act, so the SOCI CIRMP is one of the few enforceable obligations that already bites on AI in critical sectors. Sovereignty matters here too - keeping AI and its data in-country supports both SOCI resilience and sovereign-AI objectives.
The practical takeaway: build one AI control plane and one AI inventory that can produce evidence for all of these regimes, rather than a separate, manual effort per regulator.
How does Areebi support SOCI Act compliance for AI systems and data stores?
Areebi is a privately deployable Secure AI Control Plane that gives critical-infrastructure operators the discovery, control and evidence the SOCI Act expects over AI systems and AI data stores. It deploys inside your own environment - Docker, Kubernetes, on-premises or private cloud - so AI usage and AI data stay in Australia and inside the critical-asset perimeter rather than in an opaque external service.
Mapped honestly to the CIRMP all-hazards obligation, Areebi helps you:
- Discover and inventory AI (asset identification). Shadow-AI discovery and an AI inventory surface every AI tool, model, embedded AI feature and AI data store in use, so they can be added to the asset register and assessed in the CIRMP.
- Contain cyber and information-security hazards. Real-time data loss prevention (DLP) and runtime guardrails intercept business-critical data before it reaches an external model, and help mitigate prompt injection, data exfiltration and unsafe agent actions.
- Manage personnel hazards. Granular access control governs who can deploy, prompt, fine-tune or connect models to production data and AI data stores.
- Address supply-chain hazards (model-agnostic). A model-agnostic architecture reduces single-provider dependency and supports substitution if an upstream model or provider becomes a supply-chain risk.
- Evidence the annual CIRMP report. Immutable audit logging and a centralised policy engine create the continuous, queryable record needed to support the board-approved annual report and any direction to remediate.
Areebi is an enabling control layer, not a legal opinion: accountability for SOCI compliance, the CIRMP and the board attestation remains with the responsible entity. Areebi is currently pre-named-customer and in stealth, with SOC 2 readiness in progress (not yet certified). Explore the platform, the government and healthcare solutions, or run an AI governance assessment to scope your SOCI AI gaps.