CPS 230 Critical Operations and Tolerance Levels: Building the Evidence

CPS 230 does not ask you to write a resilience policy. It asks you to prove, with numbers, that you can keep your critical operations running inside limits you have set for yourself. That is a measurement problem, and most firms are treating it as a drafting one.

APRA’s Prudential Standard CPS 230 has been in force since 1 July 2025. I have written before about why it is a proof standard wearing a policy standard’s clothes; this post is the practical follow-on. The standard turns on three linked requirements: identify your critical operations, set tolerance levels for each, and be able to show you can operate within them. The first two produce documents. The third produces evidence, or it does not, and that is where supervisory attention lands. A board pack that asserts resilience without a measurement behind it is exactly the position CPS 230 was written to close.

Identifying critical operations is a scoping decision, not a list

CPS 230 defines a critical operation as a process that, if disrupted beyond tolerance, would have a material adverse impact on depositors, policyholders, beneficiaries or other customers, or on the entity’s role in the financial system. APRA does not leave the whole judgement to you. For an ADI it expects, at a minimum, that payments, deposit-taking and management, custody, and settlements and clearing are treated as critical. For insurers it names claims processing; for RSE licensees, investment management and fund administration. Every entity is expected to include customer enquiries and the systems and infrastructure that enable these operations.

The trap is treating that minimum list as the answer. The scoping decision that matters is the boundary: what counts as one operation, and where it ends. “Payments” is not a critical operation you can measure. “Inbound domestic payment processing via the New Payments Platform” is. Draw the boundaries too wide and your tolerance levels become meaningless averages. Draw them too narrow and you drown in a register nobody maintains. The right granularity is the level at which a disruption has a distinct customer impact and a distinct set of supporting resources. That is the unit you will measure against for the life of the standard, so it is worth arguing about before anything else.

Tolerance levels that mean something

For each critical operation, CPS 230 requires the board to set tolerance levels across three dimensions: the maximum period of disruption the entity would tolerate, the maximum extent of data loss it would accept, and the minimum service level it would maintain while operating under alternative arrangements. These are the operational-resilience cousins of the recovery time and recovery point objectives your technology team already talks about, but they are set by the board and framed around customer impact rather than system restoration.

A tolerance level means something only if two things are true. First, it is falsifiable: you can state, after any given day, whether you stayed inside it or not. “Minimal disruption” is not a tolerance level. “No more than four hours of full outage in a rolling twelve months, no more than fifteen minutes of committed transaction data lost, at least 60 per cent of normal throughput sustained on the contingency path” is one. Second, it is honest about what you can actually deliver. Setting a two-hour tolerance when your failover takes six is not ambition, it is a self-reported breach waiting to be found. The UK’s operational resilience regime has already made this concrete for firms there — the point that impact tolerances now have teeth applies with equal force under CPS 230. A tolerance you cannot evidence staying within is worse than no tolerance at all, because you have documented the standard you are failing.

Mapping resources and dependencies is the load-bearing work

CPS 230 requires you to identify and document the resources needed to deliver each critical operation — people, technology, information, facilities and service providers — together with the interdependencies between them and the associated risks. This is the part that takes real effort, because a tolerance level is only credible if you know everything that has to work for you to hold it.

In practice this means a mapping from each critical operation down to the concrete things it depends on, and from those things to their own dependencies, until you hit an external provider or a resource you consider a root. A single deposit operation may depend on a core banking platform, an identity provider, a payments gateway, a data centre or cloud region, and a named team. Each of those has its own availability characteristics. The tolerance for the operation cannot be tighter than the weakest link in its dependency chain will support, and until the map exists you do not know what that link is. Where the chain runs into a material service provider, note that CPS 230’s transition allowed existing arrangements to be brought into line by the earlier of their next renewal or 1 July 2026 — the mapping obligation itself did not wait.

The mapping is also the artefact that makes the measurement possible. Once every critical operation is tied to named resources with stated thresholds, a breach becomes something a system can flag rather than something a committee discovers after the fact. Here is a compact way to hold that structure as configuration.

# critical-operations.yaml
# Maps each critical operation to its resources and tolerance thresholds.
# A monitoring job evaluates measured values against these and raises breach flags.

critical_operations:
  - id: CO-01
    name: Inbound domestic payment processing
    business_impact: Customers cannot receive funds; systemic settlement role
    tolerance:
      max_disruption_minutes: 240        # maximum tolerable full outage, rolling 12m
      max_data_loss_minutes: 15          # maximum committed data that may be lost
      min_service_level_pct: 60          # minimum throughput on contingency path
    resources:                           # each must be available to hold tolerance
      - id: RES-CORE     type: technology   provider: internal    criticality: high
      - id: RES-NPP-GW   type: technology   provider: material_sp criticality: high
      - id: RES-IDV      type: technology   provider: material_sp criticality: high
      - id: RES-DC-SYD   type: facility     provider: material_sp criticality: high
      - id: RES-OPS-TEAM type: people       provider: internal    criticality: med
    notify_apra:
      incident_hours: 72                 # material operational risk incident
      outside_tolerance_hours: 24        # disruption to a critical operation

# Pseudocode for the evaluation the monitoring job runs each interval.
# measured = live telemetry for the operation over the tolerance window.
#
#   breach = (measured.disruption_minutes  > tol.max_disruption_minutes)
#         or (measured.data_loss_minutes   > tol.max_data_loss_minutes)
#         or (measured.service_level_pct   < tol.min_service_level_pct)
#
#   if breach: raise flag, start the 24-hour APRA notification clock,
#              and record the evidence trail (what breached, by how much, when).

The configuration is not the compliance. It is the scaffold that forces the three artefacts — operations, tolerances, dependencies — to line up in one place, so that measurement has something to measure against and a breach has a defined consequence. Keep it in version control and the register maintains an audit trail for free.

The evidence APRA will actually ask for

When a supervisor tests CPS 230, the questions are concrete. Show us your register of critical operations and how you set the boundaries. Show us the tolerance levels the board approved and the basis for them. Show us the dependency map, and show us the point in it where the tolerance is most exposed. Show us the measurement — not an assertion that you operate within tolerance, but the telemetry and the record of when you have and have not. Show us that you notified, or would have notified, within 72 hours of a material operational risk incident and within 24 hours of a disruption to a critical operation outside tolerance.

An entity that can produce all of that tells a coherent story: this is what matters, this is the limit we set, this is everything it depends on, and here is the proof we stayed inside it — or the record of when we did not and what we did about it. An entity with the policies but no measurement has stated compliance without evidence of operation, and CPS 230 was written precisely to make that gap visible.

The standard rewards the firms that treated it as an engineering exercise and exposes the ones that treated it as a writing exercise. The register, the thresholds and the map are the easy part. Being able to prove, on any given day, that you stayed inside your own limits is the standard.