APRA CPS 230 Is Live. Every APRA-Regulated Entity Using AI Needs to Read This.

*Published 21 March 2026.*

APRA's Prudential Standard CPS 230 — Operational Resilience — came into effect on 1 July 2025. For Australian banks, insurers, and superannuation funds, it is now the law governing how your operations must behave under disruption.

Most APRA-regulated entities have done the obvious work: mapping critical operations, identifying material service providers, stress-testing business continuity plans. The risk committees have presented. The audit reports have been filed.

What most have not done is read CPS 230 specifically through the lens of their AI systems.

This is the gap that will generate APRA findings in 2026.

What CPS 230 Actually Requires — And Why AI Is the Compliance Blind Spot

CPS 230 requires APRA-regulated entities to:

• Identify and manage critical operations — the operations whose disruption would have an unacceptable impact on customers, financial system stability, or the entity's ability to meet its obligations
• Set tolerance levels for disruption — maximum acceptable duration and impact thresholds
• Maintain service provider risk management — third-party and fourth-party dependency identification, assessment, and ongoing management
• Conduct operational resilience testing — table-top exercises, scenario testing, and business continuity validation

Here is where AI creates a specific and largely unaddressed problem for each requirement.

Critical Operations and AI

APRA defines critical operations broadly — any operation that, if disrupted, would cause unacceptable impact. For most APRA-regulated entities in 2025–26, AI systems have been embedded into critical operations faster than those operations were reassessed under CPS 230.

A mortgage lender's automated credit decisioning system — built on a machine learning model — is now a critical operation. A superannuation fund's member communication prioritisation agent is a critical operation if its failure means members with urgent queries wait days instead of hours. An insurer's claims triage AI that determines which claims get same-day versus standard processing is a critical operation.

If these AI systems were not in production when the CPS 230 critical operations mapping was completed, they are not in the register. If they are not in the register, they have no documented tolerance levels, no tested recovery procedures, and no board-approved resilience targets.

Most regulated entities that deployed AI in the 12–18 months leading up to CPS 230's July 2025 effective date have this gap.

Service Provider Risk and AI Vendors

CPS 230 has particularly strict requirements for material service providers — third parties whose disruption would significantly impact critical operations. The standard requires regulated entities to:

• Identify all material service providers
• Assess their operational resilience
• Maintain contractual controls
• Test resilience with and without key service providers

AI API providers — OpenAI, Anthropic, Microsoft Azure OpenAI, AWS Bedrock — are material service providers for any regulated entity whose AI systems have become embedded in critical operations. Model providers have had outages. API rate limits have been hit during peak periods. Model behaviour has changed between versions in ways that affected downstream system outputs.

Has your APRA-regulated entity assessed the operational resilience of its AI model providers? Can you demonstrate what happens to your critical operations if the API is unavailable for 4 hours? 24 hours? 72 hours?

For most regulated entities, the answer is that this assessment has not been done because AI providers were not in the material service provider register when CPS 230 mapping was completed.

Tolerance Levels and AI System Failure

CPS 230 requires documented tolerance levels — maximum acceptable disruption duration and impact for each critical operation. The challenge with AI systems is that they fail in ways that human-operated systems do not.

Traditional systems fail in binary ways: the server is up or it is down. AI systems can fail in subtler ways:

• Silent degradation — the model continues running but accuracy drops because input data distribution has shifted
• Confident errors — the model produces outputs with high confidence scores that are nonetheless wrong
• Scope violations — the model handles designed-parameter inputs correctly but fails on edge cases outside that scope
• Third-party dependency cascades — the model API is available but a supporting tool is degraded, causing incomplete outputs without erroring

Each of these failure modes has different detection and recovery characteristics. For CPS 230 compliance, regulated entities need tolerance levels for AI failure modes, not just for traditional system failure.

Practical requirement: For each AI system identified as part of a critical operation, document:

• What does failure look like? (Total unavailability vs. degraded accuracy vs. scope violation)
• What is the detection mechanism for each failure mode?
• What is the maximum acceptable time from failure onset to detection?
• What is the maximum acceptable time from detection to recovery?
• What is the human fallback procedure if the AI system is unavailable?

Operational Resilience Testing and AI

