Best Practices for CPS 234 Incident Response in Australia

CPS 234 has one clause that keeps boards awake: once you become aware of a material information security incident, you have 72 hours to notify APRA, and once you become aware of a material information security control weakness that you cannot remediate promptly, you have 10 business days. I have run more than 200 security assessments across 14 countries since 2013, and in APRA-regulated entities the weak point is almost never the firewall. It is the response process - who decides an incident is "material", who drafts the APRA notification, and whether anyone has ever rehearsed the path before a real breach forces them to improvise.

This guide walks through how I approach CPS 234 incident response with Australian banks, insurers, and superannuation trustees. No theatrics, no invented case studies - just the practices that hold up when an incident is live and the clock is running.

What CPS 234 Actually Requires During an Incident

CPS 234 came into force on 1 July 2019 and applies to all APRA-regulated entities: authorised deposit-taking institutions, general and life insurers, private health insurers, and registrable superannuation entity licensees. It is principle-based rather than a control checklist, which is exactly why so many entities misread what "good" looks like during an incident.

Three obligations dominate the response phase:

• Notify APRA of a material incident within 72 hours of becoming aware of it (paragraph 35). The 72 hours is not from when you finish investigating - it starts when you become aware.

• Notify APRA of a material control weakness within 10 business days (paragraph 36), including weaknesses you expect you will be unable to remediate in a timely manner.

• Maintain and test response capability so that detection, containment, and recovery are commensurate with the threats you face and the criticality of the assets involved.

The board remains ultimately accountable. You can outsource operations, but you cannot outsource responsibility. That single sentence, drawn straight from the intent of CPS 234, should shape every design decision below.

Best Practice 1: Define "Material" Before You Are In the Middle of an Incident

The most common failure I see is entities trying to decide whether an event is material while the event is still unfolding. That is the worst possible time. Adrenaline, incomplete information, and a natural bias toward downplaying bad news all push teams toward under-reporting, and under-reporting to APRA is precisely the outcome that draws regulatory attention.

Decide the thresholds in advance and write them down. A workable materiality definition considers the sensitivity and volume of data affected, whether a critical or customer-facing system is degraded, whether financial or personal information may have been accessed or exfiltrated, and whether the incident could plausibly affect the entity's ability to meet its obligations to customers or beneficiaries.

What to put in place:

• A one-page materiality matrix that a duty manager can apply at 2am without calling a lawyer.

• A named decision owner (and a documented deputy) authorised to declare a notifiable incident.

• A default bias toward notification when the assessment is genuinely uncertain. APRA has never penalised an entity for being transparent early.

If you cannot answer "is this material?" in under fifteen minutes with the information you typically have on hand, your definition is too abstract. Tighten it.

Best Practice 2: Build a Runbook, Not a Policy

A policy tells an auditor you thought about incident response. A runbook tells your on-call engineer what to do at 3am. These are not the same document, and CPS 234 cares about the second one because it is evidence that your capability is real rather than aspirational.

A response runbook that survives contact with a real incident covers the full lifecycle:

1. Detection and triage - how alerts reach a human, initial severity scoring, and the first fifteen minutes of actions.

2. Containment - concrete steps to isolate affected systems, revoke credentials, and preserve forensic evidence before you start wiping things.

3. Escalation and notification - the internal escalation tree and the APRA notification workflow with the 72-hour clock made explicit.

4. Eradication and recovery - validated steps to remove the threat and restore service from known-good backups.

5. Post-incident review - a structured lessons-learned process that feeds back into controls.

Assign named roles: an incident lead who owns decisions, a communications owner who handles internal and regulator messaging, a technical lead who directs containment, and a scribe who timestamps every action. The scribe role is undervalued and disproportionately important - your APRA notification and any later review depend on an accurate timeline, and memory is not a timeline.

If you do not have the internal seniority to own this end to end, a virtual CISO can carry the incident lead and board-reporting role until you build it in-house.

Best Practice 3: Rehearse the APRA Notification Path Before You Need It

The 72-hour clock is unforgiving because most delay is self-inflicted. Teams lose the first day arguing about materiality, the second day drafting a notification from scratch, and then discover nobody is sure who signs it off. Rehearsal removes all three problems.

Run tabletop exercises at least twice a year, and make at least one of them a scenario that forces a genuine notification decision - ransomware on a customer-facing platform, or credential compromise at a material service provider. During the exercise, actually draft the notification. Pre-build a template that captures what APRA expects: nature and timing of the incident, systems and data affected, current containment status, and remediation steps under way.

The organisations that report calmly within 72 hours are the ones that have written the notification before, under no pressure, in a room where a mistake costs nothing. If you have never penetration-tested the systems that would be involved, a penetration test and a follow-up vulnerability assessment also give your tabletop scenarios a realistic starting point instead of a hypothetical one.

Best Practice 4: Extend Response Obligations to Third Parties

CPS 234 explicitly extends to information assets managed by related parties and third parties. In practice, a large share of material incidents at regulated entities originate at a supplier - a SaaS platform, a managed service provider, or an outsourced processor. If your response plan stops at your own perimeter, it does not meet the standard.

