APRA CPS 234 Guide: Information Security for APRA-Regulated Entities

APRA's information security standard is short, but its requirements on asset classification, third parties, control testing and 72-hour notification are where most regulated entities fall short. Prudential Standard CPS 234 Information Security has applied to every entity regulated by the Australian Prudential Regulation Authority (banks and other ADIs, general and life insurers, private health insurers and superannuation trustees) since 1 July 2019. It now sits alongside CPS 230 Operational Risk Management, which took effect on 1 July 2025, and the long-standing CPS 220 Risk Management. This guide walks through CPS 234 paragraph by paragraph, the evidence auditors expect, the gaps the tripartite review exposed, and how CPS 234 applies to AI and non-human identities. It is for CISOs, risk and compliance leads, internal auditors and the engineers who produce the evidence.

Key takeaways

• The Board owns it. Paragraph 13 makes the Board "ultimately responsible for the information security of the entity", so reporting has to let directors judge capability, not just read a heat map.
• Classification drives everything. Controls, testing frequency and third-party assurance all scale with the criticality and sensitivity of information assets, including assets a third party manages for you.
• Two notification clocks. Material information security incidents go to APRA within 72 hours (paragraph 35); material control weaknesses you cannot fix in time go within 10 business days (paragraph 36).
• Testing must be independent and planned. Paragraph 30 requires testing by "appropriately skilled and functionally independent specialists", and paragraph 31 requires an annual review of the testing programme.
• CPS 230 adds operational resilience. Critical operations, tolerance levels, a 24-hour clock for disruptions outside tolerance and material service provider rules now wrap around CPS 234.

Where CPS 234 sits in APRA's framework

APRA issues binding prudential standards and non-binding prudential practice guides that explain how APRA expects them to be met. CPS 234 is the binding information security standard; CPG 234, issued in June 2019, is the companion guide.

APRA may adjust or exclude a requirement for an entity, and a Head of group must apply CPS 234 group-wide, including to entities APRA does not regulate. For other jurisdictions, see the Global Cybersecurity Regulatory Map.

What CPS 234 requires, paragraph by paragraph

The operative paragraphs run from 13 to 36. The table pairs each block with the CPS 234 evidence reviewers typically ask to see.

Information asset identification and classification

CPS 234 defines an information asset broadly as "information and information technology, including software, hardware and data (both soft and hard copy)". Criticality is "the potential impact of a loss of availability" and sensitivity is "the potential impact of a loss of confidentiality or integrity". Paragraph 20 requires classification of all information assets, including those managed by related parties and third parties.

• Classify by business impact: rate an asset by the most critical operation it supports, not in isolation.
• Include what you do not run: SaaS tenants, cloud storage and provider-held data belong in the inventory. The tripartite review's most common finding was "incomplete identification and classification for critical and sensitive information assets".
• Include credentials and keys: classify signing keys, API keys, service account credentials and AI access tokens at the level of the most sensitive asset they reach.
• Keep it live: rate new systems, integrations and AI tools in change management before go-live. See the Data Classification Guide.

Third parties under CPS 234 and CPS 230

Third-party duties run through CPS 234. Paragraph 16 requires assessment of the information security capability of related and third parties that manage information assets (a footnote extends this beyond formal outsourcing agreements). Paragraph 22 requires evaluation of third-party control design, paragraph 28 covers reliance on their testing, and paragraph 34 brings third-party assurance into internal audit.

CPS 230 adds structure. Material service providers include "those on which the entity relies to undertake a critical operation". Entities must notify APRA "as soon as possible and not more than 20 business days after entering into" or materially changing an agreement for a material service supporting a critical operation (paragraph 59(a)), and notify APRA before entering any material offshoring arrangement (paragraph 59(b)).

• Tier by asset, not spend: a cheap integration holding a privileged token into core banking outranks a large facilities contract.
• Ask for evidence, not questionnaires: SOC 2 Type 2 or ISO/IEC 27001 reports, penetration test summaries, and contractual rights to test and audit. See the Third-Party Risk Management Guide.
• Control the access path: vendor accounts and integration credentials are the usual way in. The Marks and Spencer cyberattack began with impersonation of a third-party user, and the Snowflake breach showed customer data exposed through credentials without MFA on a platform the customers did not run.

Control testing, independent testing and internal audit

Paragraph 27 sets the factors that determine the nature and frequency of testing: "the rate at which the vulnerabilities and threats change", "the criticality and sensitivity of the information asset", "the consequences of an information security incident", "the risks associated with exposure to environments where the APRA-regulated entity is unable to enforce its information security policies" and "the materiality and frequency of change to information assets". CPG 234 expects sufficient controls to be tested at least annually and controls exposed to untrusted environments to be tested throughout the year.

