Incident notification - the two clocks (72h vs 24h)

The notification obligations sit in CPS 230. An entity must notify APRA as soon as possible, and not later than 72 hours, after becoming aware of an operational risk incident it determines is likely to have a material financial impact or a material impact on its ability to maintain its critical operations. Separately, it must notify APRA as soon as possible, and not later than 24 hours, after a disruption to a critical operation outside tolerance, covering the nature of the disruption, the action taken, the likely impact, and the timeframe for returning to normal. The standard applies to non-significant financial institutions from 1 July 2026. The core standard has applied since 1 July 2025.

Take one critical operation you support. Ask whether your incident runbook outputs, within hours, the four facts your client must report on a tolerance breach: nature, action taken, likely impact, time to normal. If it does not, that is a runbook and a contract gap, and it is fixable before 1 July.

An incident process built to resolve the outage but not to report it. If your runbook tells your engineers what to do but cannot tell your client what to say to APRA inside 24 hours, the client is carrying a regulatory deadline on information only you hold. That gap shows up at the worst possible moment.

When an operational incident hits, the question a regulated entity asks early is not only how to fix it. It is which clock has started.

CPS 230 sets two separate notification timeframes, and they are often run together as if they were one. They are not. They are triggered by different things, and they run for different lengths.

The first is the 72 hour clock. It starts when the entity becomes aware of an operational risk incident it judges likely to have a material financial impact, or a material impact on its ability to maintain a critical operation. The trigger is materiality. The judgement is the entity's own, made early and on incomplete information.

The second is the 24 hour clock. It starts when a critical operation has been disrupted outside its tolerance. The trigger here is not materiality. It is the tolerance level the board has already approved. If a critical operation breaches that tolerance, the entity has one day to tell APRA the nature of the disruption, the action taken, the likely impact on its business operations, and the timeframe for returning to normal.

The common error is to treat 24 hours as the deadline for reporting incidents in general. It is not. The 24 hour clock is the tolerance-breach clock, and it is the shorter and sharper of the two. A single event can trip the 72 hour clock, the 24 hour clock, both, or neither. Knowing which one is running, and the moment it started, is the difference between a notification that is on time and one that is late.

For a service provider, this matters even though the obligation sits with the client. Three of the four things APRA wants inside 24 hours, the nature of the disruption, the action taken, and the timeframe to return to normal, usually live with the provider running the service. If the provider's incident process cannot surface those facts inside a day, the client cannot meet the clock, however good its own intentions.

So the useful question for a provider is not whether it has an incident process. It is whether that process produces, quickly, the specific facts a client needs to make a notification, and whether the contract requires it. A tolerance breach does not wait for a status page to update.

My view: the 24 hour clock is the one that catches people out. It starts on a tolerance breach, not a judgement call, so there is no thinking time. If you have not already decided who watches the tolerance and who hands you the four facts, you will miss it. Decide that now, not during the incident.

If this was useful, the free Quick Check tests one critical operation against both notification clocks in about ten minutes.