CPS 230 requires regulated entities to test their operational resilience. AI systems introduce specific scenarios absent from traditional resilience testing frameworks:

Model version change scenario: What happens when your AI model provider releases a new version with changed behaviour? How does your entity detect that outputs have changed materially?

Input distribution shift scenario: What happens when business conditions change and the data your AI processes no longer matches the distribution it was trained on?

Third-party AI API degradation scenario: What happens when the model API is available but responding 5× slower than usual?

Data pipeline failure scenario: What happens when the data feeding your AI system is corrupted, delayed, or incomplete? Does the AI fail gracefully or produce confident outputs based on bad data?

These scenarios should be in your CPS 230 resilience testing programme. For most APRA-regulated entities, they are not yet.

The Three Categories of APRA-Regulated AI Systems

Category 1: AI Systems in Critical Operations

AI systems integral to a critical operation under CPS 230. Examples:

• Credit decisioning models in retail banking
• Claims triage and assessment AI in general insurance
• Member communication prioritisation agents in superannuation
• Fraud detection models in payments processing

CPS 230 requirements: In the critical operations register; tolerance levels for AI-specific failure modes; human fallback procedures documented and tested; AI providers assessed as material service providers; AI system resilience included in annual testing.

Category 2: AI Systems Supporting Critical Operations

AI systems whose failure would degrade a critical operation. Examples:

• Document processing AI feeding data into a critical credit workflow
• Data extraction agents pre-processing inputs for a fraud detection model
• Reporting AI producing data the critical operation's oversight relies on

CPS 230 requirements: Identified as dependencies of critical operations; tolerance levels for degradation; service provider risk assessment; included in resilience testing as upstream dependencies.

Category 3: AI Systems Not in Critical Operations

AI used for non-critical functions — marketing personalisation, internal productivity, document summarisation.

CPS 230 requirements: Standard service provider risk assessment for material third-party AI providers. Subject to APRA's technology risk expectations under CPS 234.

What a CPS 230-Compliant AI System Architecture Looks Like

Graceful Degradation by Design

A CPS 230-compliant AI system in a critical operation must degrade gracefully rather than fail completely:

Human escalation pathways: When AI confidence falls below a defined threshold, or when inputs are outside the validated operating range, the system routes to human review automatically — not dependent on a human monitoring a dashboard.

Fallback modes: A documented and tested fallback mode allowing the critical operation to continue at reduced AI-augmented capacity. For a credit decisioning system, this might mean a simplified rules-based scoring model handling minimum viable volume while the primary AI is restored.

Queuing and backlog management: Documented and tested procedures for application queuing when the AI system is unavailable — how long can items queue, what happens to items beyond tolerance duration.

Monitoring and Alerting for AI-Specific Failure Modes

Standard infrastructure monitoring does not detect AI-specific failure modes. CPS 230 compliance requires:

Output distribution monitoring: Tracking the distribution of AI outputs over time and alerting when the distribution shifts materially from validated baselines. A credit model approving 85% of applications instead of its validated 65% is a signal requiring investigation.

Input distribution monitoring: Tracking inputs and alerting when they shift outside the validated range. AI models validated on pre-2024 economic data may produce unreliable outputs when conditions change materially.

Confidence distribution monitoring: For models producing confidence scores, tracking whether confidence distributions are consistent with validated performance.

Third-party API health integration: Monitoring AI API provider health in the same operational dashboard as internal systems, with alerts for latency spikes, error rate increases, and service degradation notices.

Audit Trails That Support CPS 230 Evidence Requirements

APRA expects regulated entities to produce evidence of what happened during a disruption, how it was detected, and how it was managed. For AI systems:

Decision audit logs: Every AI system decision logged with timestamp, inputs, outputs, confidence, model version, and any flags or escalations triggered. This is the same audit log required for the Privacy Act's December 2026 automated decision-making transparency obligations — building it satisfies both requirements simultaneously.

Model version history: A complete record of which model version was in production at any point in time. When APRA asks "what was your AI system doing during the March 2026 market volatility event?", you need to answer specifically — not just "it was running."

Incident records: Complete records of every AI system incident — detection timestamp, failure mode, duration, impact assessment, actions taken, and resolution timestamp.

