AI Under APRA CPS 230 and CPS 234
APRA says existing prudential standards apply to AI. What that means for a regulated entity, requirement by requirement, with the evidence APRA would expect to see and a worked example.
The short version
There is no APRA prudential standard for AI. In its letter to industry of 30 April 2026 APRA said existing prudential standards apply to AI risk, found that governance, security, third-party management and assurance are lagging behind AI adoption, and said it will step up supervision and act where entities fall short.
So AI risk is managed through the standards you already comply with:
- CPS 234 treats AI systems, data, prompts and agent credentials as information assets to be identified, classified, protected, tested and reported on.
- CPS 230 treats AI providers as service providers, often material ones, and AI-supported critical operations as operations that need tolerances and a credible fallback.
- CPS 220 puts AI strategy and risk appetite in front of the Board. Our APRA CPS 220, 230 and 234 guide covers how the three divide the territory, and summarises the letter.
Why AI strains the standards
Nothing in AI is outside CPS 230 and 234, but AI stresses them in four places existing programs were not built for:
- Non-human actors. Agents act with their own credentials, and identity and access controls designed for people do not fit them well.
- Behaviour that changes. Models drift and providers ship new versions, so a control tested once may not hold, and point-in-time assurance falls short.
- Concentration. Many entities rely on one or two foundation model providers, with opaque fourth parties underneath and untested exit plans.
- AI inside critical operations. When AI supports claims, fraud or customer service, its failure is an operational resilience event, not just a technology problem.
CPS 234 applied to AI
CPS 234 Information Security, in force since July 2019, applies to AI the way it applies to any information asset. What changes is the assets and the threats.
| Requirement | What it means for AI | Evidence APRA would expect |
|---|---|---|
| Board responsibility | The Board is ultimately responsible for information security, AI included. APRA's 2026 letter found many Boards lack the literacy to challenge AI risk. | AI literacy briefings for the Board; AI risk in Board reporting; minutes showing challenge, not just vendor presentations. |
| Roles and responsibilities | Name who owns security for each AI system, from design to decommissioning, including AI features switched on inside SaaS platforms. | An owner for every entry in the AI register; RACI covering AI systems and their providers. |
| Information security capability | Your capability must match the threats, and AI adds new ones: prompt injection, data leakage through prompts, manipulated agents. It also covers the capability of third parties who manage your AI. | Threat assessment that includes AI; assessment of AI providers' security capability. |
| Policy framework | Policies must cover AI: an AI usage policy for staff, and AI-specific rules in access, change, data handling and supplier policies. APRA found staff AI use often relies on policy without technical enforcement. | AI usage policy with technical controls behind it (approved tools, blocked uploads of sensitive data). |
| Information asset identification and classification | Models, training and fine-tuning data, prompts and outputs, retrieval stores, connectors and agent credentials are information assets. Classify them by criticality and sensitivity like any other. | AI assets in the information asset register, classified, with owners. |
| Implementation of controls | Controls proportionate to criticality and sensitivity, across the AI lifecycle: agent identities and least privilege, untrusted handling of retrieved content, human approval for high-impact actions, logging, patching, secure configuration and security testing of AI-generated code. | Control evidence mapped to each AI asset; see the ISM controls in our securing AI agents guide. |
| Incident management | Incident plans must cover AI scenarios: sensitive data leaked through an AI tool, an agent acting on injected instructions, a model provider breach. Test the plans. | AI scenarios in the incident response plan and in exercises. |
| Testing control effectiveness | Test AI controls regularly and when things change, including adversarial testing and red teaming of AI systems, and get assurance over providers' controls. Point-in-time testing alone does not suit models that change. | AI red team or adversarial test reports; continuous monitoring; provider assurance reports. |
| Internal audit | Internal audit must be able to review AI controls, which APRA found often lack specialist AI skills. | Audit plan covering AI; AI skills in, or available to, the audit team. |
| Notifying APRA | AI incidents are information security incidents. Notify APRA within 72 hours of becoming aware of a material one, and within 10 business days of a material control weakness you cannot remediate in time. | Notification criteria that explicitly include AI incidents and weaknesses. |
The controls themselves are set out in our securing AI agents guide, mapped to the ISM, including ISM-2133 agent identities, ISM-2157 combined user and agent authorisation and ISM-2159 agent activity logging.
CPS 230 applied to AI
CPS 230 Operational Risk Management, in force since July 2025, is where AI's dependence on providers and its role in critical operations are managed.
| Requirement | What it means for AI | Evidence APRA would expect |
|---|---|---|
| Critical operations | Identify which critical operations now depend on AI, directly or through a provider: claims triage, fraud detection, customer service, credit decisions, payments screening. | Critical operations register showing AI dependencies. |
| Tolerance levels | Set tolerance levels for disruption of AI-supported critical operations, covering not only outage but degraded or wrong output. | Tolerances that address AI failure modes such as drift and erroneous output. |
| Business continuity | Every AI-supported critical operation needs a credible fallback: a manual or non-AI process that can run within tolerance if the AI is unavailable, misbehaving or withdrawn. APRA's 2026 letter asks for exactly this. | Documented and tested fallbacks for each AI-supported critical operation. |
| Scenario analysis | Include AI scenarios: a model provider outage, a model version change that alters behaviour, a provider exiting the market, a poisoned model or data source. | AI scenarios in the scenario analysis program, with results. |
| Material service providers | Foundation model providers and AI platforms supporting critical operations are likely material service providers. Map the full supply chain, fourth parties included, such as the cloud underneath the model. | AI providers in the material service provider register; supply chain map. |
| Service provider management | Due diligence, contracts and monitoring for AI providers: data use and training restrictions, notice of model changes, audit and access rights, security obligations, and exit arrangements. | Contract clauses for AI-specific terms; ongoing performance and risk monitoring. |
| Concentration and exit | APRA found heavy reliance on single AI providers and exit plans rarely tested. Manage concentration actively and test substitution. | Concentration assessment; a tested exit or substitution plan. |
| Notifying APRA | Notify APRA of AI-related operational incidents that meet the CPS 230 thresholds, and of new or materially changed arrangements with material service providers, AI providers included, within the required timeframes. | Notification triggers that include AI incidents and AI provider arrangements. |
Worked example: an AI claims triage assistant
An insurer deploys an AI assistant that reads incoming claims, extracts details, flags likely fraud and routes each claim to a queue. It runs on a foundation model from an external provider, retrieves policy documents, and can update the claims system. Claims processing is a critical operation.
- Use case approved against the AI strategy and risk appetite
- Named owner, and human review of fraud flags that affect customers
- AI risk reported to the Board with escalation triggers
- Claims processing tolerance covers the assistant being down or wrong
- Tested manual triage fallback that runs within tolerance
- Model provider assessed as a material service provider; contract covers data use, model changes, audit rights and exit
- Scenario: provider changes model version and fraud flags spike
- Claims data, prompts, outputs and the agent's credentials classified as information assets
- Agent has its own identity and can update only the fields it needs
- Policy documents and claim attachments treated as untrusted input
- Activity logged and baselined; adversarial testing before release; AI incidents in the 72-hour notification criteria
What APRA's 2026 letter adds
APRA's letter does not change the standards, but it tells you where supervisors will look. It asks Boards to build AI literacy and oversee AI strategy and escalation triggers; accountable executives (the CRO, CTO and CISO) to act promptly on the gaps APRA identified; all entities to prioritise patching and review ASD's advice on frontier AI models; and entities with heightened AI risk concerns to engage early with APRA through their supervisors. Our APRA guide summarises the letter, and ASD's advice is covered in our ASD Essentials and AI guide.
AI under CPS 230 and 234 checklist
Fifteen checks. Ticks are stored in this browser only.
CPS 234; APRA letter
CPS 234
CPS 234
CPS 234
CPS 234
CPS 234
CPS 234
CPS 234
CPS 234, CPS 230
CPS 230
CPS 230
CPS 230
CPS 230
CPS 230
CPS 230
Want an AI review against CPS 230 and 234?
Tell us where AI sits in your operations and we will reply within two business days. We can introduce you to an independent adviser who reviews AI against APRA's prudential standards.
CISO AI may receive a fee from providers we introduce you to. Your details are used only for this enquiry; see our privacy policy.
Questions
Does APRA have an AI prudential standard?
No. In its letter to industry of 30 April 2026 APRA said existing prudential standards apply to AI risk. CPS 220 covers the risk framework and Board oversight, CPS 230 operational resilience and service providers, and CPS 234 information security.
Is an AI provider a material service provider under CPS 230?
It can be. A provider whose AI supports a critical operation, or which exposes the entity to material operational risk, is likely to be a material service provider, with the due diligence, contract, monitoring and notification obligations that follow. Assess each AI provider against your own criteria rather than assuming either way.
Do AI incidents need to be reported to APRA?
If they meet the thresholds. An AI incident that is a material information security incident must be notified within 72 hours under CPS 234, and an AI-related operational risk incident that meets the CPS 230 thresholds must be notified under that standard. Write AI explicitly into your notification criteria so nobody has to argue about it at the time.
Does CPS 234 cover staff using public AI tools?
Yes. Information pasted into an AI tool is an information asset leaving your control, and CPS 234 expects controls commensurate with the sensitivity of the information. APRA's 2026 letter specifically criticised relying on policy alone; back the AI usage policy with technical controls.
What does APRA expect Boards to know about AI?
Enough to oversee an AI strategy consistent with the risk appetite and to challenge management on AI risk, with monitoring and clear escalation triggers. APRA found many Boards lacked that literacy and relied on vendor presentations.