CPS 230 Tolerance Breach: Designing Detection and Board Escalation

A tolerance level you cannot measure in near real time is not a control. It is a sentence in a board pack. CPS 230 turns it into an instrumentation and escalation problem, and most firms have solved neither.

APRA’s Prudential Standard CPS 230 has been in force since 1 July 2025. Much of the attention around the 1 July 2026 date is on material service providers and the register, but the obligation that bites hardest operationally is quieter: once you have set tolerance levels for a critical operation, you have to know when you have breached one, and you have to tell APRA within a defined window. That is not a policy exercise. It is a monitoring and escalation design problem, and it is the part firms most often leave as a promissory note.

The clock is already running

CPS 230 requires an entity to notify APRA as soon as possible, and in any event no later than 24 hours, after a disruption to a critical operation that has gone outside its approved tolerance. There is a separate 72-hour window for operational risk incidents likely to have a material financial impact or a material impact on the entity’s ability to maintain critical operations. The two are different clocks, and the 24-hour one is the tighter test of whether your instrumentation works.

The implication is unforgiving. If you discover a tolerance breach three days after it happened, from a customer complaint or a reconciliation, you have already failed the notification obligation regardless of how well the underlying service recovered. Late discovery is itself the governance failure. So the design question is not “do we have a tolerance?” but “how, mechanically, do we know we are inside it right now, and how fast does that knowledge travel?”

Instrument the operation, not the infrastructure

A critical operation under CPS 230 is a business process delivered end to end — processing payments, settling trades, paying claims, maintaining member records — not a server or a queue. This is where most monitoring estates fall short. They are rich in infrastructure telemetry (CPU, disk, node health) and poor in business-outcome telemetry. Infrastructure being green tells you nothing about whether payments are actually settling within tolerance. The two can diverge completely: every node healthy, and settlement throughput on the floor because an upstream counterparty is timing out.

The instrumentation has to sit at the level of the operation. For each critical operation you need a metric — or a small set of them — that expresses the thing the tolerance is written against: transactions completing successfully, the latency of completion, the freshness of the data, the proportion of expected volume actually processed. If you have done the upstream work of defining critical operations and their tolerances properly, this is where it pays off; if you have not, this is where the gaps become visible. We have written separately on building the evidence for critical operations and tolerance levels, and detection is the layer that sits directly on top of it.

Map metrics to the three tolerance dimensions

CPS 230 frames tolerance for each critical operation across three dimensions: the maximum period of time the entity can tolerate a disruption, the maximum extent of data loss it can tolerate, and the minimum service levels it can tolerate during a disruption. A detection design has to bind a measurable signal to each of the three, because a breach of any one is a breach.

• Maximum period of disruption maps to a duration condition — a service-level signal that has stayed below its floor continuously for longer than the approved window. This is the “for” clause in an alerting rule, and it is what stops a two-minute blip from paging the board.
• Minimum service level maps to a rate or ratio — successful completions over attempts, or throughput against expected volume — evaluated against the approved threshold.
• Maximum data loss maps to a recovery-point signal — replication lag, backup age, or the gap between the last durable write and now — which is the hardest of the three to observe live and the one most often left unmeasured.

Note that these are board-approved numbers. The board approves the tolerance levels and the business continuity plan; the thresholds in your monitoring configuration therefore have to be the same numbers, traceable to the same approval. A detection rule that fires at a threshold the board never saw is not evidence of anything.

The detection rule and the escalation payload

What follows is a worked pattern: a threshold rule that fires on a minimum-service-level breach sustained past the disruption window, and the structured event it should emit. The event is the thing that drives the escalation pipeline and starts the notification clock, so it carries the fields a supervisor and a board will later ask about.

# Alerting rule for one critical operation: payment settlement
# Board-approved tolerance: min service level 99.5%, max disruption 2h
groups:
  - name: cps230_critical_operations
    rules:
      - alert: PaymentSettlementOutsideTolerance
        # Successful-settlement ratio below the minimum service level,
        # sustained past the maximum tolerable period of disruption.
        expr: |
          (
            sum(rate(settlement_success_total[5m]))
            /
            sum(rate(settlement_attempt_total[5m]))
          ) < 0.995
        for: 120m   # maximum tolerable period of disruption
        labels:
          severity: tolerance_breach
          critical_operation: payment_settlement
          tolerance_dimension: service_level
        annotations:
          summary: "Settlement below 99.5% floor beyond the 2h window"

---
# Escalation event emitted on fire. Starts the 24h APRA clock.
{
  "event_type": "cps230.tolerance_breach",
  "detected_at": "2026-09-08T03:14:00Z",
  "critical_operation": "payment_settlement",
  "tolerance_dimension": "service_level",
  "breached_threshold": "min_service_level_99.5pct",
  "observed_value": "97.1pct",
  "disruption_started_at": "2026-09-08T01:05:00Z",
  "apra_notification_due_by": "2026-09-09T03:14:00Z",
  "escalation_tier": "executive_and_board",
  "accountable_owner": "head_of_payments",
  "linked_incident": "INC-20260908-0042"
}

The mechanics are ordinary; the discipline is not. The threshold is the board’s number. The for clause is the board’s window. The emitted event names an accountable owner and computes the notification deadline at detection time, so nobody has to work out the clock in the middle of an incident. This is the same instinct that separates real detection from theatre in security tooling, a distinction we have drawn in what a board should ask about detection: an alert that no one is required to act on within a defined time is not a control.

Codify the escalation, do not improvise it

Detection without a defined pipeline just moves the failure downstream. The event has to route deterministically: to the accountable executive for the operation, to the operational-risk function that owns the APRA relationship, and, for a breach of a critical operation, to the board or its delegated committee within a timeframe that leaves room to notify inside 24 hours. “We would have told the CRO” is not a pipeline. A pipeline is a named recipient at each tier, a maximum time to acknowledge, and a fallback if the first recipient does not.

Two failure modes recur. The first is under-routing: a genuine tolerance breach is triaged as a routine incident and never reaches the executive who owes APRA the call, so the 24-hour clock expires unnoticed. The second is over-routing: every transient dip pages the board, the signal is treated as noise within a fortnight, and the real breach is ignored along with the rest. The cure for both is the same — thresholds and windows that reflect the actual approved tolerance, tested against the kind of severe-but-plausible disruptions your scenario testing library should already contain, so you have watched the pipeline fire before a supervisor asks you to prove it does.

CPS 230 is, in the end, a standard about proof rather than intent — a point we have made about the standard as a whole. A tolerance is a claim about how your business behaves under stress. The detection rule and the escalation pipeline are the only things that turn that claim into something you can stand behind on the day it is tested. Build them before the day, because you do not get to design the escalation path while the clock is already running.