APRA’s CPS 230 is more than a compliance checklist; it’s a framework for building a defensible, auditable, and genuinely resilient operational risk program. Unlike tiered frameworks such as the Essential Eight, CPS 230 does not use maturity levels. Instead, it sets outcome-focused requirements across five interconnected areas, supported by APRA’s Prudential Practice Guide CPG 230, which describes what better practice looks like for each.

An auditor’s or supervisor’s goal is to verify not only that policies and plans exist, but that they are implemented consistently and effectively, and that the entity can actually deliver its critical operations within tolerance through severe but plausible disruptions. This guide breaks down each requirement area, what compliance looks like in practice, and what an assessor will look for as proof.

Understanding the Structure of CPS 230

CPS 230’s requirements can be grouped into five areas:

#	Requirement Area	Core Obligation
1	Governance, Roles, and Responsibilities	The Board is ultimately accountable for operational risk management, business continuity, and service provider arrangements, with clear senior management roles.
2	Operational Risk Management	Identify, assess, and manage the full range of operational risks with an up-to-date risk profile and effective, tested internal controls.
3	Operational Risk Incident Management	Identify, escalate, record, and remediate incidents and near misses, and notify APRA of material incidents within 72 hours.
4	Business Continuity	Maintain a register of critical operations with Board-approved tolerance levels and a credible, annually tested BCP.
5	Management of Service Provider Arrangements	Maintain a service provider management policy, an MSP register submitted to APRA annually, compliant formal agreements, and ongoing monitoring.

Proportionality: An entity’s approach must be appropriate to its size, business mix, and complexity. Smaller, simpler entities can meet the requirements with simpler arrangements, but no requirement area can be skipped. Non-significant financial institutions (non-SFIs) benefit from deferred commencement of certain business continuity requirements until 1 July 2026.

Requirement-Level Enablement

1. Governance, Roles, and Responsibilities

Compliance Goal: Establish clear, top-down accountability so that operational resilience is owned by the Board and driven by senior management, not delegated to a compliance function.

The Requirement in Practice:

Not Meeting:
- Operational risk is managed informally within IT or risk teams; the Board receives little or no operational risk reporting and has not approved tolerance levels, the BCP, or the service provider management policy.
Meeting:
- The Board oversees operational risk management and the effectiveness of key internal controls, receives regular updates on the operational risk profile, and ensures senior management acts on areas of concern.
- The Board approves the BCP and tolerance levels for disruptions to critical operations, reviews the results of BCP testing, and oversees the execution of findings.
- The Board approves the service provider management policy and reviews risk and performance reporting on material service providers.
- Clear roles and responsibilities are set for senior managers across operational risk management, business continuity, and service provider management, and senior management provides the Board with clear information on impacts to critical operations when resilience-affecting decisions are made.

How Auditors and Supervisors Evaluate This:

Review Board and committee charters, delegations, and minutes evidencing approval of tolerance levels, the BCP, and the service provider management policy.
Examine Board reporting packs for operational risk profile updates, control effectiveness reporting, and MSP risk and performance reporting.
Check accountability mapping (for example, under the Financial Accountability Regime) showing named senior manager ownership of operational risk, business continuity, and service provider management.

Key Consideration: Board approval must be genuine engagement, not rubber-stamping. CPG 230 emphasizes that the Board should be able to challenge management’s proposed tolerance levels and testing outcomes, so retain evidence of discussion and challenge, not just final sign-off.

2. Operational Risk Management (Risk Profile and Controls)

Compliance Goal: Maintain a comprehensive, current assessment of operational risk and a control environment that is demonstrably designed and operating effectively.

The Requirement in Practice:

Not Meeting:
- Risk assessments are static documents updated annually at best; the entity cannot map which processes, systems, people, and providers support its critical operations; controls are untested or testing is ad hoc.
Meeting:
- The entity manages its full range of operational risks, including legal, regulatory, compliance, conduct, technology, data, and change management risk, across end-to-end business processes.
- The entity identifies and documents the processes and resources needed to deliver critical operations, including people, technology, information, facilities, and service providers, the interdependencies across them, and the associated risks, obligations, key data, and controls.
- Scenario analysis is undertaken to identify and assess the potential impact of severe operational risk events and to test operational resilience.
- Internal controls are designed, implemented, and embedded in line with risk appetite; controls are regularly monitored, reviewed, and tested for design and operating effectiveness at a frequency commensurate with the materiality of the risks; and results are reported to senior management.
- Material weaknesses, control gaps, and failures are remediated with clear accountabilities, root-cause analysis, and timely closure, and remain on the operational risk profile until remediated.
- The impact of business and strategic decisions (including new products, services, geographies, and technologies) on the operational risk profile is assessed as part of planning processes, and information and IT capability is maintained to meet business requirements (including monitoring the age and health of information assets and meeting CPS 234).

How Auditors and Supervisors Evaluate This:

