APRA CPS 230: AI for Operational Risk

APRA CPS 230 and the New Weight on Operational Risk

On 1 July 2025, APRA's Prudential Standard CPS 230 Operational Risk Management came into force. It replaced a scatter of older standards on outsourcing and business continuity with a single, more demanding regime. For every APRA-regulated entity, operational risk is now a board-level obligation with hard expectations around critical operations, tolerance levels for disruption, and the management of the third parties you depend on.

This is not a light-touch guideline. CPS 230 applies to authorised deposit-taking institutions, general insurers, life companies, private health insurers, and registrable superannuation entity (RSE) licensees. If you run risk, operations, technology or finance at a midsize bank, insurer, super fund or credit union (roughly the 50 to 500 employee organisations that sit below the big four but well inside the regulatory net), CPS 230 has already reshaped what your board expects to see.

There is a second audience for this guide, and it is easy to miss. If your business is a service provider to an APRA-regulated entity (a technology vendor, a claims processor, an administration platform, a data or analytics firm), CPS 230 reaches you too, through the contracts and oversight your regulated clients are now required to impose. The obligations flow downhill.

AI has a genuine role in meeting CPS 230, particularly in the continuous monitoring and evidence-gathering that the standard demands. It also has clear limits, and pointing an AI tool at a prudential obligation without governance is its own operational risk. This guide is for the person who has to make CPS 230 work in practice, and wants to know where automation earns its place and where a human has to own the decision.

What CPS 230 actually requires

• A sound operational risk management framework, with controls that are identified, monitored and tested, not just documented once.
• Identification of critical operations and board-approved tolerance levels for how long they can be disrupted, how much data can be lost, and how quickly they must recover.
• A service provider management policy, formal agreements, and active monitoring of the parties you rely on.
• A register of material service providers, linking each to the critical operations they support.

The shift from the old regime to the new one

The easiest way to understand CPS 230 is as a move from point-in-time paperwork to continuous, evidenced control. Under the older outsourcing and business continuity standards, an entity could satisfy much of its obligation with a policy document, an annual review and a contract on file. CPS 230 expects you to know your critical operations, to have tested that you can keep them running inside defined tolerances, and to be actively watching the service providers that sit underneath them.

The practical consequence is a large increase in the amount of evidence a regulated entity has to produce and keep current. Control testing, incident records, service provider performance data, and tolerance breach analysis all have to be captured continuously rather than assembled once a year for an audit. This is precisely the kind of high-volume, repetitive evidence work where AI can carry real load, provided the judgement stays human.

Where AI genuinely helps under CPS 230

CPS 230 is demanding in ways that play to automation's strengths: it wants continuous monitoring, consistent record-keeping, and fast synthesis of large amounts of operational data. None of that removes the need for accountable humans, but it is exactly the reading, tracking and drafting load that a well-governed AI system can lighten.

Four use cases stand out for midsize regulated entities and their providers:

• Continuous control monitoring. AI can watch control logs, incident systems and change records, and surface where a control is failing or drifting before it becomes a reportable event. The human risk owner decides what it means and what to do.
• Evidence assembly. Much of the CPS 230 burden is proving that controls work. AI can pull the relevant logs, test results and incident history for a given critical operation into a coherent evidence pack, ready for a human to review and sign.
• Service provider oversight. AI can track SLA performance, contract renewal dates and reported incidents across a large vendor base, and flag where a material service provider is slipping against expectations.
• Incident synthesis. When something goes wrong, AI can rapidly assemble the timeline from logs and tickets so the incident review starts from facts rather than from scratch. The root-cause judgement, and any decision about tolerance breach reporting, stays with people.

That last pattern (fast, on-premise incident synthesis) is the same problem Solve8 built RootCauseAI to solve. The lesson from building it is directly relevant here: the value is in getting a defensible timeline in front of an expert quickly, not in letting the tool decide what the incident means.

Critical operations and tolerance levels: a human judgement

The heart of CPS 230 is the requirement to identify your critical operations and set tolerance levels for their disruption. A critical operation is a process that, if disrupted beyond tolerance, would have a material adverse impact on depositors, policyholders, beneficiaries or other customers, or on the entity's role in the financial system. Tolerance levels cover the maximum time a service can be unavailable, the maximum data loss you can absorb, the recovery time for information assets, and the minimum resources needed to keep operating.

These are not judgements you delegate to an algorithm. The board has to approve the business continuity plan and the tolerance levels, review testing results, and oversee the response to any findings. AI can help you map dependencies, model scenarios and keep the evidence current, but the decision about what is critical and how much disruption is acceptable is a governance decision that sits with people who carry the accountability.

The material service provider obligation and its deadlines

The service provider requirements are where CPS 230 has bitten hardest, and where the timeline matters. A service provider is material if the entity relies on it to undertake a critical operation, or if the arrangement exposes the entity to material operational risk. Regulated entities must maintain a register of these providers, link each to the critical operations it supports, and be able to submit that register to APRA.

There is nuance in the transitional arrangements worth getting right. For existing contractual arrangements with service providers, CPS 230's requirements apply from the earlier of the next renewal date or 1 July 2026. And on 30 April 2026, APRA released final targeted amendments to CPS 230 that introduce limited exemptions from specific contractual requirements for certain categories of service provider arrangements, where full contractual compliance is not practicable. The updated CPS 230 and the accompanying Prudential Practice Guide CPG 230 commence on 1 July 2026. If your service provider register and contract remediation programme has not accounted for those amendments, it is worth a review against the current text on APRA's site rather than an older draft.

