APRA CPS 230 compliance: where operational risk programs fail under supervision
Julian ThorneApril 29, 2026
Key takeaways
CPS 230 requires APRA-regulated entities to define tolerance levels for operational disruption — specific, measurable thresholds for how much disruption the institution can absorb before the impact becomes unacceptable. Most institutions have risk appetite statements but no tolerance levels that could be tested against a real scenario.
CPS 230 incident notification to APRA is required within 24 hours for incidents that have a material impact on operational capability or could affect financial soundness. The threshold is materiality, not severity — and most incident response plans do not include a documented materiality assessment step.
Service provider obligations under CPS 230 extend beyond direct suppliers to material arrangements — any relationship where disruption would affect the institution's ability to meet its obligations. Concentration risk across a small number of cloud providers is a specific supervisory concern APRA has signaled.
Business continuity plans under CPS 230 must be tested against scenarios realistic enough to reveal recovery capability gaps. Tabletop exercises that confirm the plan exists do not satisfy the testing obligation. APRA examiners request evidence of findings from tests, not just evidence that tests occurred.
In Vulnox assessments of APRA-regulated entities preparing for CPS 230, the most consistent gap was tolerance level documentation: institutions had defined risk appetite but had never translated that into quantified disruption thresholds their continuity plans were designed to meet.
CPS 230 and CPS 234 have overlapping but non-identical scope. A cyber incident that disrupts operations triggers both frameworks simultaneously, and most institutions' incident response protocols route these through either the IT function or the operational risk function — not both in parallel.
TL;DR
CPS 230 is not a more detailed version of what APRA-regulated entities were already doing. It introduces specific requirements — tolerance levels, tested continuity plans, material service provider registers — that require new documentation and new processes, not just mapping of existing ones. Institutions that treated the July 2025 deadline as a documentation project are likely to find supervision reveals gaps their compliance program did not.
The business continuity test that confirmed nothing
A regional bank completed its first CPS 230 business continuity exercise six weeks before the July 2025 enforcement date. The scenario covered a core banking system outage lasting 48 hours. The exercise was well-run: roles were assigned, escalation paths were followed, and the recovery sequence was executed in the correct order. The after-action report noted no significant issues. When APRA examiners reviewed the exercise documentation, they asked one question: what was the institution's defined tolerance level for core banking unavailability, and did the 48-hour scenario test the boundary of that tolerance? The bank did not have a documented tolerance level for core banking availability. The exercise had confirmed that the recovery process could be followed. It had not tested whether the institution could actually absorb the disruption it was designed to simulate.
CPS 230 requires institutions to define how much operational disruption they can tolerate before impact becomes unacceptable, then test whether their continuity capabilities meet that threshold. An exercise that does not reference a tolerance level is not a CPS 230 continuity test. It is a rehearsal.
How CPS 230 tolerance levels work — and why risk appetite statements do not substitute for them
CPS 230 requires institutions to set tolerance levels for disruption to critical operations. Tolerance levels are specific and measurable: the maximum duration of outage for a given critical operation before the impact is unacceptable, or the maximum volume of transactions that can be affected before regulatory or customer harm thresholds are crossed. Risk appetite statements express the institution's general posture toward risk — they are qualitative and directional. Tolerance levels are operational parameters against which recovery capability can be objectively assessed. The two are related but not interchangeable, and CPS 230 requires both.
Example
A superannuation fund that defines its risk appetite as 'low tolerance for operational disruption affecting member services' has a risk appetite statement. A fund that specifies that member account access must be restored within 4 hours of any system outage affecting more than 10,000 accounts has a tolerance level. The first cannot be tested. The second determines what the business continuity plan must achieve and provides the basis for evaluating whether a continuity test was passed or failed. APRA examiners will ask for tolerance levels in the second format. They cannot assess compliance against the first.
CPS 230 Paragraph 25 requires that tolerance levels be approved by the Board and reviewed at least annually or following any material change to critical operations. This means tolerance levels must be a Board-level governance document, not a risk management team working paper. The Board approval requirement links tolerance level documentation directly to the board accountability evidence trail that APRA examiners will review.
What CPS 230 readiness assessments found in regulated environments
Assessment base: Vulnox CPS 230 readiness and gap analysis assessments, APRA-regulated entities in banking, superannuation, and insurance, 2024-2025.
Risk appetite statements presented as tolerance levels
In Vulnox CPS 230 readiness assessments, the near-universal finding was that institutions had risk appetite frameworks that used tolerance language without defining measurable thresholds. Documents described the institution's tolerance for operational disruption as 'low' or 'minimal' with no translation into recovery time objectives, maximum transaction volumes affected, or maximum data loss windows. When assessed against CPS 230's requirement for specific, testable tolerance levels, none of these documents satisfied the standard. The gap was not a failure to think about tolerance — it was a failure to document it in a form that can be operationalized.
A business continuity plan built around an untestable tolerance statement cannot be validated. The plan may produce a functioning recovery process but cannot demonstrate that the recovery process meets the institution's own stated acceptable outcomes. APRA examiners will assess both the tolerance definition and the evidence that continuity testing measured against it.
Material service provider registers that exclude cloud infrastructure
CPS 230 requires institutions to maintain a register of material service providers — arrangements where disruption would affect the institution's ability to meet its obligations to depositors, policyholders, or beneficiaries. In assessed environments, service provider registers consistently captured traditional outsourced functions: payroll, data processing, facilities management. Cloud infrastructure providers — AWS, Azure, and similar — were routinely absent, classified as commodity technology rather than material service arrangements. For institutions running core banking, payment processing, or member data management on cloud infrastructure, this classification is not defensible. Disruption to that infrastructure is disruption to the institution's core obligations.
APRA has publicly identified concentration risk in cloud infrastructure as a supervisory concern for the Australian financial services sector. An institution whose material service provider register does not include its cloud infrastructure provider is both non-compliant with CPS 230 and blind to a concentration risk that APRA is actively scrutinizing.
Incident notification thresholds that require a severity judgment rather than a materiality test
CPS 230 requires notification to APRA within 24 hours of becoming aware of an operational incident that has a material impact or could affect financial soundness. The operative standard is materiality — a defined threshold based on impact criteria — not severity, which is an internal prioritization category. In assessed environments, incident response plans mapped notification decisions to internal severity classifications: P1 incidents triggered notification consideration; P2 and below did not. The problem is that a P2 incident affecting a critical operation that is approaching its tolerance threshold can be material under CPS 230 without meeting the internal P1 criteria. Severity and materiality are not the same measurement.
Institutions whose notification decisions are driven by severity labels rather than materiality assessments will systematically under-report incidents to APRA. When examiners review the incident log and find P2 incidents that affected critical operations without notification, the question is not whether the classification was internally consistent — it is whether the institution applied the correct regulatory test.
CPS 230 and CPS 234 running as parallel programs with no integration at the incident level
A cyber incident that disrupts operational capability triggers both CPS 234 information security obligations and CPS 230 operational risk obligations simultaneously. CPS 234 requires notification to APRA within 72 hours of a material information security incident. CPS 230 requires notification within 24 hours of a material operational incident. If the same event qualifies under both — which a ransomware attack or significant data exfiltration event almost certainly would — the applicable notification window is the shorter of the two: 24 hours. In assessed environments, incident response protocols routed cyber events through the IT security function under CPS 234 procedures. CPS 230 notification triggers were not evaluated unless the operational impact escalated to a separate incident management process. The integration between the two frameworks at the incident level did not exist.
An institution that notifies APRA at 68 hours under CPS 234 for a cyber-operational incident has missed the CPS 230 24-hour window by 44 hours. The two notifications are legally distinct obligations. One being filed on time does not satisfy the other.
Institutions with mature CPS 234 programs are not better positioned for CPS 230 — they are differently exposed
Common belief
The assumption driving most CPS 230 implementation programs at institutions with existing CPS 234 compliance is that operational risk management is an extension of information security governance. The reasoning: CPS 234 already requires asset classification, third-party risk management, incident response, and board oversight. CPS 230 covers similar territory from an operational risk angle. A mature CPS 234 program provides the foundation; CPS 230 gap analysis identifies the delta.
What we found
In assessed environments, CPS 234 maturity correlated with strong information security control documentation and weak operational continuity evidence — exactly the pattern you would expect if the CPS 234 program had been extended to cover CPS 230 scope rather than a parallel program being built for CPS 230's distinct requirements.
The assumption is wrong in a specific and consequential way. CPS 234 is a security framework — its scope is information security incidents and controls. CPS 230 is an operational resilience framework — its scope is the institution's ability to continue meeting its obligations under disruption. The difference in scope means the evidence standards differ, the board oversight documentation differs, and the third-party risk assessment methodology differs. CPS 234 asks whether the institution's information assets are protected. CPS 230 asks whether the institution can keep operating when they are not. These are related but distinct questions, and the compliance program that answers the first well is not automatically equipped to answer the second. The institution with the most mature CPS 234 program assessed in Vulnox engagements during 2024 had zero documented tolerance levels and a service provider register that excluded three of its four cloud infrastructure providers.
CPS 230 obligations that most compliance programs have not addressed
Sub-outsourcing and fourth-party operational risk
CPS 230 requires institutions to understand and manage risks introduced by arrangements their service providers have with their own suppliers — what the standard terms sub-outsourcing. For institutions whose material service providers use cloud infrastructure, payment networks, or data processing services from a concentrated set of fourth-party providers, this obligation requires visibility two layers down the supply chain. Most service provider management frameworks assess direct arrangements and stop there. CPS 230 does not.
Change management as an operational risk trigger
CPS 230 requires institutions to assess operational risk implications before implementing material changes to critical operations, technology, or service provider arrangements. This is a pre-implementation obligation, not a post-implementation review. Institutions with mature change management processes often have robust post-implementation review disciplines. The pre-implementation operational risk assessment — specifically evaluated against CPS 230 tolerance levels and critical operation dependencies — is a new step that most change management workflows do not include.
Annual review of the critical operations list itself
CPS 230 requires institutions to maintain a list of critical operations and review it at least annually. The review must assess whether the list remains complete given changes in business activities, technology, and service arrangements. In assessed environments, critical operations lists were produced as part of the initial CPS 230 implementation and had not been reviewed since. Business units that had onboarded new services, changed technology platforms, or expanded product offerings since the list was compiled were operating outside the formal critical operations framework without anyone having made a conscious decision to exclude them.
Where APRA's CPS 230 supervision focus is heading
APRA will issue a supervisory letter within 18 months identifying cloud infrastructure concentration as a systemic operational risk across the Australian financial services sector, and requiring institutions to demonstrate how their CPS 230 service provider frameworks address this exposure.
APRA has publicly identified cloud concentration risk as a concern in multiple publications since 2022. The pattern of supervisory escalation APRA follows — public guidance, targeted letters, enforcement action — suggests the next step is institution-level requirements to demonstrate how the concern has been addressed. The July 2025 CPS 230 enforcement date creates the compliance baseline against which APRA can now assess whether institutions have treated cloud infrastructure as a material service arrangement. Supervision will find that most have not.
Confidence: highAPRA supervisory letter or thematic review publication on cloud concentration risk before end of 2026, or absence of such communication.Within two years, APRA will identify a CPS 230 enforcement action against a mid-tier institution specifically citing the failure to define measurable tolerance levels, establishing that qualitative risk appetite statements do not satisfy the CPS 230 tolerance documentation requirement.
The tolerance level gap is near-universal across assessed APRA-regulated entities. It is specific enough to be cited in an enforcement action, it is structurally connected to the board accountability obligations that APRA takes most seriously, and it is distinct from the CPS 234 obligations that institutions have already been supervised against. Enforcement actions that establish new precedent tend to target gaps that are widespread, specific, and clearly traceable to documented regulatory requirements. The tolerance level failure meets all three criteria.
Confidence: mediumPublic APRA enforcement action citing CPS 230 tolerance level documentation failure before mid-2027.
CPS 230 will produce more enforcement exposure than CPS 234 did — for a different reason
CPS 234 enforcement was concentrated on information security control gaps: missing controls, inadequate testing, third-party risk programs that existed on paper. These are technical failures that are identifiable and remediable through a standard gap analysis process. CPS 230 enforcement will concentrate on governance documentation failures — tolerance levels that were never defined, board approval records that do not exist, continuity tests that measured the wrong things. These are harder to remediate because they require changing how boards engage with risk, not just what the risk team documents. The institutions that treated CPS 230 as a documentation project will find that the supervision cycle reveals gaps that documentation cannot retroactively close.
Counterargument
The counterargument is that APRA has consistently been pragmatic about implementation timelines for new standards — that supervisory action concentrates on institutions with genuinely weak risk management rather than those with documentation gaps in otherwise sound programs. That is a reasonable read of APRA's enforcement history through 2024. The July 2025 enforcement date and APRA's public statements about CPS 230 being a substantive uplift, not an administrative update, suggest the pragmatism will be applied more narrowly this cycle.
One thing to do this week
Pull your institution's critical operations list and your business continuity plan for one critical operation. Find the tolerance level that the continuity plan is designed to meet — the specific, measurable threshold for maximum acceptable disruption duration or impact. If it is not in the document, or if the closest thing you can find is a qualitative risk appetite statement, you have identified the highest-priority CPS 230 gap in your program. Defining that tolerance level, getting it to the Board for approval, and updating the continuity plan to reference it as the target is a concrete, bounded piece of work that directly addresses the gap APRA examiners will look for first.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysis toolsNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideThird-Party Risk Management
third-party risk managementWhat is a Digital Footprint - IBM
understanding digital footprint
Frequently Asked Questions
What is the difference between a risk appetite statement and a tolerance level under APRA CPS 230?
Risk appetite statements describe an institution's general posture toward operational risk — qualitative and directional. CPS 230 tolerance levels are specific, measurable thresholds: the maximum duration of disruption to a critical operation before impact is unacceptable, or the maximum transaction volume affected before regulatory harm thresholds are crossed. APRA examiners assess compliance against tolerance levels, not appetite statements. A continuity plan that references appetite language rather than defined thresholds cannot be objectively validated.
What is the CPS 230 incident notification timeline and how does it interact with CPS 234?
CPS 230 requires APRA notification within 24 hours of an operational incident with material impact or potential to affect financial soundness. CPS 234 requires notification within 72 hours of a material information security incident. A cyber event that disrupts operations triggers both obligations simultaneously. The applicable notification window is the shorter one: 24 hours. Incident response protocols that route cyber events through CPS 234 procedures without simultaneously evaluating CPS 230 materiality will miss this window for qualifying incidents.
Does cloud infrastructure count as a material service provider under CPS 230?
For any institution running core banking, payment processing, or member data management on cloud infrastructure, yes. A material service arrangement under CPS 230 is one where disruption would affect the institution's ability to meet obligations to depositors, policyholders, or beneficiaries. Disruption to cloud infrastructure supporting critical operations clearly meets that definition. APRA has publicly identified cloud concentration risk as a supervisory concern. Service provider registers that exclude cloud infrastructure providers are both non-compliant and blind to a risk APRA is actively scrutinizing.
How does CPS 230 handle sub-outsourcing and fourth-party risk?
CPS 230 requires institutions to understand and manage risks from arrangements their service providers have with their own suppliers — sub-outsourcing. For institutions whose material service providers use a concentrated set of fourth-party providers for cloud infrastructure or payment processing, this obligation requires visibility two layers down the supply chain. Most service provider frameworks assess direct arrangements only. CPS 230 does not limit the obligation to direct relationships.
What does APRA look for when reviewing business continuity tests under CPS 230?
APRA examiners request evidence that continuity tests measured recovery capability against the institution's defined tolerance levels — not just evidence that tests occurred. An exercise that confirms the recovery process can be followed without establishing whether the recovery outcome meets the institution's tolerance threshold does not satisfy the CPS 230 testing obligation. Examiners review test findings, not test completion records. Exercises that produce no findings are a signal that the scenario was not challenging enough to reveal capability gaps.
What is the relationship between CPS 230 and CPS 234 compliance programs?
CPS 230 and CPS 234 have overlapping but non-identical scope. CPS 234 governs information security capability. CPS 230 governs operational resilience — the ability to continue meeting obligations under disruption. A mature CPS 234 program provides strong information security control documentation but does not address CPS 230's tolerance level requirements, operational continuity testing obligations, or the broader service provider register scope. A cyber incident that disrupts operations triggers both frameworks simultaneously with different notification timelines.
What gaps does a CPS 230 gap analysis typically find in APRA-regulated entities?
In Vulnox CPS 230 readiness assessments, the consistent findings were: risk appetite statements presented in place of measurable tolerance levels; service provider registers that excluded cloud infrastructure; incident notification protocols that routed cyber events through CPS 234 procedures without evaluating CPS 230 materiality in parallel; continuity tests that confirmed process execution without testing against tolerance thresholds; and critical operations lists that had not been reviewed since initial compilation despite subsequent changes to technology and service arrangements.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.