The Intersection with Privacy Act December 2026 Obligations

For APRA-regulated entities, CPS 230 compliance work and Privacy Act December 2026 automated decision-making compliance work overlap substantially.

Both require:

• A register of AI systems making or substantially influencing decisions (CPS 230 critical operations mapping; Privacy Act automated decision-making inventory)
• Audit trails for AI system actions (CPS 230 incident records; Privacy Act explanation capability)
• Human oversight mechanisms (CPS 230 fallback procedures; Privacy Act human review for significant automated decisions)
• Third-party vendor assessment (CPS 230 material service provider assessment; Privacy Act data processing agreement requirements)

An APRA-regulated entity that builds CPS 230 AI compliance infrastructure correctly will have most of the Privacy Act December 2026 infrastructure already in place. One build, two compliance outcomes.

The APRA Supervision Timeline

APRA signalled clearly in late 2025 that AI governance would be a focus of its 2026 supervisory activities:

• Whether AI systems embedded in critical operations are captured in CPS 230 frameworks
• Whether AI model providers are being assessed as material service providers
• Whether operational resilience testing includes AI-specific scenarios
• Whether boards have appropriate visibility over AI system risk in critical operations

APRA's 2026 supervisory approach includes thematic reviews expected to produce industry-wide findings for all regulated entities, not just those selected for review.

The 90-Day CPS 230 AI Compliance Roadmap

Days 1–21: AI System Inventory and Classification

Conduct a systematic inventory of all AI systems deployed. For each system: Category 1 (part of a critical operation), Category 2 (dependency of a critical operation), or Category 3 (non-critical function).

This exercise typically surfaces AI systems not captured in the original CPS 230 mapping — systems deployed in the 12–18 months since mapping was completed, or AI capabilities embedded in third-party software that were not identified as AI during the original assessment.

Days 22–45: Critical Operations Register Update and Tolerance Level Documentation

For each Category 1 and Category 2 system:

• Update the critical operations register to identify the AI system as a component
• Document AI-specific tolerance levels (detection time, recovery time, degradation thresholds)
• Document human fallback procedures
• Assess whether the AI model provider meets the CPS 230 definition of a material service provider

Days 46–70: Monitoring and Alerting Architecture

For each Category 1 and Category 2 system:

• Implement output distribution monitoring with alerts for material shifts
• Implement input distribution monitoring
• Integrate third-party AI provider health into operational monitoring
• Validate that existing audit logging is sufficient for CPS 230 evidence requirements

Days 71–90: Resilience Testing Integration

• Update the operational resilience testing programme to include AI-specific scenarios
• Conduct at least one table-top exercise covering an AI system failure in a critical operation
• Document testing results and identify gaps
• Present AI system CPS 230 compliance status to the risk committee

How Akira Data Supports CPS 230 AI Compliance

AI Readiness Sprint (AUD $7,500 · 2 weeks) Includes a CPS 230 AI system inventory and classification assessment — Category 1, 2, and 3 systems identified, gaps against CPS 230 requirements documented, and a prioritised remediation roadmap.

Privacy-Safe AI Implementation (from AUD $20,000) Full CPS 230-compliant AI system architecture: graceful degradation design, monitoring and alerting for AI-specific failure modes, audit trail infrastructure, and material service provider assessment for AI API providers. Every system built is also compliant with the December 2026 Privacy Act automated decision-making transparency obligations.

AI Strategy Retainer (AUD $8,000/month) Ongoing CPS 230 AI governance — quarterly critical operations register reviews as new AI systems are deployed, annual resilience testing programme updates, and APRA supervisory preparation.

*Akira Data builds CPS 230-compliant AI systems for APRA-regulated entities — operational resilience by design, Privacy Act compliant, with the audit trail infrastructure that satisfies both regulatory frameworks simultaneously. [Start with an AI Readiness Sprint](/contact) — AUD $7,500, two weeks, one complete CPS 230 AI system inventory and gap assessment.*

*This article was published 21 March 2026. APRA CPS 230 (Operational Resilience) came into effect 1 July 2025. This article is general information and does not constitute legal or regulatory advice. Consult your legal advisers for guidance specific to your organisation.*