This is a natural place for AI to help with the mechanical load: reading a large contract portfolio to flag which agreements touch critical operations, which lack the clauses CPS 230 expects, and which renew before the transitional cut-off. A governed AI contract review workflow can triage a vendor book far faster than a manual pass, so your legal and procurement team spends its time on the judgement calls rather than the sorting.

If you are a service provider to an APRA-regulated entity

Here is the part that catches midsize technology and services businesses by surprise. You do not have to be APRA-regulated to feel CPS 230. If you provide services to a regulated entity and you sit anywhere near one of their critical operations, your regulated clients are now required to bring you inside their service provider management regime. That means stronger contractual terms, the right to monitor your performance, notification obligations when things go wrong, and evidence that you can meet the tolerances your client has committed to.

For a fintech, a claims platform, an administration provider or a data business, this is both a cost and an opportunity. The cost is the contractual and assurance overhead. The opportunity is that a provider who can walk into a procurement conversation with clean evidence of its own operational controls, incident history and continuity testing has a real advantage over one who cannot. Being easy to onboard under CPS 230 becomes a genuine differentiator.

The figures in that summary are deliberately qualitative. CPS 230 is about the reliability of your operations, not a headline saving, and any quantified benefit depends entirely on your starting point. The honest promise of AI here is a lower, more consistent evidence burden and earlier warning of control drift, not a number you can put in a board pack without doing your own measurement first.

Where AI cannot help, and where it adds risk

It is worth being direct about the limits, because CPS 230 sits in a regulated environment where getting it wrong has consequences beyond an internal audit finding.

AI cannot own accountability. Under CPS 230, named individuals and the board are accountable for operational risk, for tolerance levels and for the decisions that flow from a disruption. An AI system that assembles evidence or flags a control failure has not made a decision; a person has to. Any process that lets "the model flagged it as fine" substitute for a human sign-off has misunderstood the standard.

AI can also become an operational risk in its own right. If you deploy an AI system into a critical operation (say, a model that helps triage incidents or monitor controls), that system is now part of your operational risk surface. It has to be understood, tested, monitored and included in your continuity thinking like any other dependency. And if the AI tool is itself provided by a third party that sits near a critical operation, it may be a material service provider that belongs on the register.

Then there is the data question. Feeding operational logs, incident detail and customer-adjacent information into an AI tool without confirming where that data goes, how it is retained, and whether it trains a shared model is a straightforward way to create a privacy and confidentiality exposure. The failure modes are the same ones we set out in how the wrong AI tools leak business data, and in a regulated financial environment the stakes are higher. Data handling, hosting and sovereignty are not optional details here; the data sovereignty guide covers why for Australian regulated entities.

Fitting CPS 230 AI into your governance

Using AI for CPS 230 work is not a standalone decision. It sits inside how your organisation governs AI generally: who approves a use case, what data it can touch, who signs off on outputs, and how you evidence all of that. That is doubly true when the use case is itself a compliance obligation. If you have not put that structure in place, the AI governance framework for Australian midsize business is the place to start, and the AI vendor selection questions are the ones to ask before you let any tool near operational data.

For the security-control side specifically, the 50-point AI security checklist gives you a concrete baseline to test any AI system against before it goes near a critical operation. And because CPS 230 overlaps with the broader Australian cyber and incident-reporting landscape, it is worth reading it alongside the Cyber Security Act 2024 ransomware reporting obligations, which apply to many of the same entities.

The pattern across all of these is consistent. AI is a leverage tool for accountable humans working under real regulatory constraints. It monitors faster, tracks more consistently and drafts more quickly than a stretched risk team. It does not carry accountability, it does not decide what is critical, and it does not report to APRA. Treat it as the most tireless analyst on your team, one whose work you always verify, and it earns its place in your operational risk function.

What to do this quarter

1. Reconcile your register against the current standard. Confirm your material service provider register reflects the April 2026 amendments and the 1 July 2026 updated CPS 230 and CPG 230, not an earlier draft.
2. Triage your contract portfolio. Use a governed AI review to flag which service provider agreements touch critical operations, which lack the expected clauses, and which renew before the transitional cut-off.
3. Map your AI systems as dependencies. Any AI tool sitting near a critical operation is part of your operational risk surface and may itself be a material service provider. Treat it accordingly.
4. Write the sign-off rule down. Every AI-generated flag, evidence pack or incident timeline is verified by a named human before it informs a decision or reaches the board or APRA.
5. If you are a provider, get audit-ready. Assemble clean evidence of your own controls, incidents and continuity testing. Under CPS 230, being easy to assure is a competitive advantage.

The regulated entities that will handle CPS 230 best are not the ones that avoid AI, and they are not the ones that trust it blindly. They are the ones that use it to carry the monitoring and evidence load, while keeping every accountable judgement firmly in human hands.

Related Reading:

• AI contract review for midsize legal and procurement teams - The document-review capability applied to a service provider portfolio.
• AI governance framework for Australian midsize business - The structure that any compliance-focused AI use case sits inside.
• The 50-point AI security checklist - A concrete baseline before AI goes near a critical operation.
• Cyber Security Act 2024 ransomware reporting - The overlapping incident-reporting regime for many of the same entities.
• How the wrong AI tools leak business data - The confidentiality failure mode to avoid with operational data.

Sources: APRA Prudential Standard CPS 230 Operational Risk Management and Prudential Practice Guide CPG 230; APRA operational risk management guidance and commencement dates; APRA April 2026 targeted amendments to CPS 230; legal analysis of CPS 230 service provider and transitional requirements from Australian firms (Minter Ellison, Corrs Chambers Westgarth, Dentons); Privacy Act 1988 and OAIC guidance on personal information. Solve8 synthesis informed by enterprise integration experience across Australian organisations. This article is general information, not legal or prudential advice.