What is CPS 234 and Why It Matters for Australian Financial Institutions

If you run technology or risk at an APRA-regulated entity, CPS 234 is the standard that turns "we take security seriously" into something you have to prove. I have spent more than a decade doing security assessments for regulated organisations, and the pattern with prudential standards is always the same: the text looks short and reasonable, and then you sit down to demonstrate compliance and realise how much operational discipline it actually demands. CPS 234 is exactly that kind of document. This is a plain-English explanation of what it requires, why it exists, and how to build a program that will survive an APRA review and a real incident.

What CPS 234 actually is

CPS 234 is a Prudential Standard on Information Security issued by the Australian Prudential Regulation Authority (APRA). It became effective on 1 July 2019 and applies to APRA-regulated entities: authorised deposit-taking institutions (banks, credit unions, building societies), general and life insurers, private health insurers, and registrable superannuation entity (RSE) licensees. If APRA regulates you, CPS 234 is not optional and it is not guidance. It is an enforceable standard, and your board carries the accountability.

The core idea is simple to state and hard to live up to: an APRA-regulated entity must maintain information security capabilities commensurate with the size and extent of the threats to its information assets, and it must be able to respond to and recover from information security incidents. The standard is deliberately outcome-focused rather than a checklist of specific technologies, because APRA does not want to freeze you into controls that are obsolete in three years. That flexibility is a gift and a trap: it means you cannot buy a product and declare victory. You have to demonstrate that your controls are appropriate for your actual risk.

The six obligations at the heart of the standard

CPS 234 is built around a small set of obligations. Everything else is detail hanging off these.

• Board accountability. The board of the regulated entity is ultimately responsible for information security. This is not something you can delegate away to IT and forget. The board must ensure the entity maintains information security in a manner commensurate with the threats.
• Clear roles and responsibilities. The entity must clearly define the information security roles and responsibilities of the board, senior management, governing bodies, and individuals.
• Information security capability. You must maintain a security capability commensurate with the size and extent of threats, and appropriate to the criticality and sensitivity of the information assets you hold. Critically, this obligation extends to information assets managed by third parties.
• Policy framework. You must maintain an information security policy framework commensurate with your exposures and vulnerabilities.
• Controls and testing. You must implement controls to protect information assets, and you must test the effectiveness of those controls through a systematic testing program. The nature and frequency of testing must reflect the rate of change of the asset and the consequences of a control failure.
• Incident management and notification. You must have robust mechanisms to detect and respond to incidents, and you must notify APRA. This is where the hard deadlines live, and I will come back to them.

The two notification deadlines you cannot miss

Most of CPS 234 is about maintaining capability over time. The notification obligations, by contrast, are specific and time-bound, and they are the part regulated entities most often get caught out on.

• 72 hours for material incidents. You must notify APRA no later than 72 hours after becoming aware of an information security incident that materially affected, or had the potential to materially affect, the entity or the interests of depositors, policyholders, beneficiaries, or other customers. It also covers incidents that have been notified to another regulator, whether inside or outside Australia.
• 10 business days for material control weaknesses. You must notify APRA no later than 10 business days after becoming aware of a material information security control weakness that you expect you will not be able to remediate in a timely manner.

The practical implication is that your incident response process has to be able to make a materiality judgement quickly and route it to whoever files the APRA notification. I have seen organisations with technically excellent detection who still would have blown the 72-hour window because nobody owned the decision to notify. Build that decision path before you need it.

Why CPS 234 exists and why it matters

APRA introduced CPS 234 because the financial system runs on trust and on data, and the threat environment against that data had outgrown the older, more general risk-management standards. Financial institutions are high-value targets: they hold money, they hold identity data, and they sit at the centre of interconnected supply chains. A single compromised managed service provider can expose dozens of downstream institutions. The standard responds to that reality by forcing entities to own their security posture end to end, including the parts they have outsourced.

