CPS 230 is not a compliance project

APRA's Prudential Standard CPS 230 has been in force since July 2025, and for many regulated entities the transition period for pre-existing contractual arrangements runs out in mid-2026. Most programs we see are on schedule against their plan. Fewer are on schedule against the standard's actual question — which is not "is your register complete?" but "do your critical operations keep running when something breaks?" That distinction sounds rhetorical. It is not. CPS 230 is written as an outcome standard: identify your critical operations, set tolerance levels for disruption, and be able to demonstrate — to your board first and your supervisor second — that you can stay within them. A program can produce every artefact the standard names, on time, and still leave the organisation unable to answer the outcome question. We call that the compliance-shaped version of resilience: it photographs well and fails under load. The compliance-shaped version has a recognisable anatomy. The critical operations list is assembled by workshop rather than derived from how value actually flows through systems. Tolerance levels are set at whatever the current architecture can plausibly meet, rather than what the business can actually absorb — which quietly inverts the standard's intent. Third-party dependencies are catalogued at the contract layer, while the platform layer — where a single shared integration or an unowned legacy service can take down three "independent" critical operations at once — stays invisible. And business continuity is tested by walkthrough, in business hours, with the people who wrote the plan in the room. The engineering-shaped version starts somewhere else: with the map. Which systems, integrations, data flows, and providers actually sit under each critical operation? Not the architecture diagram from the last program — the current, honest map, including the parts nobody owns. In our experience this mapping exercise is where CPS 230 earns its money, because it surfaces the concentration risk the org chart hides. When two critical operations quietly share one ageing integration platform, that platform is a critical operation, whatever the register says. With the map in hand, tolerance levels become engineering requirements rather than aspirations. A two-hour tolerance on payments is a statement about failover design, data replication, and the automation of recovery — or it is fiction. This is the test we encourage boards to apply to any tolerance level they are asked to endorse: ask what, specifically, in the architecture makes this number true. If the answer is a plan to write a plan, the number is not yet real. Third-party risk follows the same logic. CPS 230's material service provider requirements are commonly read as a contracting exercise — refresh the agreements, insert the audit and step-in clauses, build the register. Necessary, and insufficient. The operational question is what your architecture does in the hours after a material provider fails. Can you degrade gracefully? Is there a substitution path, and has anyone exercised it? Contractual remedies operate on legal time; your tolerance levels operate on operational time. The gap between the two is an engineering problem, and it is yours, not the provider's. Then there is testing. The standard requires a testing program for business continuity, and the difference between testing that satisfies and testing that strengthens is severity. Scenario walkthroughs have their place, but resilience is demonstrated by exercising the failure paths for real: pulling the dependency in a controlled window, running the failover, timing the recovery, and feeding what broke back into the backlog. Organisations that do this discover their real recovery times are usually multiples of their documented ones — which is precisely the information a board needs before it attests, not after an incident makes it public. None of this argues against the program disciplines — the registers, the policies, the board reporting. They are the floor, and the floor matters. But compliance is a floor. Resilience is the outcome. The organisations that will be comfortable in front of APRA in 2027 are the ones treating CPS 230 as a forcing function to engineer resilience into their platforms — designed in, not bolted on — and using the compliance artefacts to describe something that is actually true. A practical place to start: take your single most critical operation and trace it end to end — systems, integrations, data, providers, people. Set its tolerance level against what the business can genuinely absorb, then have engineers, not report writers, assess whether the architecture makes that number true. The gap you find is your real CPS 230 program.