APRA CPS 230 and AI: Operational Risk for Australian Financial Services

APRA Prudential Standard CPS 230 Operational Risk Management, effective 1 July 2025, requires every APRA-regulated bank, insurer and superannuation trustee to identify AI systems that support critical operations, keep those operations within board-approved tolerance levels through disruption, and manage AI and LLM vendors as material service providers where they meet the threshold. AI is in scope by function, not by name.

CPS 230 is a cross-industry prudential standard that consolidated and replaced five earlier standards - CPS 231 Outsourcing and CPS 232 Business Continuity Management (for ADIs, life and general insurers), SPS 231 and SPS 232 (superannuation), and HPS 231 (private health insurers) - covering outsourcing and business continuity. It applies to authorised deposit-taking institutions (ADIs), general, life and health insurers, and registrable superannuation entity (RSE) licensees. You can read the standard in full in the APRA Prudential Handbook.

CPS 230 itself is deliberately technology and vendor agnostic - it never mentions "artificial intelligence". That neutrality is the point: an AI model that triages insurance claims, scores loan applications, disrupts scams, or powers a customer chat assistant is captured the moment it underpins a critical operation or exposes the entity to material operational risk. On 30 April 2026 APRA closed the interpretive gap by issuing an industry letter calling for a step-change in AI-related risk management and governance, making clear that entities can no longer rely on the principles-based framework alone to evidence AI control. APRA was explicit that it is not introducing additional prudential requirements at this stage - it expects entities to manage AI risk within the existing standards.

For a CISO, CRO or operational-risk lead, the practical consequence is concrete: AI dependencies must appear in your critical-operations mapping, your business continuity plan (BCP), your scenario-testing program, and - where the AI vendor is material - your material service provider register and contracts.

Under CPS 230 paragraph 35, a critical operation is a process that, if disrupted beyond tolerance levels, would have a material adverse impact on depositors, policyholders, beneficiaries or other customers, or on the entity's role in the financial system. An AI system is captured whenever it materially underpins such a process - the test is the impact of disruption, not whether the technology is labelled "AI".

Once an AI system supports a critical operation, three obligations attach directly:

• Board-approved tolerance levels (para 22 and 38). The Board must approve the BCP and the tolerance levels for disruptions to critical operations. For each critical operation those tolerance levels must cover the maximum period of disruption the entity would tolerate, the maximum extent of data loss it would accept, and the minimum service levels it would maintain on alternative arrangements. An AI-dependent process must be able to operate within those limits.
• A credible continuity plan through disruption (para 33 and 40). The entity must maintain a BCP setting out how it would keep critical operations within tolerance through disruptions, including disaster recovery for critical information assets. For AI, this means a documented, viable fallback - a non-AI process, a substitute model, or degraded-mode operation - that can be invoked if the model, its API, or its provider fails.
• Systematic scenario testing (para 43 and 44). The entity must run a systematic testing program covering all critical operations, including an annual business continuity exercise against a range of severe but plausible scenarios. For AI this includes provider outage, model deprecation or version change, corrupted or poisoned outputs, and loss of access to a foundation model.

In its 30 April 2026 letter, APRA warned that entities rely on point-in-time and sample-based assurance methods despite these methods being ill-suited to probabilistic models that learn, adapt and degrade over time, and that assurance is lagging behind deployment. The supervisory expectation is continuous validation of AI that supports critical operations, with fallback arrangements that have actually been tested rather than merely documented.

Yes. Under CPS 230 paragraph 49, a material service provider is one the entity relies on to undertake a critical operation or that exposes it to material operational risk. An AI or LLM vendor that powers credit decisioning, claims handling, fraud detection, customer servicing, or another critical process meets that threshold, and the full service-provider regime applies.

Where an AI vendor is material, CPS 230 requires the entity to:

• Maintain a service provider management policy (para 47) and record the vendor on the register of material service providers (para 49), which must be submitted to APRA on an annual basis (para 51). APRA requested that entities submit their first register using its template by 1 October 2025.
• Hold a formal legally binding agreement (para 54 and 55) that, among other things, sets out audit access and data-ownership rights and preserves APRA's access to the service provider. The service provider management policy must also address fourth parties the vendor relies on (para 48) - for AI this extends to upstream foundation-model providers buried inside a vendor's platform.
• Assess and manage concentration risk (para 53) as part of due diligence on each material arrangement, including risks associated with the concentration of the service providers or parties the provider relies on, and ensure it can conduct an orderly exit if needed (para 56).
• Comply for pre-existing contracts by the earlier of the next contract renewal or 1 July 2026, per the transition arrangement that has applied since the standard commenced.

APRA's April 2026 letter identified third-party and supply-chain risk as the widest gap between current practice and regulatory expectation. It found that AI capabilities are increasingly embedded within software, platforms or developer tools, meaning upstream dependencies such as foundation models, training data sources and fourth-party providers are opaque, and that contractual arrangements often lagged practice, with limited evidence of provisions addressing audit rights, model updates and deviations, incident notification or changes to data handling. The 30 April 2026 final targeted amendments to CPS 230 (effective 1 July 2026) created a narrow exemption from some contractual requirements for non-traditional service providers such as central banks and clearing and settlement facilities - but APRA explicitly declined to exempt cloud infrastructure and IT providers, so AI and cloud vendors remain in full scope.