The reason it matters to you as an executive is not just avoiding regulatory attention, although that is real. It matters because CPS 234 codifies the exact disciplines that determine whether a breach is a contained, reportable event or an existential one. Entities that genuinely meet the standard detect faster, contain faster, and recover faster. The framing I sometimes hear, that compliance is a sales asset, is not wrong, but it is the wrong reason to do this. Do it because it makes you materially harder to breach and materially faster to recover. The commercial credibility follows from that, not the other way around.

How to build a CPS 234 program that holds up

Below is the sequence I use when helping a regulated entity move from "we think we are mostly compliant" to something that would survive an APRA tripartite review or a real incident. Treat it as a program, not a project. The standard explicitly expects ongoing capability, not a one-off certification.

1. Establish real governance, not a signature line

Start at the board. The board needs a genuine line of sight into information security risk: regular reporting, a named senior owner (commonly the CISO or equivalent), and documented roles that make it clear who does what. The failure mode I see most often is a governance structure that exists on paper but where the board receives no meaningful security reporting between annual audits. APRA will look for evidence that the board is actually engaged, so create the artefacts that prove it: minutes, risk reports, decisions on risk appetite.

• Name a board-level owner for information security risk.
• Define and document roles for the board, senior management, and security function.
• Set and record an information security risk appetite.
• Report security posture to the board on a regular cadence, not just after incidents.

2. Classify your information assets

You cannot protect assets commensurately with their sensitivity if you have never classified them. Build and maintain an inventory of information assets, including those held or processed by third parties, and rate them by criticality and sensitivity. This inventory is the backbone of everything else, because it tells you where to concentrate controls and testing. It is also the artefact assessors ask for first, and the one most entities cannot produce cleanly.

3. Assess risk and close the gaps

With the inventory in hand, run a structured risk assessment against your material assets, including the systems and vendors that touch them. Look for the boring, high-impact gaps: unpatched internet-facing systems, weak identity controls, over-broad administrative access, unmonitored third-party connections. Prioritise remediation by impact, not by how easy the fix is. Our IT security audit and vulnerability assessment services exist precisely to produce this kind of evidence-based gap picture, and it is the foundation for defensible control decisions.

4. Implement controls appropriate to the risk

CPS 234 does not prescribe a control set, which means you choose controls proportionate to your assessed risk. In practice, for almost every regulated entity that means strong identity and access management with multi-factor authentication, encryption of sensitive data in transit and at rest, disciplined patch and vulnerability management, network segmentation, logging and monitoring, and hardened endpoints. Map every control back to the risk it addresses, because at review time you will be asked to justify why your controls are commensurate. Many Australian entities also align to the ACSC Essential Eight as a practical control baseline that supports CPS 234 outcomes.

5. Test control effectiveness systematically

This is the obligation that separates real programs from paper ones. CPS 234 requires a systematic testing program whose frequency reflects how fast the asset changes and how bad a control failure would be. Testing means more than an annual vulnerability scan. It means penetration testing against your material systems, validation that controls actually work as designed, and internal audit of the security function itself. The standard also expects the testing program to be reviewed by suitably skilled and independent people. Independent penetration testing is the most credible evidence you can bring to an APRA conversation, because it demonstrates that controls were tested by someone with no incentive to declare them effective.

6. Build and rehearse incident response

Detection and response capability is a CPS 234 obligation, not a nice-to-have. Stand up monitoring that can actually surface a compromise, write an incident response plan that includes the materiality assessment and the APRA notification path, and then rehearse it. Run tabletop exercises that force the team to decide, under time pressure, whether an incident is materially reportable and who files within 72 hours. The first time your team works through that decision should not be during a live breach.

7. Manage third-party and supply-chain risk

CPS 234 explicitly extends to information assets managed by related parties and third parties, which is unusual and important. If a vendor holds or processes your material data, their control weaknesses are your regulatory exposure. Build vendor due diligence that asks for evidence, not assurances: their own testing results, their incident notification commitments, their control attestations. Bake information security obligations into contracts, and re-assess critical vendors on a schedule rather than once at onboarding.

Where CPS 234 sits alongside other frameworks

Regulated entities rarely deal with CPS 234 in isolation. Here is how it relates to the other standards you are likely juggling.