• Independence: the operators of a control cannot test it themselves.
• Escalation: paragraph 29 requires deficiencies that cannot be remediated in a timely manner to be escalated to the Board or senior management, usually through a findings register with ageing and owner.
• Internal audit: paragraphs 32 to 34 require skilled review of control design and operating effectiveness. See the Penetration Testing Guide for scoping.

The CPS 234 tripartite review

Under its 2020 to 2024 Cyber Security Strategy, APRA required each regulated entity to appoint an independent auditor to assess its CPS 234 compliance, with more than 300 banks, insurers and superannuation trustees expected to take part by the end of 2023. APRA's 5 July 2023 release on the first tranche listed six common gaps: incomplete asset identification and classification, limited assessment of third-party capability, inadequate control testing programmes, untested incident response plans, limited internal audit review of security controls, and inconsistent, late reporting to APRA. Use them as a self-assessment list.

Incident and control weakness notification

Paragraph 35 requires notification "as soon as possible and, in any case, 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 other regulators, either in Australia or other jurisdictions". An information security incident is "an actual or potential compromise of information security", so near misses with potential material impact count. Paragraph 36 requires notification "no later than 10 business days" after becoming aware of a material control weakness the entity expects it cannot remediate in a timely manner.

The second limb of paragraph 35 is easy to miss: a breach notified to the OAIC under the Notifiable Data Breaches scheme, or to an overseas regulator, also triggers the 72-hour APRA clock regardless of APRA materiality. Build one incident triage step that checks every regulatory clock at once. See the Incident Response Guide and, for the privacy side, the Global Privacy Regulatory Map.

CPS 234 and CPS 230 together

CPS 230 replaced APRA's separate outsourcing and business continuity standards and brought them into one operational risk standard. APRA deems certain operations critical: for ADIs "payments, deposit-taking and management, custody, settlements and clearing"; for insurers "claims processing"; for RSE licensees "investment management and fund administration"; and for all entities "customer enquiries and the systems and infrastructure needed to support critical operations". For each critical operation the entity sets tolerance levels for the maximum period of disruption, the maximum extent of data loss and minimum service levels under alternative arrangements (paragraph 38), runs "an annual business continuity exercise" (paragraph 43) and updates its business continuity plan annually.

• Shared asset view: map each CPS 234 asset to the CPS 230 critical operations it supports.
• Cyber scenarios in continuity testing: the annual exercise should include ransomware and identity platform compromise, and test recovery of the directory and privileged access tooling. See the Business Continuity and Disaster Recovery Guide.
• Risk framework link: CPS 220 requires a risk appetite statement, an independent CRO with a direct reporting line to the CEO, a comprehensive review of the risk management framework at least every three years and an annual risk management declaration to APRA.

Where identity fits: CPG 234 Attachment C and AI

CPG 234 Attachment C (Identity and access) expects access to be granted only on valid business need and only for as long as required, "multi-factor authentication for privileged access, remote access and other high-risk activities", regular access reviews by information asset owners, a two-person rule for the most sensitive assets such as encryption keys, and heightened monitoring of privileged accounts.

AI security under CPS 234 is now explicit supervisory territory. APRA's 30 April 2026 letter to all regulated entities states that "existing prudential standards apply to AI risk", observes that identity and access management "have not yet adjusted to nonhuman actors such as AI agents", and expects "strong privileged access management", "controls over agentic and autonomous workflows", "an inventory of AI tooling and AI use cases" and mapping of "the full AI supply chain", including fourth parties.

• Treat agents and service accounts as information assets: inventory them, assign an owner and classify them by what they can reach. See the Service Account Security Guide.
• Apply Attachment C to non-human identities: least privilege, short-lived credentials and recertification by the asset owner apply to API keys and agent tokens just as to people. See the Agentic AI Identity Guide.
• Bring privileged paths into scope: vault and rotate privileged credentials and monitor sessions. See the Privileged Access Management Guide.

How to implement CPS 234: a phased approach

