APRA CPS 234: the information security standard and its 72-hour and 10-day clocks

Prudential Standard CPS 234 Information Security is made by the Australian Prudential Regulation Authority (APRA) under the Banking Act 1959, Insurance Act 1973, Life Insurance Act 1995, Private Health Insurance (Prudential Supervision) Act 2015 and Superannuation Industry (Supervision) Act 1993. It commenced on 1 July 2019, and for information assets managed by a third party it applied from the earlier of the next contract renewal or 1 July 2020. APRA's handbook still lists the July 2019 version as in force. It applies to authorised deposit-taking institutions (including foreign ADIs for their Australian branch operations), general insurers, life companies and friendly societies, private health insurers, RSE licensees (super trustees), and authorised or registered non-operating holding companies. A group head must apply it across the group, including members that are not themselves APRA-regulated.

Key definitions. An information asset is information and information technology, including software, hardware and data in soft or hard copy. An information security incident is an actual or potential compromise of confidentiality, integrity or availability, so a suspected compromise still under investigation already counts. Criticality is the potential impact of losing availability; sensitivity is the potential impact of losing confidentiality or integrity. A control is any prevention, detection or response measure.

Governance and capability. The Board is ultimately responsible for information security (paragraph 13) and must make sure it is maintained in proportion to the size and extent of threats. The entity must define security roles for the Board, senior management, committees and individuals (14), keep a capability that matches its threats and keep it current as threats, assets and the business change (15 and 17), and maintain a policy framework that tells staff, contractors, related parties, third parties and customers what they are responsible for (18 and 19).

Suppliers are inside the scope. Where a related party or third party manages information assets, the entity must assess that party's security capability in proportion to the consequences of an incident (16), evaluate the design of its controls (22), check whether its control tests are adequate if the entity relies on it (28), and, where an incident could materially affect the entity or customers and internal audit intends to rely on the supplier's assurance, have internal audit assess that assurance (34). The footnotes make clear this covers all information assets held by related and third parties, not only formal outsourcing arrangements, so cloud, SaaS and managed service providers all need to be in your assessment register.

Classification, controls and incident readiness. Every information asset, including supplier-managed ones, must be classified by criticality and sensitivity according to how much an incident could hurt the entity or depositors, policyholders, beneficiaries and other customers (20). Controls must be implemented in a timely way in proportion to threats, classification, life-cycle stage and consequences (21). The entity must have robust mechanisms to detect and respond to incidents in a timely way (23), keep response plans for incidents that could plausibly occur covering every stage from detection to post-incident review plus escalation to the Board (24 and 25), and review and test those plans every year (26).

Control tests and audit. Controls must be tested through a systematic program whose depth and frequency match how fast threats change, asset criticality and sensitivity, consequences, exposure to untrusted environments and the rate of change (27). Tests must be run by appropriately skilled and functionally independent specialists (30), deficiencies that cannot be fixed in time must go to the Board or senior management (29), and the program itself must be reviewed at least annually or after a material change (31). Internal audit must review the design and operating effectiveness of security controls, including those maintained by suppliers (32 and 33). APRA's companion guide CPG 234 gives examples such as penetration tests, red team exercises, backup environment tests and code review.

The two clocks. Paragraph 35: notify APRA as soon as possible and no later than 72 hours after becoming aware of an information security incident that materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers, or that has been notified to any other regulator in Australia or overseas. Paragraph 36: notify APRA as soon as possible and no later than 10 business days after becoming aware of a material control weakness the entity expects it will not be able to remediate in a timely manner. Two practical points follow. The 72-hour clock runs from awareness, not from confirmation, and potential impact is enough. And anything you report to the OAIC under the Notifiable Data Breaches scheme, to the Department of Home Affairs under the SOCI Act, to ASD under ransomware payment reporting, or to an overseas regulator automatically meets the 'notified to other regulators' limb, so the APRA notice belongs in the same playbook step.

How it fits with CPS 230. APRA's operational risk standard CPS 230 (the version in APRA's handbook commences 1 July 2026) separately requires notice within 72 hours of an operational risk incident likely to have a material financial impact or a material impact on critical operations, and within 24 hours of a disruption to a critical operation outside tolerance. It says an information security incident already reported under CPS 234 does not need to be reported again under CPS 230, but a cyber incident that also takes a critical operation outside tolerance still triggers the 24-hour disruption notice.

What to do. Map every information asset, including SaaS and outsourced platforms, to a criticality and sensitivity rating and keep supplier assessments current. Write the 72-hour and 10-business-day triggers into your incident and vulnerability management runbooks with a named owner, and treat any notice to another regulator as an automatic APRA notice. Run and record an annual test of each response plan, keep penetration tests and control tests independent of the teams that run the systems, track overdue findings so material weaknesses reach the Board, and make sure internal audit's program explicitly covers third-party assurance.