Framework	Who sets it	Nature	Relationship to CPS 234
CPS 234	APRA	Mandatory prudential standard for APRA-regulated entities	The baseline obligation for Australian financial institutions
ACSC Essential Eight	Australian Cyber Security Centre	Prioritised mitigation strategies (maturity model)	A practical control baseline that supports CPS 234 outcomes
ISO 27001	ISO/IEC	Certifiable information security management system standard	An ISMS that provides much of the policy and control structure CPS 234 expects
SOC 2	AICPA	Attestation report on service organisation controls	Useful for evidencing third-party controls in your supply chain
NIST SP 800-53	NIST (US)	Comprehensive control catalogue	A control library some entities map to for depth and rigour

If you want a deeper comparison, we have written specifically on CPS 234 versus NIST 800-53 and on the ACSC Essential Eight, both of which come up constantly in Australian financial services security programs.

The mistakes that cost regulated entities the most

Across assessments, the same failures recur. None of them are exotic. All of them are avoidable.

• Governance on paper only. A named owner who never reports to the board, and a board that never engages, will not survive scrutiny.
• No asset inventory. Without classified assets you cannot show controls are commensurate, and you cannot scope testing sensibly.
• Testing that is not systematic. One annual scan does not meet a standard that ties testing frequency to rate of change and consequence of failure.
• Ignoring third parties. Treating vendor security as the vendor's problem contradicts the plain text of CPS 234.
• No rehearsed notification path. Excellent detection is wasted if nobody owns the 72-hour materiality call.

Getting help without losing ownership

You can and should bring in external expertise for the parts that benefit from independence and specialised skill: gap assessment, penetration testing, and building the testing program. What you cannot outsource is accountability, because CPS 234 places it squarely on the board. The right engagement model gives you independent evidence and a defensible program while keeping ownership inside the entity. For institutions that lack a full-time security leader, a fintech-focused virtual CISO or broader virtual CISO engagement can carry the program day to day while your board retains oversight. If you would like an outside read on where you stand, get in touch and we can scope a CPS 234 gap assessment.

Frequently Asked Questions

Who does CPS 234 apply to?

CPS 234 applies to all APRA-regulated entities: authorised deposit-taking institutions such as banks and credit unions, general insurers, life insurers, private health insurers, and registrable superannuation entity licensees. If APRA regulates you, the standard applies, and compliance has been mandatory since it took effect on 1 July 2019.

What are the CPS 234 breach notification timeframes?

There are two. You must notify APRA within 72 hours of becoming aware of an information security incident that materially affected, or could have materially affected, the entity or its customers. Separately, you must notify APRA within 10 business days of becoming aware of a material information security control weakness that you do not expect to remediate in a timely manner.

Does CPS 234 cover outsourced and cloud systems?

Yes. The standard explicitly extends to information assets managed by related parties and third parties, including cloud and managed service providers. You remain accountable for the security of your material data even when a vendor holds or processes it, so third-party due diligence and contractual security obligations are part of compliance.

How is CPS 234 different from ISO 27001 or SOC 2?

CPS 234 is a mandatory prudential standard enforced by APRA, focused on outcomes and board accountability. ISO 27001 is a voluntary, certifiable management-system standard, and SOC 2 is a US attestation report on a service organisation's controls. ISO 27001 and SOC 2 can supply much of the policy structure and third-party evidence CPS 234 expects, but neither replaces the obligation to meet the standard itself.

How often do we need to test our controls under CPS 234?

The standard does not fix a single frequency. It requires a systematic testing program whose frequency reflects how quickly the asset changes and how serious a control failure would be. High-change, high-consequence systems need more frequent testing, typically including regular vulnerability assessment and periodic independent penetration testing, with reviews by suitably skilled and independent parties.

What happens if we do not comply with CPS 234?

As an enforceable prudential standard, non-compliance can attract regulatory action from APRA, including intensified supervision and formal enforcement. The larger practical risk is operational: an entity that has not built the required detection, response, and testing capability is far more likely to suffer a serious, poorly contained breach. The board carries the accountability in both cases.