APRA CPS 234
information security standard for APRA-regulated entities
Prudential Standard CPS 234 obligates APRA-regulated entities to maintain information security capability commensurate with the size and extent of threats, identify and classify information assets, implement controls (including against third-party-managed assets), and notify APRA of material information security incidents within 72 hours. This page covers the structure of CPS 234, the obligations under each section, the evidence APRA expects, and how a workspace records it.
No credit card required. Free plan available forever.
CPS 234 in context: APRA prudential standard for information security
Prudential Standard CPS 234 has applied since 1 July 2019 and sets the information security obligations for APRA-regulated entities operating in Australia. APRA published Prudential Practice Guide CPG 234 alongside the standard to describe the practices APRA considers prudent for meeting CPS 234. The standard is principles-based, deliberately so: it does not prescribe a control catalogue. It obligates the entity to maintain a capability and controls commensurate with the threats and the asset profile, and to evidence that commensurate position to APRA on request.
CPS 234 sits alongside other Australian frameworks SecPortal already covers, including the ACSC Essential Eight, which APRA-regulated entities frequently treat as a reference baseline for technical controls under paragraphs 20 to 22. For the wider financial-sector picture, the SWIFT Customer Security Programme sets controls for the SWIFT-related infrastructure that many APRA-regulated entities operate, and the ISO 27001 information security management system often sits above CPS 234 at the entity level. For Asian regional comparators, the HKMA Cyber Resilience Assessment Framework sets the equivalent supervisor-led expectation for Authorised Institutions in Hong Kong, with iCAST as its intelligence-led testing pillar, and the MAS Technology Risk Management Guidelines carry the equivalent obligation in Singapore. CPS 234 is its own standard with its own obligations; the related frameworks supply control catalogues and assurance models that the entity can use as evidence rather than as a substitute for CPS 234 itself.
In-scope entities: who CPS 234 applies to
CPS 234 applies to APRA-regulated entities. The standard names the population in paragraphs 5 to 7, and the obligations apply at the regulated entity level, with consolidated obligations for authorised non-operating holding companies. The summary below is the working categorisation; the standard text is the authoritative reference for any scope question.
Authorised deposit-taking institutions (ADIs)
Banks, building societies, and credit unions authorised by APRA to take deposits. CPS 234 applies in full, with the obligations weighted to the criticality of the customer-facing systems and the payment infrastructure. Foreign ADIs operating in Australia are in scope for their Australian operations.
General insurers, life insurers, and private health insurers
Insurance entities licensed under the Insurance Act, the Life Insurance Act, and the Private Health Insurance (Prudential Supervision) Act. Policyholder data, claims systems, and premium platforms typically anchor the highest criticality classifications under CPS 234.
Registrable superannuation entities (RSE) and RSE licensees
Superannuation funds and the trustee licensees that operate them. Member data, contribution platforms, investment management systems, and the administrator relationships sit inside the asset register that CPS 234 obligates the trustee to maintain and assess.
Authorised non-operating holding companies
Holding companies authorised by APRA at the group level, which carry CPS 234 responsibilities at the consolidated entity level for the information security capability that supports the regulated subsidiaries.
The four working pillars of CPS 234
CPS 234 is structured as a single set of obligations, but a working read groups the obligations into four pillars: capability, framework and assets, controls, and incident-and-testing. The pillars below are the way many regulated entities organise the evidence pack so the audit trail follows the structure of the standard rather than the structure of the entity.
Pillar 1: capability commensurate with threats and assets
Information security capability (paragraph 15) is people, processes, and technology together. The board must satisfy itself that capability matches the size and extent of threats and the criticality and sensitivity of the assets. Capability evidence is staffing levels with named accountability, the budget allocation, the expertise model (in-house, outsourced, hybrid), and the operating model the entity actually runs to. APRA examines capability against the threat picture for the regulated entity, not against a generic baseline.
Pillar 2: information security policy framework and asset classification
A documented framework (paragraph 16) covering roles, classification, controls, incident management, third-party management, and testing. Information assets (paragraph 17) are identified and classified by criticality and sensitivity, with the classification driving the controls applied to each asset. The asset register is a working document that is reviewed when the entity changes shape, when new asset classes appear, and at scheduled intervals.
Pillar 3: implementation of controls including third-party-managed assets
Controls (paragraphs 20 to 22) implemented commensurate with the vulnerabilities, threats, criticality, sensitivity, lifecycle stage, and potential consequences. Third-party-managed assets (paragraphs 18 and 19) carry the same obligation: the entity must assess the information security capability of any related party or third party that manages information assets. APRA holds the entity accountable for the security of assets it does not directly operate.
Pillar 4: incident management, systematic testing, and notification
Incident management (paragraph 23), the systematic testing program (paragraph 28), internal audit coverage (paragraphs 33 and 34), the 72-hour APRA notification on material incidents (paragraph 35), and the 10-business-day notification on material control weaknesses the entity cannot remediate in time (paragraph 36). These obligations operate continuously across the year rather than at audit time only.
Paragraph 28: the systematic testing programme
Paragraph 28 is the operational heart of CPS 234 for many regulated entities. The standard does not prescribe a testing methodology; it requires the testing programme to be commensurate with five named factors. The factors below are the structural variables an entity weighs when deciding what to test, how often, and to what depth. Penetration testing, vulnerability scanning, configuration assessment, and red team exercises all contribute to the programme; the discipline is matching method, cadence, and depth to the asset class rather than running a uniform programme everywhere.
- The rate at which vulnerabilities and threats change for the asset class (web-facing systems usually demand a higher cadence than internal back-office systems)
- The criticality and sensitivity of the information assets the controls protect (customer payment systems usually demand a higher cadence than internal collaboration tools)
- The potential consequences of an information security incident affecting the asset class (consequences for depositors, policyholders, members, or beneficiaries)
- The risks associated with exposure to environments where the entity is unable to enforce controls (cloud platforms, third-party-managed environments, partner integrations)
- The materiality and frequency of change to assets (a system under heavy active development demands more frequent testing than a stable system in maintenance mode)
For the workflow that turns systematic testing into auditable evidence, the penetration testing workflow keeps engagement, findings, and remediation tied to a single record. The scanner result triage workflow covers turning raw scanner output into assessor-ready findings without losing the audit trail. For the analytical view of how testing cadence interacts with finding age, the aging pentest findings research covers why a paragraph 28 testing programme without a remediation cadence drifts into a backlog the auditor will read as a control weakness.
Paragraphs 18 and 19: third-party-managed information assets
Where an information asset is managed by a related party or a third party, the regulated entity must assess the information security capability of that party. The obligation does not transfer to the third party. APRA holds the entity accountable for the security of every asset in its register, including assets the entity does not directly operate. The third-party assessment is the artefact that closes the loop between the asset register and the controls actually applied to the asset.
- Identify the third party in the information asset register, with the assets the third party manages, the criticality and sensitivity classification, and the contractual basis of the relationship
- Document the entity capability assessment of the third party, covering the third-party policy framework, control implementation, incident response, testing programme, and assurance evidence the third party provides (SOC 2 reports, ISO 27001 certifications, penetration test summaries, internal audit reports)
- Capture the gaps the assessment identifies (controls the third party does not implement, evidence the third party will not share, residual risks the entity must absorb), with the rationale for accepting or remediating each gap
- Tie the third-party assessment to the entity-side controls that compensate for residual risk (additional monitoring, contractual remediation rights, exit planning, alternate provider analysis)
- Refresh the assessment on a documented cadence and on material change in the third-party relationship (control failures, contract amendments, sub-processor introductions, certification lapses)
- Maintain the assessment record in a workspace that the auditor can examine, the board can review, and APRA can request without reconstruction from email and shared drives
Paragraph 35: APRA notification within 72 hours
Paragraph 35 sets the strictest timing obligation in CPS 234. The entity must notify APRA 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. The 72-hour clock starts at awareness, which is structurally tighter than regimes that start the clock at materiality determination. The implication is that the materiality assessment must run inside the 72-hour window, not as a precondition to starting it.
Paragraph 36 sets a parallel obligation for material control weaknesses the entity expects it will not be able to remediate in a timely manner: notification to APRA as soon as possible and within 10 business days. The 10-business-day clock makes control weakness notification a workflow obligation rather than an annual review item. The defensible position is a workspace that surfaces material control weaknesses through the findings triage cycle and a documented decision rule for when a weakness crosses the paragraph 36 threshold.
For the underlying triage discipline, the scanner false positives guide covers how to validate findings before they leave the draft state, which prevents paragraph 36 notifications based on unverified output. For the severity scoring discipline, the severity calibration research covers how to anchor scores to verified evidence so a paragraph 36 threshold call is grounded rather than improvised.
The evidence pack: what APRA and the auditor will look for
APRA conducts thematic reviews and entity-level examinations against CPS 234. The auditor community supplies the assurance work the entity relies on. The artefacts below are the working set that recurs across reviews and examinations. The exact list varies with entity size, asset profile, and any control weaknesses the entity has previously notified under paragraph 36, but this is the core that recurs.
- Information asset register with classification, criticality, sensitivity, owner, and the controls applied per asset class, refreshed on a documented cadence
- Third-party register with the assessment of each related-party and third-party that manages information assets, including the assurance evidence the third party provides and the gaps the entity has identified
- Information security policy framework versioned and dated, with the constituent policies (access management, change management, vulnerability management, incident management) tied to the controls they operationalise
- Capability assessment showing how staffing, budget, expertise, and operating model match the threat profile and asset criticality, with the next review date and the trigger conditions for an out-of-cycle refresh
- Systematic testing programme schedule for the year, with vulnerability scans, penetration tests, configuration reviews, and red team exercises mapped to asset classes and frequencies that match the paragraph 28 factors
- Penetration test reports with findings, severity, remediation plans, and retest evidence per finding, attached to the asset register entries the testing covered
- Vulnerability scan output across the asset register, with findings tied to the relevant assets, severity, remediation owners, and SLA progress
- Incident register with detection time, response actions, materiality determination time, APRA notification time (where paragraph 35 applies), post-incident review, and the lessons learned the entity has applied
- Tabletop exercise records demonstrating the incident response plan has been reviewed and tested at least annually, with the gaps the exercise surfaced and the closure of those gaps tracked over time
- Internal audit reports covering design and operating effectiveness of information security controls, including third-party-managed assets, with the reliance basis on third-party assurance documented per audit
- Board reporting record showing the cadence and content of information security updates to the board, with the escalation path operating before an incident rather than assembled during one
Vulnerability scanning evidence and penetration test findings are usually the highest volume artefacts in the pack. The remediation tracking workflow keeps finding ownership, target dates, and verification evidence on the same record so the auditor can walk from a control gap to the closure that resolved it. The pentest evidence management workflow keeps the artefacts attached to the engagement so the audit trail walks back to the primary source.
How SecPortal aligns to a CPS 234 testing programme
SecPortal is built for security service providers and internal security teams running regulated assessment cycles. CPS 234 fits the platform model directly: the asset register and the third-party register drive the testing programme, the assessor or pentester walks the controls on the workspace, the evidence pack lives on the finding and engagement records, and the board reporting reflects what the workspace already says.
- Engagement management dedicated to a CPS 234 testing programme, with the in-scope asset class, the testing cadence, and the assessor or pentester record on a single workspace
- Findings management with CVSS 3.1 scoring, 300+ templates, and explicit mapping of vulnerability and assessor findings to the relevant CPS 234 paragraph and asset register entry
- Compliance tracking that maps CPS 234 paragraphs to controls, asset classifications, and the evidence pack alongside the internal audit cycle
- AI report generation that turns control assessment notes, deviations, and remediation plans into the audit-ready report and the board-ready narrative without manual rewriting
- External and authenticated scanning to feed paragraph 28 systematic testing for the in-scope assets, with scheduled scans across the year rather than a single audit-time snapshot
- Continuous monitoring with scheduled scans so the asset register carries a coverage record that the auditor and APRA can examine across the year
- Findings audit trail with reasons and re-evaluation dates so suppressions, deviations, and risk acceptances are defensible at internal audit, at board review, and at APRA examination
Practical sequencing: how to run a CPS 234 cycle without scrambling at audit
CPS 234 obligations operate continuously across the year. The pattern that breaks the scramble is sequencing the work against the asset class rather than against the audit date. The cadence below is the working pattern many regulated entities run; the actual cadence depends on the asset profile and the threat picture the entity faces.
- Q1: refresh the information asset register, refresh the third-party register, and refresh the capability assessment against the threat picture for the year ahead
- Q1 to Q2: run the high-criticality penetration tests, refresh the third-party capability assessments for the most material relationships, and run the first tabletop exercise against the incident response runbook
- Q2 to Q3: rotate through the medium-criticality testing, address the outstanding remediation items from the Q1 round, and run the internal audit walk on design and operating effectiveness for the controls audited this cycle
- Q3 to Q4: run the second tabletop exercise, refresh the policy framework for any control or threat changes the year surfaced, and prepare the board reporting pack with the year-on-year capability and testing evidence
- Year-round: incident response readiness, paragraph 35 notification readiness, and paragraph 36 control weakness review cadence so the obligations operate as workflow rather than as audit-time reconstruction
Common control weakness patterns and how to record them
Most entities carry a small number of control weaknesses across the cycle, especially after a control change, an asset acquisition, or a third-party migration. The defensible position is not zero weaknesses; it is documented weaknesses with a rationale, a compensating control, an owner, a remediation plan, and the paragraph 36 evaluation. The pattern below is what the auditor and APRA read as a mature programme rather than as a gap.
- Weakness reason recorded on the control: the structural reason the control is not implemented as written, in plain language rather than in auditor jargon
- Compensating control identified and tied to the weakness, with the evidence the compensating control is implemented and operating
- Risk acceptance signed by the accountable owner, with the date and the duration bounded against the next cycle or the remediation deadline
- Paragraph 36 evaluation: whether the weakness is material, whether the entity expects to remediate in a timely manner, and the notification decision with rationale
- Remediation plan attached to the weakness with owners, deadlines, and the explicit retest condition that closes the weakness when met
Scope and limitations
CPS 234 is the prudential standard operated by APRA and applied by the regulated entity. SecPortal is the workspace that holds the engagement, the asset and third-party registers, the controls evidence, and the audit trail. Notification to APRA under paragraphs 35 and 36 remains an action the entity takes through the APRA-prescribed channel; SecPortal holds the supporting record so the notification is grounded in the evidence pack rather than reconstructed from email and shared drives at the awareness moment.
CPS 234 is principles-based and does not prescribe a control catalogue. This page describes the structure of the standard and how a workspace-driven cycle plays against it; the authoritative reference for the obligations remains the APRA-published Prudential Standard CPS 234 and the accompanying Prudential Practice Guide CPG 234. The control catalogue an entity selects to meet CPS 234 is the entitys own decision, evidenced through the asset register, the capability assessment, and the testing programme.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Paragraph 13: roles and responsibilities of the board
The board of an APRA-regulated entity is ultimately responsible for the information security of the entity. CPS 234 names the board explicitly, which means board minutes, charter references, and the reporting cadence to the board are part of the evidence pack rather than a side document. The accountable individual or committee for information security must be documented and the escalation path to the board must operate before an incident, not be assembled during one.
Paragraph 15: information security capability
The entity must maintain an information security capability commensurate with the size and extent of threats, and the criticality and sensitivity of the information assets. Capability is people, processes, and technology together. APRA examines whether the staffing, the budget, the expertise, and the operating model match the threat profile of the entity rather than match a generic baseline. The capability assessment is its own artefact, refreshed when the threat picture changes.
Paragraph 16: information security policy framework
The entity must maintain an information security policy framework commensurate with its exposures, articulated in language that drives decisions rather than documents intent. The framework covers roles, classification, controls, incident management, third-party management, and testing. Each constituent policy is reviewable, dated, and tied to the controls that operationalise it.
Paragraphs 17 to 19: information assets and third-party-managed assets
Information assets must be identified and classified by their criticality and sensitivity. Where an information asset is managed by a related party or third party, the entity must assess the information security capability of that party. The third-party assessment carries the same severity as an internal control review: the entity remains accountable to APRA for assets it does not directly operate, and the evidence pack must demonstrate the third-party security posture is understood.
Paragraphs 20 to 22: implementation of controls
Controls must be implemented commensurate with the vulnerabilities and threats to the information assets, the criticality and sensitivity of the assets, the stage at which the assets sit in their lifecycle, and the potential consequences of an information security incident. The same control catalogue is unlikely to suit every asset class. The evidence must show that control selection followed a documented assessment rather than a defaulted baseline.
Paragraph 23: incident management
The entity must have robust mechanisms in place to detect and respond to information security incidents in a timely manner, including plans to respond to incidents that the entity considers could plausibly occur. The plans must be reviewed and tested at least annually. Tabletop exercise records, the runbook version history, and the post-incident review record are all part of what APRA looks for at examination.
Paragraph 28: systematic testing of controls
The entity must test the effectiveness of its information security controls through a systematic testing program. The nature and frequency of testing must be commensurate with the rate at which vulnerabilities and threats change, the criticality and sensitivity of the assets, the consequences of an incident, the risks associated with exposure to environments where the entity is unable to enforce controls, and the materiality and frequency of change to assets. Penetration testing, vulnerability scanning, and configuration assessment evidence sit at the centre of this obligation.
Paragraphs 33 and 34: internal audit
The internal audit activities of the entity must include a review of the design and operating effectiveness of the information security controls, including those maintained by related parties and third parties. Where internal audit relies on the work of others (such as third-party assessors or external auditors), the reliance basis must be documented. The audit cycle is a recurring obligation, not a one-off review.
Paragraph 35: APRA notification within 72 hours
The entity must notify APRA 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 (whether in Australia or other jurisdictions). The 72-hour clock starts at awareness, not at materiality determination, which is structurally tighter than some peer regimes.
Paragraph 36: APRA notification of control weaknesses
The entity must notify APRA as soon as possible and no later than 10 business days after it becomes aware of a material information security control weakness that the entity expects it will not be able to remediate in a timely manner. The notification covers the weakness, the affected assets, the planned remediation, and the interim mitigations. The 10-business-day clock makes control weakness notification a workflow obligation, not an annual review item.
Run a CPS 234 testing programme on one defensible record
Hold the asset register, the third-party assessments, the systematic testing evidence, the incident record, and the APRA notification trail in one workspace. Start free.
No credit card required. Free plan available forever.