Two things matter here. First, contracts must obligate providers to notify you of incidents fast enough that you can still meet your own 72-hour obligation to APRA. A supplier that tells you five days later has already made you non-compliant. Second, you need to have tested that notification path - a clause in a contract you have never exercised is a hope, not a control.

When I assess third-party arrangements, I look for named contacts on both sides, an agreed severity language so "critical" means the same thing to both parties, and evidence that the notification channel has actually been used at least once. If you rely heavily on cloud providers, pairing this review with dedicated cloud security consulting closes the gap between what the contract says and what your architecture actually allows.

Best Practice 5: Capture Evidence and Run a Real Post-Incident Review

CPS 234 requires you to test the effectiveness of your controls and have internal audit review the design and operation of information security controls. Incidents are your richest source of evidence for both. An incident you handled but did not document is a missed opportunity and, from an audit perspective, close to an incident that did not happen at all.

Keep a contemporaneous log during the incident, retain forensic artefacts, and hold a blameless post-incident review within two weeks while details are fresh. The review should produce specific, owned, dated remediation actions - not a vague resolution to "improve monitoring". Track those actions to closure and report the trend to the board.

This documentation is also what turns a bad day into a defensible position. When APRA or your internal auditor asks how you handled an event, a complete timeline, a clear materiality decision, and a closed set of remediation actions demonstrate exactly the capability the standard is asking you to maintain. A periodic IT security audit is the cleanest way to confirm that this evidence would stand up before you are relying on it under scrutiny.

CPS 234 Notification Obligations at a Glance

The two notification obligations are frequently confused. This is the distinction that matters most when an event occurs:

Trigger	Deadline	Clock starts	Typical example
Material information security incident	72 hours	When you become aware of the incident	Ransomware, confirmed data exfiltration, customer-facing outage from an attack
Material information security control weakness	10 business days	When you become aware you cannot remediate it in a timely manner	An unpatched critical vulnerability on a key system with no near-term fix

Read those two rows carefully. The obligation is not only about incidents that have already caused harm. A serious control weakness you cannot fix promptly is itself notifiable, and entities that overlook the second row are the ones most likely to be surprised by a regulator.

A Practical Incident Response Maturity Path

If you are building this capability from a low base, sequence it rather than trying to stand up everything at once:

Stage	Focus	What "done" looks like
Foundation	Materiality definition, roles, notification template	A duty manager can declare and draft within an hour
Operational	Runbook, detection tuning, evidence handling	On-call staff follow documented steps without improvising
Tested	Tabletop exercises, third-party notification drills	Notification path exercised at least twice a year
Assured	Internal audit review, board reporting, trend tracking	Independent assurance that controls operate as designed

Most entities I assess sit somewhere between Foundation and Operational and assume they are further along than they are. The honest test is simple: could you produce a defensible APRA notification, with an accurate timeline, for an incident that started an hour ago? If the answer is no, start at Foundation.

Frequently Asked Questions

How quickly must we notify APRA of a security incident under CPS 234?

No later than 72 hours after you become aware of a material information security incident. Separately, you must notify APRA of a material information security control weakness within 10 business days. The 72-hour clock starts at awareness, not at the completion of your investigation, which is why a pre-decided materiality definition is so important.

Who decides whether an incident is "material"?

CPS 234 leaves the assessment to the entity, which is exactly why you should define thresholds in advance and name an accountable decision owner with a documented deputy. Deciding materiality live, during an unfolding incident, is where most under-reporting happens. When in genuine doubt, notify.

Does CPS 234 cover incidents at our third-party providers?

Yes. The standard applies to information assets managed by related parties and third parties. If a supplier suffers an incident affecting your data or systems, your notification obligations to APRA can still be triggered. Your provider contracts must require notification fast enough for you to meet your own 72-hour deadline, and you should test that channel rather than assume it works.

How often should we test our incident response plan?

At least twice a year, with at least one exercise that forces a real notification decision. Testing is not only good practice - CPS 234 requires you to test control effectiveness and have internal audit review your controls. Untested plans consistently fail under the pressure of a live incident.

Do we need a full-time CISO to meet CPS 234 incident response requirements?

Not necessarily. Smaller regulated entities and fintechs frequently meet the requirement with a fractional or virtual CISO who owns the response process, board reporting, and the APRA notification decision. What CPS 234 requires is capability commensurate with your risk, not a specific headcount.

What evidence should we keep after an incident?

A contemporaneous, timestamped action log, forensic artefacts from affected systems, the materiality assessment and any APRA notification, and a documented post-incident review with owned, dated remediation actions tracked to closure. This is the evidence your internal auditor and APRA will look for as proof that your response capability is real.

Where to Start

If you take one thing from this: incident response under CPS 234 is won or lost before the incident, in the definitions you write, the runbook you build, and the notification path you rehearse. The technology matters, but the process is what regulators actually test.

If you want an experienced set of eyes on your current plan - or someone to own the response capability while you build it internally - get in touch. For the wider compliance picture, our guides on how to prepare for a CPS 234 audit and what CPS 234 actually requires are good next reads.