APRA CPS 234 (Australia)

Introduction

Prudential Standard CPS 234 Information Security is the cornerstone information-security regulation issued by the Australian Prudential Regulation Authority (APRA). It applies across the whole prudentially regulated financial sector in Australia and took effect on 1 July 2019. Unlike voluntary frameworks, CPS 234 is legally enforceable: it is made under the various industry Acts (the Banking Act 1959, the Insurance Act 1973, the Life Insurance Act 1995, the Private Health Insurance (Prudential Supervision) Act 2015 and the Superannuation Industry (Supervision) Act 1993). Non-compliance can attract formal enforcement action, licence conditions and heightened supervisory scrutiny.

CPS 234 is deliberately outcomes-based rather than prescriptive. It sets out a small number of legally binding objectives that an APRA-regulated entity must achieve, and it holds the Board ultimately accountable for information security. This guide provides an auditor-grade, clause-by-clause deep dive: what CPS 234 requires, who it binds, how to scope and assess it, the evidence an assessor should demand, a maturity model to benchmark against, and how it maps to other frameworks such as ISO/IEC 27001, the NIST CSF and PCI DSS. It is written to support both first-line implementation and independent third-party review.

What is APRA CPS 234

CPS 234 is a cross-industry prudential standard whose stated objective is to ensure that an APRA-regulated entity takes measures to be resilient against information security incidents, including cyber-attacks, by maintaining an information security capability commensurate with information security vulnerabilities and threats. In plainer terms, APRA wants regulated financial institutions to protect the confidentiality, integrity and availability of the information assets they hold, both their own and those of their customers, in proportion to the risk those assets carry.

The standard is short, roughly two pages of operative clauses, but each clause is dense and legally binding. Its key design features are:

• Outcomes-based: it specifies what must be achieved (e.g. 'maintain an information security capability commensurate with the size and extent of threats') rather than mandating specific technologies or control catalogues.
• Board accountability: the Board of the regulated entity is explicitly and ultimately responsible for information security. This cannot be delegated away.
• Third-party reach: it extends obligations to information assets managed by related parties and third parties (service providers, cloud, outsourcers), so a regulated entity cannot escape accountability by outsourcing.
• Mandatory incident notification: it introduces hard notification timeframes to APRA (72 hours for material incidents; 10 business days for material control weaknesses).
• Continuous assurance: it requires systematic testing of controls and independent review of the security control testing programme.

CPS 234 is complemented by CPG 234 Information Security, a non-binding Prudential Practice Guide that describes better-practice implementation. CPG 234 is where APRA expresses its expectations in detail and is the practical yardstick supervisors use when assessing an entity.

It is important to understand the regulatory philosophy behind CPS 234. APRA has publicly stated that its objective is not to prescribe a fixed shopping list of controls, because the threat environment moves faster than any static rule could accommodate, and because the diversity of entities it regulates, from a single-fund RSE licensee to a systemically important major bank, makes a one-size-fits-all catalogue meaningless. Instead the standard fixes the accountability (the Board), the outcomes (resilience against information security incidents), and the assurance loop of test, review and notify, and leaves the choice of specific controls to the entity, subject to the overriding requirement that everything be commensurate with the entity's vulnerabilities and threats. This is why an auditor cannot simply tick controls against a checklist; they must form a defensible judgement about whether the entity's control set is proportionate to its risk. APRA reinforces this expectation through its supervisory activities, thematic reviews and, since 2020, a tripartite assessment programme in which an independent third party reviews an entity's CPS 234 compliance and reports findings that the entity shares with APRA.

CPS 234 also introduced, for the first time in Australian prudential regulation, hard external notification timeframes for cyber events. Before CPS 234, incident reporting to APRA was largely discretionary and inconsistent. The 72-hour incident-notification clock and the 10-business-day control-weakness notification obligation give APRA near-real-time visibility of systemic cyber risk across the financial sector, and they force entities to build the internal triage, materiality-assessment and escalation machinery needed to meet those deadlines. Failing to notify, or notifying late, is itself a breach that supervisors take seriously. It is worth noting that CPS 234 sits within a wider APRA framework: CPS 230 Operational Risk Management (effective 2025) subsumes and extends the earlier outsourcing (CPS 231) and business continuity (CPS 232) standards, and interacts closely with CPS 234 where information security incidents cause operational disruption.

Who must comply