Review the operational risk profile and risk appetite statement, including indicators, limits, and tolerance levels.
Examine process and resource mapping for critical operations, including interdependencies and supporting service providers.
Inspect the control testing schedule, testing results, and reporting to senior management; sample tested controls for evidence of both design and operating effectiveness assessment.
Review remediation plans for identified weaknesses, including root cause, owner, due dates, and evidence of closure.
Check scenario analysis documentation and how outcomes fed into new or amended controls and mitigation strategies.

Key Consideration: End-to-end process mapping for critical operations is the foundation everything else builds on; entities that cannot show what their critical operations depend on cannot credibly set tolerance levels, test continuity plans, or identify material service providers. Make the mapping a living artifact, refreshed when the business changes.

3. Operational Risk Incident Management

Compliance Goal: Ensure incidents and near misses are caught, escalated, learned from, and, where material, reported to APRA on time.

The Requirement in Practice:

Not Meeting:
- Incidents are handled informally with no central record; near misses are ignored; APRA notification obligations are unknown or untested.
Meeting:
- Operational risk incidents and near misses are identified, escalated, recorded, and addressed in a timely manner.
- Incidents and near misses feed back into the assessment of the operational risk profile and control effectiveness.
- APRA is notified as soon as possible, and no later than 72 hours, after the entity becomes aware of an incident likely to have a material financial impact or a material impact on its ability to maintain critical operations.

How Auditors and Supervisors Evaluate This:

Review the incident register, including near misses, with classification, escalation paths, and closure evidence.
Sample material incidents for timeliness of escalation and APRA notification against the 72-hour requirement.
Check post-incident reviews for root-cause analysis and resulting control changes or risk profile updates.

Key Consideration: An information security incident already reported under CPS 234 does not need to be reported again under CPS 230, but your incident procedures should make clear which obligation applies and who owns the notification decision, since the clock starts when the entity becomes aware.

4. Business Continuity (Critical Operations, Tolerance Levels, and the BCP)

Compliance Goal: Be able to continue delivering critical operations within Board-approved tolerance levels through severe disruptions, with a credible and tested BCP.

The Requirement in Practice:

Not Meeting:
- A generic BCP exists but is not linked to defined critical operations or tolerance levels; testing is a desktop walkthrough at best; disaster recovery for critical information assets is not addressed.
Meeting:
- The entity defines, identifies, and maintains a register of its critical operations, including at minimum the operations APRA prescribes for its industry (for example, 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 supporting systems for all entities), unless it can justify otherwise.
- For each critical operation, the entity establishes tolerance levels for the maximum period of disruption it would tolerate, the maximum extent of data loss it would accept, and the minimum service levels it would maintain under alternative arrangements.
- The BCP includes the register of critical operations and tolerance levels, activation triggers and resourcing arrangements, the actions the entity would take to maintain critical operations within tolerance, an assessment of execution risks and key internal and external dependencies, and a communications strategy. Disaster recovery planning covers critical information assets.
- The entity maintains the capabilities (people, resources, and technology) required to execute the BCP, monitors compliance with tolerance levels, and reports any failure to meet tolerance levels, with a remediation plan, to the Board.
- APRA is notified as soon as possible, and no later than 24 hours, after a disruption to a critical operation outside tolerance, covering the nature of the disruption, action taken, likely impact, and timeframe for returning to normal operations.
- A systematic testing program covers all critical operations, includes an annual business continuity exercise, and tests the ability to meet tolerance levels against a range of severe but plausible scenarios, including disruptions to material service providers and scenarios requiring contingency arrangements. The BCP is updated at least annually, and internal audit periodically reviews the BCP and testing adequacy and provides assurance to the Board.

How Auditors and Supervisors Evaluate This:

Review the critical operations register and the rationale for any prescribed operation excluded from it.
Examine Board approval of tolerance levels and the analysis (such as business impact assessment) supporting them.
Inspect the BCP for the required content elements and its alignment to the critical operations register.
Review the testing program, scenario library, results of the most recent annual exercise (including MSP disruption scenarios), and remediation of findings.
Check tolerance monitoring, any breach notifications to APRA against the 24-hour requirement, and internal audit’s periodic review and assurance to the Board.

Key Consideration: Tolerance levels are the hinge of the whole standard: they must be specific enough to test against and realistic enough to defend. A BCP test that does not measure performance against the stated maximum outage, data loss, and minimum service levels will not satisfy an assessor, regardless of how smoothly the exercise ran.

5. Management of Service Provider Arrangements

Compliance Goal: Effectively manage the risks associated with service providers through a comprehensive policy, an accurate MSP register, compliant formal agreements, and robust ongoing monitoring.

The Requirement in Practice:

