APRA CPS 234 Information Security: What Every APRA-Regulated Entity Must Implement

What is APRA CPS 234?

APRA Prudential Standard CPS 234 Information Security is the mandatory information security standard that applies to all APRA-regulated entities (AREs) — including banks, credit unions, general insurers, life companies, private health insurers, and superannuation fund licensees — and their material ICT third-party service providers. It has been mandatory since 1 July 2019.

CPS 234 is principles-based rather than prescriptive. APRA does not mandate specific technologies or control frameworks. Instead, it requires entities to maintain information security capability commensurate with the size, nature, and complexity of threats to their information assets. This means controls that are appropriate for a major ADI will differ from those appropriate for a small health insurer — but both must satisfy the standard.

The companion guidance is CPG 234 Information Security, which provides detailed guidance on how to satisfy each CPS 234 requirement. CPG 234 also describes the annual self-assessment that entities must complete and retain for APRA review.

Who must comply with CPS 234?

CPS 234 applies to:

• Authorised Deposit-taking Institutions (ADIs) — banks, credit unions, building societies
• General insurers
• Life companies and friendly societies
• Private health insurers
• Registrable Superannuation Entity (RSE) licensees
• Registered Financial Corporations (RFCs)
• ICT third-party service providers when they manage information assets on behalf of an ARE

If you are a SaaS company providing cloud infrastructure, core banking software, insurance policy management, or any other material ICT service to an APRA-regulated entity, CPS 234 applies to you indirectly — the regulated entity must ensure you maintain CPS 234-equivalent security capability, and will contractually require this.

The 8 CPS 234 requirement areas

1. Information Security Capability (¶10–13)

The Board is accountable for ensuring the entity maintains an appropriate information security capability. CPS 234 ¶10 places this responsibility squarely on the Board — not just on management. APRA expects boards to demonstrate active engagement with information security, not passive oversight.

Key requirements in this area:

• Board maintains and oversees information security capability proportionate to threat environment (¶10)
• Roles and responsibilities for information security are explicitly defined for the Board, senior management, and relevant third parties (¶11)
• Third-party information security responsibilities are identified and documented (¶12)
• Security capability is commensurate with the size and nature of threats — including emerging cyber threats (¶13)

APRA supervisory reviews regularly examine Board minutes for evidence of information security oversight. A board that receives only annual security briefings is unlikely to satisfy ¶10 for a medium or large entity.

2. Policy Framework (¶14–17)

Every APRA-regulated entity must maintain a comprehensive information security policy framework covering all information assets, including those managed by third parties. The framework must be endorsed at an appropriate level (typically Board or senior management), reviewed at least annually, and communicated to all relevant stakeholders.

Common gaps observed by APRA in this area: policies that haven't been updated since initial certification, policies that don't address cloud or third-party managed environments, and policies with no evidence of Board-level endorsement.

3. Information Asset Identification and Classification (¶18–23)

CPS 234 requires a complete asset register covering all information assets — hardware, software, data, and services managed by third parties. Assets must be classified by criticality and sensitivity, and the register must be kept current. This classification is the foundation for everything else in CPS 234: control selection (¶24), testing scope (¶35), and audit coverage (¶37) all depend on having an accurate asset register with meaningful classifications.

Common gap: treating the asset register as an annual exercise. APRA expects the register to be updated when new systems are deployed, decommissioned, or materially changed.

4. Implementation of Controls (¶24–30)

Controls must be implemented commensurate with asset criticality and sensitivity. Higher-criticality assets must have proportionally stronger controls. Third-party controls must be assessed — not just assumed to exist. Residual risk after controls must be formally accepted by an authority with appropriate seniority.

CPS 234 ¶26-27 is a major focus area for APRA supervisors: entities must assess the controls of third parties managing their information assets. For critical assets, this means more than relying on a vendor's SOC 2 report. APRA expects entities with critical third-party dependencies to exercise audit rights, commission independent assessments, or conduct on-site reviews.

5. Incident Management (¶31–34)

The entity must have a documented incident response plan specific to information security incidents. The plan must cover detection, classification (including criteria that trigger APRA notification), containment, eradication, recovery, and post-incident review. Contact details for internal and external escalation — including APRA contacts — must be documented and current.

Critically, the notification process (described in detail under requirement area 8 below) must be rehearsed through tabletop exercises. A process that exists on paper but has never been tested is unlikely to be executed correctly under the pressure of a real incident.

6. Testing Control Effectiveness (¶35–36)

CPS 234 requires a systematic testing programme — planned, scheduled, and documented — with test frequency and rigour proportional to asset criticality. For high-criticality assets, testing must be performed by suitably qualified and operationally independent parties (¶36). A typical testing programme includes:

• Vulnerability assessments — at least annually for all material systems, quarterly for high-criticality systems
• Penetration testing — at least annually by independent, qualified testers (CREST-certified, OSCP-qualified, or equivalent)
• Control effectiveness testing — testing specific controls against defined objectives
• Tabletop/scenario exercises — testing detection, response, and notification processes

Testing results must be documented and remediation tracked to closure. APRA expects critical findings from penetration tests to be remediated promptly, not deferred indefinitely.

7. Internal Audit (¶37–39)

The internal audit function must provide at least annual assurance over the effectiveness of information security controls — including controls maintained by third parties. Internal audit must have sufficient information security expertise (either in-house IS audit staff, or external IS specialist co-sourcing). Findings must be reported to the Board Audit Committee, with management responses tracked.