CPS 234 applies to all APRA-regulated entities across banking, insurance and superannuation. The obligation extends to the Head of a group and, where relevant, to the group as a whole. The table below summarises the population in scope.

Third parties are not directly bound by CPS 234, but regulated entities must contractually and operationally ensure that the information security of assets managed by related parties and third parties is assessed and maintained. In practice this pulls cloud providers, IT outsourcers, administrators and shared-service entities firmly into the assessment scope.

Structure of APRA CPS 234

CPS 234 is organised as a set of numbered operative clauses grouped into logical themes. The following table maps the clause groups (the effective 'control domains') to their intent. Clause numbers reflect the standard as in force; assessors should confirm against the current published version.

Master assessment checklist

This is the core of the guide. Each CPS 234 domain is broken down into its constituent obligations. For every group, the table states what an assessor must verify and the typical evidence that demonstrates conformance. No control area is skipped. Assessors should record a conformance rating and observation against each line.

Domain 1 - Roles and responsibilities (clauses 13-14)

Domain 2 - Information security capability (clauses 15-17)

Domain 3 - Policy framework (clauses 18-20)

Domain 4 - Information asset identification and classification (clauses 21-22)

Domain 5 - Implementation of controls (clauses 23-26)

Domain 6 - Incident detection and response (clauses 27-30)

Domain 7 - Testing control effectiveness (clauses 31-34)

Domain 8 - Internal audit and independent assurance (clauses 35-36)

Domain 9 - APRA notification (clauses 36-40)

Scoping

Scoping a CPS 234 assessment means defining the boundary of information assets, systems, environments, related parties and third parties to which the standard applies for a given regulated entity. Because CPS 234 explicitly reaches into third-party and related-party arrangements, scope is broader than a traditional internal-only IT audit.