Not Meeting:
- Vendor management is procurement-driven with no materiality assessment; contracts predate CPS 230 and lack APRA access or subcontractor provisions; there is no register and no ongoing performance or control monitoring.
Meeting:
- A comprehensive service provider management policy covers how the entity identifies material service providers and manages arrangements, including its approach to entering, monitoring, substituting, and exiting agreements; managing MSP risks; and managing risks associated with fourth parties that MSPs rely on to deliver a critical operation.
- The entity identifies and maintains a register of material service providers (those it relies on for a critical operation or that expose it to material operational risk), classifies at minimum the providers APRA prescribes for its industry (for all entities: risk management, core technology services, and internal audit) unless justified otherwise, and submits the register to APRA annually.
- Before entering or materially modifying a material arrangement, the entity undertakes appropriate due diligence, including an appropriate selection process, an assessment of the provider’s ability to deliver on an ongoing basis, and an assessment of financial and non-financial risks, including geographic location and concentration risk.
- Formal legally binding agreements for all material arrangements include, at minimum: specified services and service levels; rights, responsibilities, and expectations (including data ownership and control, dispute resolution, audit access, liability, and indemnity); provisions ensuring legal and compliance obligations can be met; notification of material subcontracting and provider liability for subcontractor failures; force majeure provisions; termination rights; and provisions allowing APRA access to documentation and data, the right to conduct on-site visits, and agreement not to impede APRA.
- For each material arrangement, the entity manages risks to ongoing service delivery and risks to itself (such as step-in or contagion risk), ensures it can execute its BCP, and ensures it can conduct an orderly exit if needed.
- Monitoring includes regular assessment of performance against agreed service levels, the effectiveness of controls managing provider risks, and both parties’ compliance with the agreement, with reporting to senior management. APRA is notified within 20 business days of entering or materially changing an agreement relied on for a critical operation, and prior to entering any material offshoring arrangement (or significant changes to one). Internal audit reviews any proposed material arrangement involving outsourcing of a critical operation and reports regularly to the Board or Board Audit Committee.

How Auditors and Supervisors Evaluate This:

Review the service provider management policy, including its treatment of fourth-party risk.
Examine the MSP register, the materiality assessment methodology, justifications for excluding prescribed provider types, and evidence of annual submission to APRA.
Sample material arrangements for due diligence records and contract clause coverage against the CPS 230 minimum provisions (a contract clause gap analysis is a common artifact).
Inspect monitoring evidence: SLA reporting, control assessments, compliance reviews, and senior management reporting.
Check notification records against the 20-business-day and offshoring pre-notification requirements, and internal audit reviews of outsourced critical operations.

Key Consideration: Legacy contracts are the most common gap: pre-existing arrangements must comply by the earlier of the next renewal or 1 July 2026. Prioritize uplift for providers supporting critical operations, and remember the entity, not the provider, decides materiality; “the vendor doesn’t consider itself material” is not a defensible justification.

Demonstrating Compliance and Readiness

CPS 230 does not require a single mandated artifact (such as ISO 27001’s Statement of Applicability), but supervisors and auditors will expect a coherent, connected set of artifacts: the operational risk profile, the critical operations register with tolerance levels, the BCP and testing results, the MSP register, formal agreements, and monitoring and Board reporting. A GRC platform is the ideal place to map your evidence (policies, registers, test reports, contracts, and monitoring outputs) directly to each CPS 230 requirement, and to reuse controls already evidenced for frameworks such as SOC 2, ISO 27001, and CPS 234.

What about proportionality and justifications? Where CPS 230 allows an entity to depart from a default (for example, not classifying a prescribed business operation as critical, or a prescribed provider type as material), the entity must be able to justify that decision. Document the justification at the time the decision is made; an undocumented exclusion will generally be treated as a gap.

Common Pitfalls That Cause Findings

Disconnected artifacts: a BCP, risk register, and vendor list that don’t reference the same critical operations and tolerance levels.
Untested tolerance levels: annual exercises that don’t measure recovery against the stated maximum outage, data loss, and minimum service levels.
Missing MSP scenarios: BCP testing that never simulates the failure of a material service provider.
Incomplete MSP registers: prescribed provider categories excluded without documented justification, or registers not submitted to APRA annually.
Contract gaps: agreements missing APRA access rights, subcontractor notification and liability, force majeure, or termination provisions.
Notification process failures: no rehearsed process for the 72-hour incident, 24-hour tolerance breach, and 20-business-day arrangement notifications.
Stale risk profiles: operational risk assessments not updated for new products, technologies, incidents, or near misses.
Fourth parties ignored: no visibility of the subcontractors your MSPs rely on to deliver your critical operations.

Conclusion

CPS 230 compliance is achieved when the five requirement areas operate as one system: governance sets the appetite and approves the thresholds, risk management maps and controls what critical operations depend on, incident management feeds learning back in, business continuity proves the entity can stay within tolerance, and service provider management extends all of it across the supply chain. By aligning your controls to each requirement and documenting clear evidence, your organization can demonstrate both real-world resilience and audit readiness.