1. Baseline (months 0 to 3): run a gap assessment against paragraphs 13 to 36 and the six tripartite findings; confirm Board and committee roles; agree materiality criteria for paragraphs 35 and 36 with risk and legal.
2. Inventory and classify (months 2 to 6): build the register from CMDB, cloud accounts, SaaS discovery and contracts; rate criticality and sensitivity; map to CPS 230 critical operations.
3. Third-party assurance (months 4 to 9): tier providers by the assets they manage; collect independent assurance; add testing, audit and notification clauses at renewal.
4. Testing programme (months 6 to 12): define test types and cadence per asset class using the paragraph 27 factors; confirm tester independence; start a findings register with escalation thresholds; schedule the annual programme review.
5. Notification drill: run a tabletop that forces decisions on the 72-hour, 10 business day and CPS 230 24-hour clocks and the OAIC notification, then fix the gaps it finds.
6. Assure and report: give internal audit a plan covering design and operating effectiveness, and give the Board a quarterly report combining metrics with commentary on business impact, as CPG 234 Attachment H describes.

Where a control cannot be implemented, record the exception, compensating control and date, and assess whether it is a paragraph 36 weakness.

Decision guidance

• Internal or external testers: a functionally independent, skilled internal team can satisfy paragraph 30; use external specialists for internet-facing critical assets, specialist techniques and controls internal teams helped design.
• Is it material? Decide in advance: customer data compromise at scale, loss of a critical operation, compromise of privileged or signing credentials, ransomware and anything notified to another regulator. CPG 234 says notification should not wait for complete information.
• Small versus large entities: a small insurer or superannuation trustee relying on providers will spend most effort on paragraphs 16, 22 and 28; a major bank on testing depth, red teaming and group-wide application.
• One control framework: map CPS 234 to ISO/IEC 27001, NIST CSF 2.0 or the ASD Essential Eight rather than running a parallel one. See the Essential Eight Guide.

Detection and measurement

CPG 234 describes behavioural baselining, scanning for unauthorised hardware and software, threshold-based sensors and logging of access to sensitive data. Log privileged sessions, identity provider and access policy changes, creation of keys and service accounts, and data access on critical and sensitive assets.

• Classification coverage: percentage of critical and sensitive assets (including third-party managed) with an owner and current rating.
• Testing coverage: percentage of critical assets tested within the cadence their classification requires.
• Finding age: number of high findings open past their due date and how many were escalated under paragraph 29.
• Third-party assurance: percentage of providers managing critical or sensitive assets with current independent assurance reviewed.
• Notification timeliness: time from awareness to APRA notification for every reportable event, against 72 hours and 10 business days.
• Privileged and non-human identity hygiene: percentage of privileged and service accounts with MFA or vaulted, rotated credentials, and AI tools with a recorded owner.

Framework mapping

Common failure patterns

• Inventory that stops at the data centre: SaaS, provider-held data, keys and service accounts are missing, so classification and testing never reach them.
• Questionnaire-only third-party assurance: no evaluation of control design under paragraph 22 and no testing evidence under paragraph 28.
• Unsystematic testing: a few annual penetration tests unrelated to classification, run by the control operators.
• Untested response plans: plans that exist but have not been exercised in the past year, or exercises without success criteria.
• Late or missing notifications: teams waiting for certainty before notifying, or forgetting that an OAIC notification also starts the APRA clock.
• Unprotected privileged and integration credentials: the CitrixBleed exploitation showed stolen session tokens bypassing MFA at organisations including ICBC, so session monitoring matters as much as MFA itself.

Practitioner checklist

• Confirm the Board's role and reporting under paragraphs 13 and 14, with minutes that show challenge.
• Build one asset inventory covering third-party managed assets, keys, service accounts and AI tools, rated by criticality and sensitivity.
• Map every critical and sensitive asset to the CPS 230 critical operations it supports.
• Assess third-party capability and control design for every provider managing critical or sensitive assets.
• Define a testing programme from the paragraph 27 factors, with independent testers and an annual review.
• Test incident response plans at least annually with defined success criteria.
• Agree written materiality criteria for paragraphs 35 and 36 and rehearse every notification clock together.
• Apply CPG 234 Attachment C controls to non-human identities and AI agents as well as people.
• Report metrics with business-impact commentary to the Board each quarter.

Standards and references

• APRA: Prudential Standard CPS 234 Information Security
• APRA: Prudential Practice Guide CPG 234 Information Security
• APRA: Prudential Standard CPS 230 Operational Risk Management
• Federal Register of Legislation: Prudential Standard CPS 220 Risk Management
• APRA: Cyber security stocktake exposes gaps
• APRA: Letter to industry on artificial intelligence (AI)
• APRA: APRA finalises new prudential standard on operational risk

Related NHI Mgmt Group resources: Financial Services Identity Security Guide · Global Cybersecurity Regulatory Map · DORA Guide · Third-Party Risk Management Guide · Board Cyber Risk Reporting Guide. This guide summarises APRA CPS 234, CPG 234, CPS 230 and CPS 220 as of 18 October 2026 and is not legal advice.