CPS 230 for AI: the operational playbook APRA expects you to have

What CPS 230 requires

CPS 230 consolidates five earlier standards (CPS 231, CPS 232, SPS 231, SPS 232, and HPS 231) and applies to every APRA-regulated entity: ADIs, general and life insurers, private health insurers, RSE licensees, and authorised NOHCs.

Three obligations sit at the core:

• Operational risk management across every process that delivers a critical operation.
• Business continuity, including documented tolerance levels and tested severe-but-plausible scenarios.
• Service provider management, including a maintained material service provider register and credible exit strategies.

The board is accountable. Senior management is responsible for implementation. CPG 230, the supervisory guidance APRA finalised in June 2024, is the document APRA staff read before a prudential review.

Artificial intelligence is not a critical operation

Listing "artificial intelligence" on a register is a category error, because AI is an input, not an operation. The critical operation is the decision it supports: a fraud alert, a credit decision, a claims triage, a member-advice interaction.

The first job of a CPS 230 AI programme is to make this judgement consistently. The second is to document it, because the opening question in any prudential review is "show me the reasoning."

When ANZ migrated its operational-risk stack into ServiceNow to meet CPS 230, the exercise mapped 19 critical operations across roughly 43,000 supporting resources and 16 non-financial risk themes. That is what a tier-one bank's register looks like in practice.

Classifying AI vendors on the MSP register

APRA defines a material service provider as one the entity relies on for a critical operation, or one that exposes the entity to material operational risk. Third, related, and connected parties all count. APRA released the register template in October 2024 and the first annual submission was due on 1 October 2025. PolyGovern's third-party AI risk practice classifies vendors against the test below.

Modern AI deployments rarely have a two-party structure. They usually have four tiers:

CPG 230 is explicit that fourth parties should sit on the register when they are material. That covers the cases where a licensed SaaS silently routes prompts or embeddings to a foundation-model provider the bank never contracted with. Regulated customers of that SaaS carry a documented exposure they did not sign up for, and the register must reflect it.

Five questions for every AI vendor

Two "yes" answers means the provider belongs on the register.

1. 1.Does the AI output support or constitute a decision on a critical operation?
2. 2.Is the AI output visible to a customer, a member, or a regulator?
3. 3.Can the entity substitute the AI provider within the business-continuity tolerance without degrading the critical operation?
4. 4.Does the AI provider process customer personal information, transaction data, or regulated records?
5. 5.Is the entity exposed to enforcement, customer harm, or financial impact if the provider fails for 24 hours?

The checklist below expands each question with evidence requirements, scoring guidance, and a sample register row.

On the NTSP consultation

APRA opened a targeted consultation on non-traditional service providers in December 2025. Submissions closed on 30 January 2026. The consultation did not carve AI out. Through the first half of 2026, every AI vendor touching a critical operation remains in scope.

Exit strategy when your dependency is a foundation model

Classical SaaS exit plans assume three things that foundation-model dependencies break:

What a defensible exit strategy looks like

• Dual-model architecture from day one. Two providers able to serve the operation with minor prompt and adapter changes. The second kept warm through weekly regression runs or a small percentage of live traffic.
• Vector stores decoupled from the embedding provider. Access control, chunking, and retrieval logic in the entity's own code rather than the provider's.
• AI escrow. The AI analogue of software escrow. Fine-tune weights, prompt libraries, and evaluation harnesses deposited with a third party under release triggers tied to the CPS 230 materiality thresholds.
• Tolerances calibrated to deprecation events. Major providers have deprecated production checkpoints with nine months' notice or less.
• A documented minimum viable replacement. The pared-down capability the entity will operate under for the duration of a replacement programme. This is the bridge state, not the target state.

An exit strategy is engineered, not declared. A document without architectural mitigation will not survive a real model deprecation.

The board report CPS 230 actually asks for

The quarterly pack needs six elements. Not ten.

1. 1MSP register with AI classification flagged, row count, change month-over-month, and any additions or removals that crossed the materiality threshold.
2. 2Critical operations enabled by AI with performance against each tolerance dimension and pass-fail on golden evaluation sets.
3. 3Output drift and hallucination metrics with monthly trend against the tolerances. Breaches are escalated items, not reported items.
4. 4AI incident log covering disruption events, prompt-injection events, and model-deprecation events, with resolution status and lessons applied elsewhere.
5. 5Exit-strategy testing results for each material foundation-model dependency, including the minimum viable replacement walk-through.
6. 6Material supervisory correspondence: any APRA letter referencing CPS 230 or CPS 234 for an AI operation, and any heightened-supervision flag.

FAR statements that name AI

An accountable-person statement for an AI-enabled critical operation names four things:

• The accountable person (usually the CRO, CIO, or a named business-line executive; rarely the CDO or Chief AI Officer).
• The critical operation in CPS 230 language, aligned to the register.
• The material service providers in the AI chain, referenced by register entry.
• The escalation paths for tolerance breaches.

Statements that describe AI as "a distributed capability across the organisation" are not FAR-compliant. A single person owns each AI-enabled critical operation. PolyGovern's board-level AI governance practice drafts the statements with the named accountable persons.

What to do in April to June 2026

1. 1.Re-test the MSP register. Run every AI-vendor entry through the five-question test. The entries written before 1 October 2025 pre-date the first review cycle.
2. 2.Write tolerance levels on the five-dimension set. Output drift and hallucination rate are new. The team will not have baselines. Establish them on production traffic this quarter so the September board pack has real numbers.
3. 3.Engineer the exit strategy. Dual-provider architecture, AI escrow, minimum viable replacement. Raise any of the three lock-ins without mitigation to the risk committee.
4. 4.Refresh vendor contracts for 1 July 2026. Sub-processor disclosure is the most common gap. The 24-hour incident notification window is the second.
5. 5.Rewrite the FAR statements. The statements filed before the AI programme existed are incomplete by construction.
6. 6.Rebuild the board AI report on the six-element structure. The next pack the risk committee sees should be the first one APRA would recognise in a review.