• Legal entity boundary: identify every APRA-regulated entity in the group and whether obligations apply at Level 1, Level 2 or Level 3 (group) basis.
• Information asset universe: all data and systems, including on-premises, cloud (IaaS/PaaS/SaaS), end-user computing and physical records, classified by criticality and sensitivity.
• Related parties: shared services, group IT functions, offshore captives and intra-group hosting.
• Third parties: outsourced IT, managed security providers, cloud hyperscalers, payment processors, administrators, and fourth parties (a provider's own subcontractors) where material.
• Threat and vulnerability context: the threat landscape relevant to the entity's role in the financial system informs how 'commensurate' is judged.
• Regulatory overlap: CPS 234 sits alongside CPS 230 (Operational Risk Management), CPS 231/CPS 232 (outsourcing/BCM legacy), and the CPG 234 guidance; scope should note these interfaces.

In practice, scoping decisions must be documented and traceable. An assessor should expect to see a scoping paper that names each in-scope legal entity, states the basis of application (Level 1, 2 or 3), lists the material information assets and their classifications, enumerates the related parties and third parties whose controls are relied upon, and records the threat context that justifies the level of capability. Where an entity relies heavily on a group service company or an offshore captive, the assessor should confirm that those related-party arrangements have been assessed with the same rigour as external vendors, because CPS 234 draws no softer line for intra-group providers. Similarly, cloud usage requires an explicit shared-responsibility analysis: the entity remains accountable for the security of its data and configuration even where the provider secures the underlying platform, and the assessor should test that the boundary of responsibility is understood and that provider-side controls are independently assured.

Implementation approach

A phased implementation moves an entity from initial gap analysis to sustained, tested compliance. Each phase below lists indicative activities and deliverables.

The programme should be governed as a formal change initiative with Board or committee sponsorship, a named senior owner, and clear milestones tied to the remediation roadmap produced in Phase 1. The phases below can overlap and iterate; in most organisations asset classification (Phase 2) and control remediation (Phase 3) run in parallel once priorities are known, and third-party assurance (Phase 4) is a continuous, ongoing discipline rather than a one-off project stream. Crucially, testing and independent assurance (Phase 6) is not a closing gate but a permanent capability that feeds back into every earlier phase, so the implementation should be designed as a continuous-improvement loop from the outset.

Phase 1 - Governance and gap analysis (weeks 1-6)

• Activities: confirm Board accountability, stand up or refresh the security governance committee, perform a CPS 234 / CPG 234 gap assessment, establish the proportionality rationale.
• Deliverables: Board-endorsed CPS 234 programme charter, roles and responsibilities RACI, gap assessment report, prioritised remediation roadmap.

Phase 2 - Asset identification and classification (weeks 4-12)

• Activities: build/refresh the information asset register including third-party-managed assets, define and apply a classification scheme, complete business impact assessments.
• Deliverables: information asset register, data classification policy and scheme, criticality/sensitivity ratings, third-party asset inventory.

Phase 3 - Policy framework and controls (weeks 8-20)

• Activities: build the policy hierarchy, define control baselines by classification, remediate priority control gaps (MFA, patching, logging, segmentation, backups), embed secure SDLC and change control.
• Deliverables: approved information security policy framework, control baselines, remediated key controls, secure development and change standards.

Phase 4 - Third-party assurance (weeks 12-24)

• Activities: assess related-party and third-party controls, obtain independent assurance (SOC 2 / ISO 27001), embed security schedules and right-to-audit into contracts, map shared responsibility.
• Deliverables: vendor risk assessments, contractual security schedules, provider assurance evidence library, fourth-party register.

Phase 5 - Incident management and notification (weeks 16-26)

• Activities: build/refresh incident response plans and playbooks, define materiality criteria and the APRA notification process, run a tabletop exercise covering the 72-hour clock.
• Deliverables: incident response plan, playbooks, materiality framework, APRA notification procedure, tabletop exercise report.

Phase 6 - Testing and independent assurance (weeks 20-32 and ongoing)

• Activities: stand up the systematic control-testing programme, engage independent skilled testers, task internal audit with reviewing control effectiveness and the testing programme itself.
• Deliverables: testing strategy and calendar, penetration/red-team reports, findings register, internal audit assurance report, continuous improvement cycle.

Maturity and capability model

CPS 234 does not mandate a maturity model, but supervisors expect entities to demonstrate improving capability. The following five-level model (aligned to common CMMI-style scales and APRA's better-practice expectations in CPG 234) provides a benchmark for self-assessment and independent review.

When using this model, assessors should rate each of the nine CPS 234 domains independently rather than assigning a single overall score, because entities frequently show uneven maturity, for example strong technical controls but weak third-party assurance, or excellent asset classification but untested incident-response plans. Level 3 (Defined) represents the threshold of baseline compliance for most entities; anything below Level 3 in a material domain should be treated as a compliance gap requiring remediation, not merely an improvement opportunity. The proportionality principle means a smaller entity may legitimately sit at Level 3 across the board and be fully compliant, whereas a systemically important institution facing a heightened threat profile would be expected to demonstrate Level 4 or 5 in its most critical domains. The model is therefore a benchmark for judgement, not an automatic pass or fail mechanism.

Assessment and audit approach

An independent CPS 234 assessment should follow a disciplined, evidence-driven sequence.

The assessment should combine documentation review, control walkthroughs, technical validation and interviews across the three lines of defence. Documentary evidence alone is insufficient; an auditor should corroborate that documented controls operate as described by inspecting live configurations (for example MFA enforcement, logging pipelines, patch status and backup restore tests) and by tracing sample incidents and vulnerabilities through the entity's actual processes. Independence and skill of the entity's own control testers should be scrutinised carefully, as this is one of the most commonly deficient areas. Findings should be risk-rated, mapped to the specific CPS 234 clause they relate to, and reported in a form the Board and Audit Committee can act upon, with a clear distinction between compliance breaches and better-practice recommendations.

1. Confirm scope and proportionality: identify all regulated entities, information assets, related parties and third parties, and document the threat-based proportionality rationale.
2. Review governance: examine Board accountability, roles and responsibilities, and the security governance operating model against clauses 13-14.
3. Assess the policy framework and asset classification: test coverage, approval, currency and communication (clauses 18-22).
4. Evaluate control implementation: sample controls against classification-driven baselines across the lifecycle and across third parties (clauses 23-26).
5. Test incident management: review plans, playbooks, annual testing evidence and escalation (clauses 27-30).
6. Examine the control-testing programme: assess systematic coverage, proportionate frequency, tester skill and independence, and remediation (clauses 31-34).
7. Review independent assurance: confirm internal audit reviews control effectiveness and assures the testing programme (clauses 35-36).
8. Validate notification readiness: test the 72-hour incident and 10-business-day control-weakness notification processes and materiality criteria (clauses 36-40).
9. Rate and report: assign conformance ratings, document gaps with risk ratings, and produce a prioritised remediation plan with Board-level reporting.

Evidence request list

The following categorised evidence list supports a full CPS 234 assessment. Request the current, approved and dated versions of each artefact.

• Governance: Board charter and minutes, security governance committee ToR and minutes, RACI, delegations, three-lines-of-defence model.
• Strategy and capability: information security strategy, capability roadmap, budget/resourcing, threat assessments, org chart.
• Policy: information security policy framework, supporting standards and procedures, exception/waiver register, acknowledgement records.
• Assets: information asset register/CMDB, data classification scheme and policy, business impact assessments, PII/PHI inventory.
• Controls: control baselines, security architecture, hardening standards, MFA and access records, patch/vulnerability metrics, backup and recovery configs, secure SDLC and change records.
• Third parties: vendor risk assessments, SOC 2/ISO 27001 reports, contractual security schedules, right-to-audit records, fourth-party register, shared responsibility matrices.
• Incident management: incident response plan, playbooks, incident register, tabletop and exercise reports, post-incident reviews.
• Testing: testing strategy and calendar, penetration/red-team reports, tester credentials and independence attestations, findings and remediation register.
• Assurance: internal audit plan and reports, audit committee minutes, assessment of the testing programme.
• Notification: APRA notification procedures, materiality framework, evidence of any past notifications, decision logs.

Roles and responsibilities

KPIs to track

• Percentage of information assets classified and with an assigned owner.
• Mean time to detect (MTTD) and mean time to respond (MTTR) to security incidents.
• Vulnerability remediation within SLA by severity (critical/high/medium).
• Patch compliance rate across critical systems.
• MFA coverage across privileged and remote access.
• Percentage of material third parties with current independent assurance (SOC 2 / ISO 27001).
• Control-testing coverage of critical assets against the annual plan.
• Number and ageing of open security findings from testing and internal audit.
• Annual incident-response exercise completion and action closure rate.
• APRA notification timeliness: incidents notified within 72 hours; control weaknesses within 10 business days.
• Security awareness training completion and phishing simulation failure rate.
• Board reporting cadence and coverage of information security metrics.

Readiness checklist

• Board accountability for information security is documented and evidenced in minutes.
• Roles and responsibilities are defined across governance bodies and individuals (RACI).
• An information asset register exists, including third-party-managed assets, with criticality and sensitivity classifications.
• An approved, current information security policy framework provides direction to all obligated parties.
• Control baselines are defined by classification and implemented across the asset lifecycle.
• MFA, patching, logging, segmentation and backup controls are implemented and monitored.
• Related-party and third-party security is assessed with independent assurance obtained.
• Contracts include security schedules and right-to-audit clauses.
• Incident response plans and playbooks exist and are tested at least annually.
• Materiality criteria and the APRA notification process (72 hours / 10 business days) are defined and understood.
• A systematic, risk-based control-testing programme uses appropriately skilled and independent testers.
• Internal audit reviews control effectiveness and assures the testing programme.
• Findings from testing and audit are tracked to closure with risk-based prioritisation.
• Board and committees receive regular, meaningful information security reporting.

Common gaps

• Treating CPS 234 as an IT-only obligation and failing to evidence genuine Board accountability.
• Incomplete information asset registers that omit SaaS and third-party-hosted assets.
• Classification schemes that exist on paper but do not drive control selection.
• Weak third-party assurance: relying on vendor questionnaires without independent SOC 2 / ISO 27001 evidence or right-to-audit.
• Incident response plans that are never tested, or tabletop exercises that ignore the APRA notification clock.
• No defined materiality criteria, leaving responders unable to decide whether the 72-hour or 10-business-day notification applies.
• Control testing performed by the same team that owns the controls, breaching the independence requirement.
• Ad hoc rather than systematic, risk-based testing that ignores rate of change and criticality.
• Internal audit not covering third-party controls or not assuring the testing programme itself.
• Failing to reassess capability and testing sufficiency after material environmental or threat changes.
• Not documenting the proportionality rationale, so 'commensurate' decisions cannot be defended to APRA.

APRA CPS 234 mapped to other frameworks

CPS 234 is outcomes-based and maps readily onto established control catalogues, which entities often use to operationalise it. The table shows indicative alignment; it is not a formal crosswalk.

How CyberSigma helps

Frequently asked questions

Need help with APRA CPS 234?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.