APRA CPS 230: A Proof Standard Wearing a Policy Standard’s Clothes

CPS 230 doesn’t ask whether you manage operational risk. It asks you to prove your critical operations survive.

If you run technology for an APRA-regulated entity — a bank, an insurer, a super fund — you have been living under CPS 230 since 1 July 2025. Most of the market treated it as a business-continuity refresh with some vendor paperwork attached. That reading will get you through a quiet year and fail you the moment APRA actually looks, because CPS 230 is not a policy standard. It is a proof standard. The difference is the whole point, and almost nobody selling “CPS 230 compliance” will say so plainly.

Here is the plain version.

What it actually is

CPS 230 is APRA’s cross-industry prudential standard for operational risk management. It swept away the old outsourcing and business-continuity standards — CPS 231, CPS 232, and the operational-risk guidance that sat around them — and replaced the lot with a single instrument built around resilience rather than documentation. It applies to everyone APRA prudentially regulates: authorised deposit-taking institutions, general and life insurers, private health insurers, and RSE licensees.

It has been in force since 1 July 2025. The one deadline still ahead of most firms is the service-provider tail: for contracts that pre-date the standard, the requirements bite at the earlier of the next renewal or 1 July 2026. In April 2026 APRA finalised a set of targeted amendments that carve limited exemptions from specific contractual requirements for certain categories of service provider where a compliant clause simply isn’t obtainable — useful relief, but relief at the edges. The spine of the standard did not move.

The spine is three sentences. An APRA-regulated entity must manage its operational risks with controls that actually work. It must keep its critical operations running within board-approved tolerance levels through severe but plausible disruption. And it must manage the risk that its service providers introduce. Everything else in the standard is those three obligations, made specific.

Why it’s a proof standard

Read the three obligations again and notice what each one quietly demands.

“Manage your operational risks with effective controls” is not satisfied by owning a risk register. It’s satisfied by controls that are designed and operating effectively — a phrase auditors recognise, because it means someone can be asked to demonstrate the operation, not just point at the policy.

“Keep critical operations within tolerance” requires you to have named your critical operations, set a specific, board-approved tolerance for each — a maximum outage, a maximum data loss — and be able to show, through tested scenarios, that you actually stay inside it when something breaks. A tolerance nobody has tested is a number in a slide, and APRA has been explicit that it wants the test, not the slide.

“Manage service-provider risk” means maintaining a register of your material service providers, holding contracts that contain specific clauses — audit and APRA access, exit and contingency, subcontracting and liability, data ownership and return — and understanding your fourth-party dependencies, the subcontractors your providers rely on to keep your critical operations alive.

And then the tell, the part that separates CPS 230 from the standards it replaced: the incident clock. You must notify APRA as soon as possible and no later than 72 hours after an operational-risk incident you judge likely to have a material financial impact or a material impact on your critical operations — and no later than 24 hours after a disruption pushes a critical operation outside its approved tolerance. You cannot meet a 24-hour clock with a data model that takes a fortnight to answer “which critical operation was affected, and were we inside tolerance?” The clock is the proof requirement made unforgiving.

That is why I call it a proof standard. Every obligation in it resolves, under pressure, to show me — show me the operation, show me the tolerance, show me the test, show me the provider, show me you knew inside the day. And your board carries the accountability for all of it; CPS 230 puts the oversight squarely on directors, not on a compliance function they can point at afterwards.

Where it actually breaks

It breaks in the same place every operational-resilience regime breaks: the model underneath.

You cannot report against a critical operation you have not defined as a distinct thing your systems recognise. You cannot answer a 24-hour tolerance-breach question if “the payments service” is really nine systems, two of which nobody currently owns, mapped in a spreadsheet that a person maintains by hand. You cannot evidence fourth-party dependency if your service-provider register lists vendors but not the operations they underpin. The standard asks you to attest to relationships — operation to system to provider to subcontractor to tolerance — and if your data model doesn’t hold those relationships, the attestation gets assembled manually, late, and defensively, which is precisely the posture a supervisor is trained to distrust.

This is not a tooling problem, and buying a CPS 230 platform will not solve it. A platform will give you somewhere to store the register. It will not tell you what your critical operations are, and it will faithfully store whatever confusion you feed it. The work that matters happens one layer down: naming the critical operations, tracing each to the systems and providers that carry it, attaching a tolerance you have actually tested, and holding all of that in a model that can answer the clock. Get that right and the tool is an implementation detail. Get it wrong and no tool will save you.

If you already did DORA, you’re most of the way there

There is one genuinely good piece of news, and it’s strategic. CPS 230 is DORA-shaped. Critical operations map to DORA’s critical or important functions. Tolerance levels map to impact tolerances. Material service providers map to critical ICT third parties. The 72-hour and 24-hour clocks rhyme with DORA’s incident-reporting cadence. Board accountability sits in the same place.

If you are a group with both Australian and EU exposure, this is the cross-regime dividend done properly: one control environment, evidenced twice. The critical-operations register you built for DORA is largely the register CPS 230 wants, attested against a different reference. The scenario tests satisfy both. The provider clauses overlap heavily. What you cannot do is run two parallel programmes and two parallel registers — that way you pay twice and reconcile forever. The move is to build the model once, deep enough to carry either obligation, and generate the two attestations from the same source. That only works if the model was designed to hold the relationships in the first place, which brings us back to the layer that always matters.

The short version

CPS 230 has been in force for a year, most Australian firms are treating it as a documentation exercise, and it is a proof exercise. The firms that will struggle are the ones whose critical operations live in people’s heads and spreadsheets; the firms that will breeze it are the ones whose data model can already answer “which operation, which provider, what tolerance, were we inside it, and can you show me by tomorrow morning.” If you’re not sure which one you are, that uncertainty is the finding — and it’s cheaper to discover it now than during the 24 hours after something breaks.

Sixteen Pillars works where a regulator defines what “good” means, and CPS 230 defines it unusually clearly. If you carry APRA obligations — or DORA and APRA both — the question isn’t whether you have the controls. It’s whether you can prove your critical operations survive, inside the clock. That’s the conversation to have.