CPS 230 has been in force since 1 July 2025, and the transitional runway for pre-existing service provider contracts ran out on 1 July 2026. Most of what ranks for CPS 230 is legal commentary; what practitioners actually need is a working register. This page explains each artefact column by column and gives you two free CSV templates, a critical operations register and a tolerance levels register, to start from today.
Prudential Standard CPS 230 Operational Risk Management applies to all APRA-regulated entities: ADIs, general, life and private health insurers, and RSE licensees. It replaced the old outsourcing and business continuity standards (CPS 231 and CPS 232 and their industry equivalents) with one operational risk standard. The standard and its practice guide, CPG 230, are published by APRA at apra.gov.au.
Three dates matter, and all of them have now passed:
Strip away the commentary and CPS 230 requires three living artefacts, each owned, evidenced and reviewed:
The business processes which, if disrupted beyond tolerance, would cause material harm to depositors, policyholders, beneficiaries or other customers, or to your role in the financial system. Identified, justified, owned and kept current.
For each critical operation: the maximum period of disruption you would tolerate, the maximum data loss you would accept, and the minimum service level you will maintain while running on alternative arrangements.
A comprehensive register of the providers you rely on for critical operations or that expose you to material operational risk, submitted to APRA annually.
APRA has said it presumes certain operations are critical unless the entity can justify otherwise: payments, deposit-taking and management, custody, settlements and clearing for ADIs; claims processing for insurers; investment management and fund administration for RSE licensees; and customer enquiries and the systems supporting these operations across the board. If one of those is missing from your register, you need a documented reason.
The standard also sets notification clocks: notifying APRA as soon as possible, and within 72 hours, of an operational risk incident likely to have a material impact; within 24 hours where a critical operation is disrupted outside tolerance; and within 20 business days of entering into or materially changing a material service provider agreement. Check the wording of the standard itself before you hard-wire these clocks into your incident process.
Download the critical operations register template (CSV). It ships with three worked example rows, each clearly marked EXAMPLE, covering an ADI, an insurer and an RSE licensee. Delete them before use. Here is what each column is for and why it earns its place:
| Column | What goes in it | Why it matters |
|---|---|---|
| operation_id | A stable identifier that never changes, even if the operation is renamed | Everything else (tolerances, incidents, provider records) cross-references this ID |
| operation | The business process as a customer would experience it, e.g. payments processing, claims processing | CPS 230 is about operations, not systems; systems belong in the dependencies column |
| description | End-to-end scope: where the process starts, where it finishes, what is in and out | Scope ambiguity is where registers quietly go wrong; boundaries make tolerances testable |
| apra_presumed | Whether this operation is on the APRA presumed-critical list for your industry | Presumed operations excluded from the register need a written justification |
| criticality_rationale | Why disruption beyond tolerance would materially harm customers or the financial system | This is the sentence a supervisor will read first; it should stand on its own |
| owner | A named accountable role, not a team or a committee | Accountability under CPS 230 sits with people; shared ownership is no ownership |
| tolerance_ref | The ID of the matching row in the tolerance levels register | Every critical operation must have tolerance levels; an empty cell here is a finding |
| dependencies | Systems, data sets, key people and infrastructure the operation cannot run without | This is what your scenario testing and BCP have to actually cover |
| providers | External providers the operation relies on, with the service each one supplies | Reliance for a critical operation is a trigger for material service provider treatment |
| provider_register_ref | IDs of the matching entries in your material service provider register | Keeps the two registers reconciled instead of drifting apart |
| last_review / next_review | When the row was last confirmed accurate and when it falls due again | A register nobody has reviewed is evidence against you, not for you |
| status | Current, under review, or flagged, with a short reason | Lets the Board see at a glance which rows are settled and which are moving |
Download the tolerance levels template (CSV), again with three clearly marked example rows. CPS 230 requires tolerance levels for each critical operation across three dimensions, and the template maps one column to each: the maximum tolerable period of disruption (max_tolerable_disruption), the maximum data loss you would accept (data_loss_tolerance), and the minimum service level you will maintain while operating under alternative arrangements (min_service_level). Tolerance levels must be approved by the Board.
| Column | What goes in it | Why it matters |
|---|---|---|
| tolerance_ref | Stable ID, referenced from the critical operations register | One tolerance record per operation keeps the pair reconcilable |
| operation | The critical operation this tolerance belongs to | Tolerances attach to operations, never to systems |
| disruption_type | The scenario being tolerated: technology outage, provider failure, site loss, data corruption | One operation can carry different tolerances for different disruption types |
| max_tolerable_disruption | The longest outage the entity will accept, in concrete units | Breaching this outside tolerance starts a 24-hour APRA notification clock |
| data_loss_tolerance | The maximum data loss accepted, expressed per data set where tolerances differ | Some data (member balances, ledgers) will carry nil tolerance; say so explicitly |
| min_service_level | What you will keep delivering while on workarounds, e.g. hardship claims triaged within 24 hours | The most commonly forgotten of the three mandated dimensions |
| rationale | Why these numbers and not others: customer harm, settlement obligations, workaround capacity | A tolerance without a rationale is a guess in a table |
| approved_by | Board approval, with meeting date or minute reference | Board approval is a CPS 230 requirement, and the reference is your evidence of it |
| review_date | When the tolerance next comes back for review | Tolerances should be revisited when the operation, its dependencies or your risk appetite change |
A practical test before anything goes to the Board: for each row, ask whether you could detect a breach with the monitoring you have today, and whether your scenario testing has ever exercised that disruption type. If either answer is no, the number is aspiration rather than tolerance.
Listing the core banking platform as a critical operation inverts the standard. The operation is payments; the platform is a dependency of it. Get this wrong and every downstream artefact inherits the error.
IT recovery targets describe what technology can do. Tolerance levels describe what the Board will accept on behalf of customers. Setting one equal to the other by default skips the actual decision CPS 230 is asking for.
Time and data loss get all the attention, but the standard also asks what service you will keep providing while running on alternative arrangements. Hardship and urgent cohorts usually need their own line.
If payments, claims processing or fund administration is absent from your register, silence is not a position. Record the justification, and expect it to be tested.
Material service providers are defined by reliance and risk, not by whether a contract exists, and the standard expects you to understand material subcontracting chains, not just direct counterparties.
Operations change, providers change, dependencies change. A register with review dates from last year tells a supervisor the process is not embedded, whatever the content says.
The providers column in the critical operations register feeds directly into your material service provider register, which CPS 230 requires you to maintain comprehensively and submit to APRA annually. Reliance for a critical operation is one trigger for materiality; exposure to material operational risk is the other, so the provider register will usually be longer than the union of your providers columns. Where the service is technology, the Australian Cyber Security Centre's cyber supply chain risk management guidance at cyber.gov.au pairs well with the CPS 230 lens. Our third-party risk management page covers how the engine treats providers as first-class records rather than spreadsheet rows.
The templates on this page will get you a defensible starting position. Their weakness is the same as every spreadsheet's: nothing connects them to reality. On the CyberSentien engine, the CPS 230 module and the TPRM module hold these registers as structured, cross-linked records: each operation points at its tolerance record and its providers, each row carries an owner and review dates, and supporting evidence attaches to the record itself rather than living in someone's inbox. Posture is reported deterministically from the evidence actually on file, so a missing tolerance link or a lapsed review is visible instead of buried, and the Ask assistant answers questions only from that evidence, never from thin air. The platform page explains the wider engine, and because APRA-regulated data should not leave the country to be assured, everything runs on Australian-sovereign hosting. Pricing is on the pricing page.
See the CPS 230 module on the live demo Talk to us about your register
All APRA-regulated entities: authorised deposit-taking institutions, general insurers, life companies, private health insurers and RSE licensees. Details, the standard itself and CPG 230 are on apra.gov.au. If you are not APRA-regulated, the artefacts are still a sound operational resilience pattern, but the obligations do not bind you.
The pre-existing-contract relief and the non-SFI extension have both expired, so the requirements now apply in full. If gaps remain, the practical path is to establish an honest baseline quickly, prioritise the presumed-critical operations, and engage openly with your supervisor rather than presenting a polished register you cannot evidence. We cannot advise you on your regulatory position; we can help you build the baseline fast.
A critical operation is a business process whose disruption beyond tolerance would materially harm customers or your role in the financial system. A material service provider is an external party you rely on for such an operation, or one that exposes you to material operational risk. They live in separate registers that must reconcile: every provider named against a critical operation should appear in the provider register.
There is no prescribed number, and any figure we quoted would be an estimate. In practice the APRA presumed list for your industry sets the floor, and most entities add a handful more based on their own customer-harm analysis. A register with fifty rows usually means systems have been listed instead of operations; a register with two usually means the analysis has not been done.
Yes. CPS 230 requires Board approval of tolerance levels, which is why the template carries an approved_by column with space for a minute reference. Treat that cell as evidence, not decoration: it is the first thing worth checking in an internal review.
They are a starting structure, not a compliance outcome. The example rows are illustrative and must be replaced with your own analysis, the columns will need tailoring to your industry and scale, and a register only has value if it is reviewed, evidenced and connected to your BCP and scenario testing. That ongoing part is what the engine automates.
The templates are provided free, with no sign-up. The example rows are fictional and clearly marked; replace them with your own analysis before any internal or regulatory use.
Every capability referenced on this page is live on the CyberSentien engine — see it on the always-live gated demo. Nothing on this page is legal advice.