CPS 230 paragraph 53 requires an entity, before relying on a material service provider, to assess the financial and non-financial risks from that reliance, including risks associated with the geographic location or concentration of the service providers or parties the provider relies on. The service provider management policy (para 47 and 48) must set out the entity's approach to substituting and exiting agreements, and for each material arrangement the entity must be able to conduct an orderly exit if needed (para 56). For AI, this means identifying where a single model, provider or foundation model underpins multiple critical operations, and maintaining a tested exit or substitution path.

APRA's April 2026 AI letter put this beyond doubt. It found entities heavily dependent on a single provider for multiple AI use cases, with few demonstrating robust contingency planning or tested exit and substitution strategies. APRA's expectation is a credible exit strategy that includes a documented fallback solution capable of maintaining business continuity if the AI system fails, with the feasibility of reverting tested against realistic timeframes and existing resources.

Concentration risk in AI is compounded by two structural features the regulator highlighted:

• Stacked dependencies. Many AI vendors are themselves built on a small number of frontier foundation models. A single upstream model deprecation, price change, safety intervention or outage can simultaneously degrade several apparently independent vendors - a fourth-party concentration that is invisible without supply-chain mapping.
• Substitution friction. Proprietary platforms with bespoke integrations and fine-tuned models are far harder to replace than capabilities built on open standards or portable, model-agnostic architectures. APRA expects entities to weigh this lock-in when assessing replaceability.

The practical CPS 230 response is to inventory every AI dependency and its upstream model, map concentration across critical operations, and prove - through testing, not assertion - that the entity can fall back or switch providers within its board-approved tolerance levels.

APRA treats opaque, complex AI as an operational, conduct and fairness risk, not merely a technical one. In its 30 April 2026 letter it warned that governance, risk management, assurance and operational resilience practices are not keeping pace with the scale, speed and complexity of AI adoption, and that AI capabilities are increasingly embedded within software and platforms, limiting an entity's ability to independently assess model performance, bias, resilience and security.

While CPS 230 is the operational-resilience anchor, AI fairness and explainability sit at the intersection of several APRA expectations and other Australian law:

• Board literacy (set out in the 30 April 2026 letter). APRA set a minimum expectation that boards maintain sufficient understanding and literacy with respect to AI to set strategic direction and provide effective challenge and oversight - and cautioned specifically against over-reliance on vendor presentations and summaries without sufficient examination of key AI risks.
• Explainability for consumer outcomes. Where AI influences pricing, underwriting, credit or claims, opaque "black-box" models can produce unfair or unexplainable outcomes for policyholders and customers. APRA expects entities to be able to understand, challenge and evidence how AI-influenced decisions are reached.
• Security of the AI itself. APRA named prompt injection, data leakage and insecure integrations as common attack pathways, and flagged the manipulation or misuse of autonomous AI agents and strain on change and release controls from AI-assisted software development - failures that can both corrupt outputs and breach the security obligations in CPS 234, the information security standard in force since 1 July 2019.

Explainability and bias obligations also flow from the Privacy Act automated decision-making transparency reforms, which commence on 10 December 2026 under the Privacy and Other Legislation Amendment Act 2024 (see our Australian Privacy Act compliance guide), and from Australia's broader AI governance framework, which remains principles-based and voluntary - the Voluntary AI Safety Standard and the National AI Plan (December 2025) did not legislate mandatory AI guardrails. CPS 230 is the resilience layer; together these regimes require regulated entities to keep AI decisioning transparent, contestable and auditable.

Areebi is a privately deployable Secure AI Control Plane that gives Australian regulated entities the operational visibility and controls CPS 230 expects over AI systems and AI vendors. It is deployed in your own environment - Docker, Kubernetes, on-premises or private cloud - so data stays in Australia and AI usage sits inside your operational-resilience perimeter rather than in an opaque external platform.

Mapped honestly to CPS 230 obligations, Areebi helps you:

• Inventory AI dependencies (para 47, 49). Shadow-AI discovery and an AI inventory surface every AI tool, model and embedded AI capability in use, which feeds the identification of material service providers for your register.
• Reduce concentration and lock-in (para 53, 56). A model-agnostic architecture spanning 30-plus LLMs supports substitution and viable alternatives, so a single provider's failure need not breach tolerance.
• Evidence control and outcomes (para 40, 43, 44). Immutable audit logging, a centralised policy engine, runtime guardrails and real-time data loss prevention (DLP) create the continuous, queryable evidence base APRA expects in place of point-in-time sampling.
• Contain the named threats. Guardrails and DLP help mitigate prompt injection, data leakage and unsafe agent actions that APRA flagged in its April 2026 letter.

Areebi is an enabling control layer, not a legal opinion: accountability for CPS 230 compliance, tolerance-setting and board oversight remains with the regulated entity. Areebi is currently pre-named-customer and in stealth, with SOC 2 readiness in progress. Explore the platform, the dedicated financial services solution, or run an AI governance assessment to scope your CPS 230 AI gaps.