AI for APRA-regulated entities: CPS 234, CPS 230 and AI risk

There is a question we get on every engagement with an APRA-regulated entity, within the first thirty minutes: “Does this need its own AI risk framework, or does it fit inside what we already have?”

The honest answer is: it fits inside what you already have. APRA hasn’t issued an AI-specific prudential standard, and isn’t expected to in the immediate term. What APRA has done is signal — through speeches, through engagement with regulated entities, through the published Information Paper on AI in financial services — that AI systems are in-scope for the existing standards. CPS 234 (information security) applies to AI systems. CPS 230 (operational risk management) applies to AI systems. CPG 235 (managing data risk) applies to the data flowing through them.

This means the work is integration, not creation. The AI-specific risks need to be mapped to the existing control frameworks your internal audit team already tests. Done well, this saves an enormous amount of duplication and produces a governance posture that survives the next regulator engagement. Done poorly, you end up with a parallel AI risk register that doesn’t talk to the rest of the firm’s risk function and gets quietly ignored by everyone except its author.

This piece is the mapping we use inside engagements. CPS 234 first, then CPS 230, then CPG 235. Plus a brief note on the Voluntary AI Safety Standard, which doesn’t replace APRA’s standards but does inform how APRA-regulated entities should think about AI lifecycle governance.

CPS 234 — Information security for AI systems

CPS 234 is the prudential standard for information security. It applies to APRA-regulated entities and their third-party service providers. The standard’s substantive obligations are familiar — maintain capability commensurate with vulnerabilities and threats, identify and classify information assets, implement controls, test the controls, notify APRA of material incidents.

For AI systems, every one of these obligations applies. The work is to make the application explicit in your information security control framework.

Information assets

The first practical step is to add AI systems to your information asset inventory. Each AI system is an asset; the data flowing through it is an asset; the model itself (where you’re fine-tuning or operating a proprietary model) is an asset. Each needs a classification under your existing data classification policy — typically Public / Internal / Confidential / Highly Confidential.

This step matters because the data classification determines the architecture choices. If you classify customer credit data as Highly Confidential and your AI architecture sends that data to a US-hosted LLM API, you have a CPS 234 alignment issue independent of any AI-specific consideration. The fix is usually architectural (VPC-deployed model, AU-region inference, data redaction at the API boundary) rather than policy-level.

For most APRA-regulated entities running production AI today, this is the single most consequential CPS 234 piece of work — getting clarity on which AI workflows are sending which data classifications to which model providers, and aligning that against the existing data classification policy.

Controls — the AI-specific extensions

The controls themselves are mostly extensions of existing IT security controls, with three AI-specific additions:

• Model access controls — who can call which model with which data. Implemented at the IAM layer plus, increasingly, at the prompt-orchestration layer (LLM gateways, AI security platforms).
• Prompt injection and output validation — input sanitisation, output schema validation, where the AI is consuming or producing structured data. For agentic AI systems with tool access, an additional layer of action-validation controls.
• Audit logging for AI inferences — every model call traced with sufficient detail for incident reconstruction. Critical for both CPS 234 (incident response) and CPS 230 (operational risk).

These controls don’t replace your existing controls. They sit alongside them, in the same control framework, tested by the same internal audit team.

Incident notification

CPS 234 requires notification to APRA of material information security incidents within 72 hours. AI systems can produce CPS 234-reportable incidents in ways traditional systems don’t — model output containing sensitive data, prompt injection enabling unauthorised actions, supplier-side breaches of the foundation model platform.

The practical implication: the AI system’s logging and alerting needs to surface incidents to the same incident response process that handles every other CPS 234-reportable event. Bolt-on AI monitoring that doesn’t integrate with your existing IR process creates a real risk of missing the 72-hour notification window.

CPS 230 — Operational risk management for AI systems

CPS 230 is the prudential standard for operational risk, effective from 1 July 2025. It applies to AI systems in two ways: (a) AI systems themselves are operational risk surfaces, and (b) AI providers — particularly foundation model providers — are material service providers under the standard’s definitions.

AI systems as operational risk surfaces

CPS 230 requires entities to identify, assess and manage operational risks across the full risk taxonomy. For AI systems, the operational risk register needs to identify AI-specific risks:

• Model availability — what happens if the foundation model provider has an outage? Is there a fallback model? A degraded operating mode?
• Model behaviour drift — what happens if the model’s behaviour changes (a provider-side update, a fine-tune drift, an evaluation regression)? How is the change detected? Who is responsible for response?
• Cost overruns — AI inference costs scale with usage in non-linear ways. CPS 230 expects entities to manage operational risks including financial volatility from operations.
• Decision quality degradation — for AI used in regulated decisioning, a degradation in decision quality is itself an operational risk event. The detection mechanism is the evaluations and observability framework.
• Reputational risk from AI-generated outputs — particularly relevant for customer-facing generative AI, where a single bad output can become a public incident.

These risks live in the operational risk register alongside the rest. They’re tested in the existing risk assurance cycle. The treatment plans use the existing tooling.

AI providers as material service providers

The more consequential CPS 230 implication is on the supplier side. CPS 230 introduces explicit requirements for management of material service providers — assessment before engagement, ongoing monitoring, exit planning, contractual provisions for service continuity, audit rights.

For most APRA-regulated entities, the foundation model providers (Anthropic, OpenAI, Google, Microsoft for Azure OpenAI, AWS for Bedrock) and the relevant cloud platforms hosting them will meet the “material service provider” threshold once AI workflows are in production at any significant scale.

The practical work:

