What does CPS 230 require you to document about your critical operations?

What the standard actually asks for

Prudential Standard CPS 230 Operational Risk Management has been in force since 1 July 2025, with a further year allowed for entities to review contracts with existing material service providers. Its aim, in APRA's words, is that a regulated entity is resilient to operational risks and disruptions, maintains its critical operations through disruption, and manages the risks arising from service providers.

The requirement that turns this into a documentation exercise is the one about processes and resources. According to APRA, an entity must identify and document 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.

Read that list slowly, because each item is a different kind of thing and most organisations hold them in different places, maintained by different teams, at different levels of currency. This page is a plain summary for the people who will do the work. It is not prudential or legal advice, and the authority is APRA and the standard itself.

Why it is a mapping problem, not a register problem

The instinctive response is to build a register: a spreadsheet with a row per critical operation and columns for the systems, the vendors and the owner. Registers are quick to produce and they satisfy an auditor asking whether the artefact exists.

They do not satisfy the requirement, because the requirement is about interdependencies. A register lists what a critical operation touches. A map shows how, in what order, and what happens to the operation when one of those things is unavailable. The second question is the one that matters during a disruption, and it is the one a table of rows cannot answer.

The practical test: pick a critical operation, remove one service provider from it, and ask what stops. If the answer requires convening a meeting, the documentation is a register rather than a map.

Scoping is the decision that costs the most

Critical operations are the processes whose disruption would have a material impact, and deciding which those are sets the size of everything that follows. Scope too widely and the mapping becomes a programme that never finishes and is stale in the parts that finished first. Scope too narrowly and the gap is visible the first time something outside the scope causes a disruption.

The failure mode worth naming is scoping to the operations that are easy to map. Processes that run inside one well-instrumented system are the least likely to be where the risk sits, precisely because they are visible. The processes held together by a shared mailbox, a spreadsheet and two long-serving people are harder to document and are usually the ones with the concentration risk.

The interdependencies are where the work actually is

Identifying the processes takes a while. Identifying what they depend on takes longer, because dependency is transitive and nobody holds the whole chain.

• People. Not headcount, but which specific knowledge the operation cannot run without, and whether more than one person holds it. This is the dependency organisations are most reluctant to write down and most exposed to.
• Technology. The systems in the path, including the integration nobody owns and the report that is generated by a scheduled job someone set up years ago.
• Information. What data has to be available and correct, and where it comes from. An operation can be fully staffed and fully online and still stopped by a stale reference file.
• Facilities. Where the work physically happens, which matters again in a way it did not for a while.
• Service providers. The named material ones, and the fourth parties behind them, which is the layer where mapping usually stops and where concentration risk usually hides.
• The links between all of the above, which is the item that turns five lists into a map, and the reason the exercise cannot be delegated to five separate teams working in parallel.

Why event logs will not produce this

It is reasonable to hope that process mining will produce the map from system data, and for some operations it contributes usefully. It will not produce what the standard asks for.

An event log records what a system did. It has nothing to say about which person holds the knowledge, which facility the work happens in, which contractual obligation attaches to a step, or which control is meant to be operating there. Those are not events; they are facts about the work that live in contracts, policies, org structures and people's heads.

It also cannot see the parts of a critical operation that happen outside the instrumented systems, which in most regulated entities is where the manual controls and the workarounds are. A map assembled only from logs is confident about the visible middle of an operation and silent about both ends.

The harder half: keeping it true

A map produced for a deadline is accurate on the day it is signed and decays from the next one. Systems get replaced, providers get switched, a team reorganises, a control moves. None of those events updates a document.

That is the difference between documentation that satisfies a submission and documentation that helps during an incident, and it is worth deciding which one you are building before you start. The second kind needs the map to be attached to something that is already maintained, so that changing the thing changes the map.

The most reliable version of this is to generate the map from the material the organisation keeps anyway, its procedures, its contracts, its wiki, its change records, rather than drawing it separately and then trying to remember to update it. Anything maintained by discipline alone eventually is not.

Where Valstra fits

Omni builds one model that holds processes, the people and systems they depend on, and the documents that govern them, generated from the material the organisation already has rather than drawn by hand. Controls and their evidence sit in the same model as the work they govern, which is the shape CPS 230 asks for: the process, its resources, its interdependencies, and the controls, in one place rather than in five.

The obligation can be met without any of that, with interviews, a drawing tool and enough people. Whether that is the right choice depends on how many critical operations you have and how long the map has to stay true.