A common deficiency: generic IT audit teams without IS specialisation attempting to audit complex cloud environments. APRA expects IS-specific audit capability, not just general IT knowledge.

8. Notification to APRA (¶40–46)

This is the most operationally critical area of CPS 234. APRA notification obligations are strict:

72-hour notification for material incidents (¶40)

When an entity becomes aware of a material information security incident, it must notify APRA within 72 hours. The clock starts when the entity becomes aware — not when the incident is fully investigated. Internal escalation delays count toward the 72-hour window.

What makes an incident 'material' is not exhaustively defined, but APRA has indicated in supervisory letters that materiality should be assessed against: impact on customers, impact on financial stability, regulatory reporting obligations triggered, and reputational significance. When in doubt, notify.

The notification must include prescribed information under ¶41: description of the incident, systems and data affected, actual and potential impact, actions taken and planned, and a timeline for updates.

10-day notification for material control weaknesses (¶45)

If the entity (or its auditors, testers, or third parties) identifies a material weakness in information security controls that cannot be remediated within a reasonable timeframe, APRA must be notified within 10 days of the entity becoming aware. This applies to weaknesses in the entity's own controls and weaknesses in controls maintained by third parties on behalf of the entity.

Entities need a clear definition of 'material weakness' to trigger the ¶45 clock consistently. Recommended approach: define materiality thresholds in your information security policy (e.g. critical-severity finding from penetration test with no compensating control, or a third-party assessment finding that directly affects a high-criticality system).

Annual self-assessment (¶46)

Every APRA-regulated entity must conduct an annual self-assessment of compliance with CPS 234, following CPG 234 guidance. The self-assessment must be substantive — not a checkbox exercise — and retained for APRA review. The Board or senior management must attest to the self-assessment.

APRA has been known to request self-assessments during supervisory reviews. Entities that produce superficial self-assessments (e.g. all items marked 'compliant' without supporting evidence) face greater supervisory scrutiny.

The third-party risk management challenge

Third-party ICT risk management is the most challenging aspect of CPS 234 for most entities. The principle is clear: even when information assets are managed by a third party, the APRA-regulated entity remains accountable for their security.

In practice, this means:

1. Due diligence before engaging — assess the third party's security capability before contracting, not just via a questionnaire but through assessment of independent certifications (ISO 27001, SOC 2) reviewed critically, not just accepted at face value.
2. Contractual requirements — contracts must include security obligations equivalent to CPS 234, incident notification requirements (typically 24-48h to the entity when a security event occurs), audit rights, and regulatory access provisions.
3. Ongoing monitoring — annual review at minimum; more frequent for providers managing high-criticality assets.
4. Exercising audit rights — for critical providers, APRA expects audit rights to actually be exercised, not just to exist contractually.

How CPS 234 relates to other frameworks

CPS 234 does not mandate any particular control framework, but CPG 234 notes that entities may use established frameworks to satisfy the standard. Common mappings:

• ISO 27001:2022 — an ISO 27001 certification provides strong evidence of policy framework, asset management, and control implementation (CPS 234 ¶14-30). However, ISO 27001 does not cover the specific APRA notification obligations or the Board accountability requirements. Additional work is needed.
• NIST Cybersecurity Framework — maps well to the Identify, Protect, Detect, Respond, Recover structure of CPS 234. Useful for structuring control evidence.
• ASD Essential Eight — the Australian Signals Directorate's Essential Eight are commonly referenced in CPG 234. Achieving Maturity Level 2 or above against the Essential Eight provides strong evidence for the control implementation requirements (¶24-30).
• SOC 2 Type II — a SOC 2 Type II report from a service provider can partially satisfy APRA's third-party control assessment requirements (¶26-27), but APRA expects entities to review reports critically, not just file them.

5 common APRA CPS 234 compliance mistakes

1. Board accountability is on paper only — IS governance is delegated to management with no genuine Board-level engagement. APRA will find this in minutes review.
2. Outdated asset registers — the register was created during initial assessment and hasn't been updated since. New cloud services, SaaS tools, and third-party integrations are missing.
3. Reliance on vendor attestations alone — accepting a third party's SOC 2 report or security questionnaire without critical review, and never exercising audit rights.
4. Untested APRA notification process — the 72-hour notification procedure exists in a document but has never been rehearsed. Under real incident pressure, the process won't work.
5. Superficial annual self-assessment — completing ¶46 as a checkbox exercise without genuine evidence review, leaving the entity exposed during supervisory review.

Getting started: 6-step CPS 234 compliance approach

1. Board information security training — ensure management body members have sufficient IS knowledge to satisfy ¶10-11. Document training completion.
2. Asset register and classification — build or update your complete information asset register, including all third-party managed assets, classified by criticality and sensitivity.
3. Control gap assessment — assess controls against CPS 234 requirements, use CPG 234 as the evaluation benchmark. Use ComplyKit's APRA CPS 234 Compliance Checklist to structure and document the assessment.
4. Third-party risk programme — identify all third parties managing information assets, tier by criticality, and establish appropriate due diligence and monitoring for each tier.
5. Incident response and notification rehearsal — document the 72-hour and 10-day notification processes, identify APRA contacts, and run a tabletop exercise that tests them.
6. Annual self-assessment — implement a structured CPG 234 self-assessment process with Board attestation and evidence retention.

ComplyKit's APRA CPS 234 Compliance Checklist generates a scored assessment covering all 8 CPS 234 requirement areas, with APRA-specific remediation guidance, notification deep-dive, and a phased remediation roadmap — free, no account required.