• Map the AI supply chain — which providers are providing which AI services, and which of those become material as the AI program scales
• Apply the existing supplier assessment process to AI providers — most of the contractual provisions APRA expects are present in the major providers’ enterprise terms, but they vary in detail
• Build exit planning into AI architectures — designing AI systems so they can move between foundation models with bounded effort. This is increasingly a CPS 230-driven architectural pattern rather than a cost-optimisation one.
• Establish service-level monitoring — AI provider outages and degradations need to be detected and reported through the same operational risk reporting process as other material service providers.

The hardest part of CPS 230 for AI is the exit planning. Foundation models are not commodities — switching from one to another involves prompt re-engineering, evaluation re-baselining, behaviour re-testing. We typically recommend a documented “exit playbook” per material AI provider, even when actual exit is unlikely; the existence of the playbook is what CPS 230 expects, and the discipline of writing it surfaces real architectural dependencies.

CPG 235 — Managing data risk

CPG 235 is the prudential practice guide for managing data risk. It’s a guide rather than a standard, but APRA’s expectations under CPG 235 are firm.

For AI systems, CPG 235 maps to:

• Data quality — AI systems are only as good as the data they consume. CPG 235’s data quality expectations apply to training data, RAG corpora, and prompt-context data.
• Data lineage — for AI systems making or influencing decisions, the lineage of the data flowing into the decision needs to be documented and auditable. This is harder for LLM-based systems than for traditional ML; the patterns are still evolving.
• Data governance — the ownership, classification and stewardship of data flowing into and out of AI systems. Typically integrates with the entity’s existing data governance function.

The practical work here is usually integration with the entity’s existing data governance function rather than building a parallel AI data governance capability. The CDO’s office is the right home for AI-data-governance work in most APRA-regulated entities.

Where the Voluntary AI Safety Standard fits

The Voluntary AI Safety Standard is not an APRA standard. But for APRA-regulated entities, alignment to it produces a governance posture that materially satisfies the AI-relevant elements of CPS 234, CPS 230 and CPG 235 — because the underlying lifecycle practices are the same.

The pragmatic approach we recommend: implement the Voluntary AI Safety Standard’s ten guardrails using the entity’s existing CPS 234 / CPS 230 / CPG 235 control framework as the implementation substrate. This produces:

• One AI governance posture, mapped explicitly to both the Voluntary AI Safety Standard guardrails and the APRA standards’ obligations
• Documentation that internal audit can adopt — because the controls live inside the existing framework rather than parallel to it
• A defensible position with APRA when (not if) AI-specific scrutiny arrives — because the entity can demonstrate AI risks are managed within the existing prudential framework

This is the engagement pattern in our productised AI Governance Review for APRA-regulated entities. Four weeks of focused work; the output is the alignment statement against the Voluntary AI Safety Standard’s ten guardrails AND the explicit mapping to CPS 234, CPS 230 and CPG 235.

What internal audit will look for

When internal audit gets to your AI control environment — typically driven by the audit committee asking for AI assurance — three things will be on the test list:

1. Is there a documented AI risk taxonomy, integrated with the entity’s operational risk taxonomy? If yes, the conversation moves on. If no, this is the first remediation item.

2. Is there evidence of AI controls being tested? Not just designed, tested. Pre-deployment evaluations, production observability, drift detection, incident logs. The artefacts internal audit will want to see exist already if you’re running AI well; they don’t exist if AI is being run as a side-project.

3. Is there evidence of AI supplier management consistent with CPS 230? Supplier assessment artefacts, contractual review of provider terms, exit planning documentation. This is often the gap area — AI providers are managed informally, not through the same process as other material service providers.

The fix for all three is typically a one-off remediation engagement followed by integration into the entity’s normal control assurance cycle. The remediation is unpleasant but bounded; the integration is the sustainable answer.

What APRA has not yet said but may

It’s worth being explicit about what APRA has signalled but not formalised. The Information Paper on AI (and APRA’s various speeches) indicate areas of likely focus, even if formal regulatory action hasn’t yet followed:

• Board-level AI accountability — APRA expects boards to be substantively informed about AI use within the entity, not just receive aggregated risk reports. The board-level AI briefing pack is increasingly expected at the audit-committee level.
• AI-specific scenario analysis under CPS 230 — operational resilience exercises (CPS 230 Section 35) should consider AI-specific failure scenarios. Most entities haven’t yet incorporated AI into scenario analysis; this is likely to be tested.
• CISO involvement in AI — APRA has been clear that the CISO function should be involved in AI architecture decisions from the design stage. AI projects that emerge from business units without CISO touchpoint are a flagged pattern.

None of these are formal standards yet. All three are areas where getting ahead is much cheaper than catching up.

How to start, if you haven’t

Most APRA-regulated entities we engage with are in one of three positions:

Position A — No published AI policy, ad-hoc AI use across the firm. Start with the named accountable executive and the AI inventory. Inventory first; you can’t govern what you can’t see.

Position B — AI policy exists but doesn’t map to APRA standards. Add the mapping. Four weeks of focused work; the output is the policy plus the explicit mapping to CPS 234, CPS 230 and CPG 235.

Position C — Mature governance, scattered evidence. The work is consolidation and pack-building. The AI governance pack exists; it just isn’t organised for an audit to pick up and assess.

For all three, the productised AI Governance Review is the four-week engagement designed exactly for this. The output is the alignment statement, the risk register, the policy mapped explicitly to APRA standards, and the board-ready briefing pack.

If you want to talk through your situation first, the discovery call is 30 minutes, no deck.