APRA CPS 234 makes the Board accountable for information security, and it expects evidence that the controls actually work. For financial services firms, that shifts the question from whether policies exist to whether they hold up when tested. What follows is a practical read of the standard’s testing requirement, the part most checklists skip over.
Most CPS 234 content stops at governance and policy. The harder work is the systematic testing program itself: what gets tested, how the program runs, how you choose a tester, and where firms come unstuck. That is the ground this article covers.
These obligations bite hardest for regulated financial and professional firms, where client trust and record-keeping sit under constant supervision. SIAX supports these environments through its work with Financial & Professional Services, where security is built into daily support rather than added afterwards.
What APRA CPS 234 Actually Requires (and Who It Binds)
CPS 234 is a prudential standard, in force since 1 July 2019, that makes the Board ultimately responsible for an entity’s information security. It binds the full range of APRA regulated entities:
- Banks and other ADIs
- General and life insurers
- Private health insurers
- RSE licensees that run super funds
Its reach extends to information assets managed by related parties and third parties, as the CPS 234 standard makes clear.
The standard asks for more than controls on paper. CPS 234 information security obligations require entities to implement controls and to undertake systematic testing and assurance of how well those controls actually work. That testing duty sits alongside the broader framework choices financial firms weigh, which we compare in ISO 27001 vs Essential Eight for Financial Services.
The Testing Requirement, Read Properly
Testing means planned and repeatable, not annual and rote. A systematic testing program means planned, repeatable testing aligned to risk. It is not a single exercise booked once a year to satisfy an auditor.
Read the outcome, not the label. The standard itself does not name penetration testing. It describes an outcome: evidence that controls work, tested at a scope and frequency that reflect the risk involved. Penetration testing is widely used to produce that evidence, which is why penetration testing requirements sit at the centre of CPS 234 conversations.
Material change resets the clock. Frequency should follow risk, not the calendar. Annual testing is a sensible baseline, but material changes should trigger more, such as a new customer-facing application, a cloud migration, or a significant change to your architecture. APRA’s CPG 234 guidance sets out how entities are expected to judge whether their testing remains sufficient.
Independence isn’t optional. The standard also expects testing by functionally independent, appropriately skilled specialists. Internal-only testing can struggle to meet that bar, because the people who build and run a control are rarely best placed to prove it fails. That points towards independent, evidence-producing Penetration Testing carried out by a party with no stake in the result.
What Gets Tested Under CPS 234
Scope should follow the critical information assets, the systems that store or process sensitive financial and customer data. Testing an arbitrary boundary wastes effort and leaves real exposure untouched.
- Applications and systems that handle sensitive financial data
- Internet-facing infrastructure and the network perimeter
- Cloud environments, including Microsoft 365, Azure, and equivalents
- Identity and access systems, including privilege escalation and multi-factor authentication (MFA) paths
- Third-party and related-party connections your entity relies on
- Incident detection and response mechanisms
A vulnerability scan and a test are not the same thing. A scan lists known weaknesses, while a test proves whether your controls actually stop a realistic attack. Point-in-time testing works best alongside the continuous monitoring and vulnerability review that sit within managed Cyber Security.
How to Choose a Penetration Testing Partner
The value of a test depends on who runs it. Choosing a provider for penetration testing Australia-wide is a decision about competence, independence, and whether the findings will actually help you act.
- Recognised tester certifications, such as CREST or OSCP, as a baseline of competence
- Genuine experience in financial services and other regulated environments
- Familiarity with APRA reporting expectations and the CPS 234 attestation context
- Functional independence from the teams that build and run your controls
- Clear, prioritised, board-readable reporting
- A defined remediation and re-test path, not only a list of findings
Good testing puts real pressure on the environment and leaves you with something to act on. That is the standard SIAX brings to this work: findings that show where security stops holding up, and clear priorities for what to fix first.
Common Pitfalls That Undermine CPS 234 Testing
Checkbox compliance looks fine until something tests it, whether that is APRA, an auditor, or an actual incident. Most gaps in APRA CPS 234 compliance are not exotic. They are predictable, and they repeat.
- Treating a vulnerability scan as evidence that controls work
- Running a fixed annual cycle that ignores mid-year material changes
- Scoping too narrowly, leaving critical assets or third-party connections untested
- Tracking remediation informally, with no re-test to confirm the fix
- Reporting a headline finding count to the Board without residual risk or the status of open findings
The implication is uncomfortable. An unremediated material weakness found through testing can, in some cases, be a matter the entity must report to APRA, a duty the APRA Prudential Handbook sets out, so testing without disciplined remediation can create exposure rather than close it.
Change should also reshape what and when you test, as we explain in Essential Eight and Cloud Migration Architecture: How Maturity Targets Should Shape the Move.
Building a CPS 234 Testing Program You Can Defend
Good looks like a systematic, risk-based testing program: independent testers, disciplined remediation, and board reporting that reflects real residual risk. The next step is to define which information assets are critical, where current testing falls short, and how the program will respond to change.
That is a decision worth getting right before your next material change or supervisory review. SIAX can help review your current testing approach and map the program CPS 234 requires through its Governance, Risk & Compliance service.
Frequently Asked Questions
What does APRA CPS 234 compliance require for security testing?
APRA CPS 234 compliance requires a systematic testing program proportionate to risk, carried out by functionally independent specialists, with the program’s sufficiency reviewed at least annually or whenever a material change occurs.
Does CPS 234 make penetration testing mandatory in Australia?
Not by name. CPS 234 does not mandate penetration testing, but it is the method most APRA regulated entities use to evidence control effectiveness. Independence and risk-based frequency matter more than the label.
How often should penetration testing be carried out under CPS 234?
Treat annual testing as a baseline. Add testing after material changes such as new applications, cloud migrations, or architecture changes. Frequency is risk-based rather than a fixed annual number.
What are the penetration testing requirements for third-party systems?
CPS 234 information security obligations extend to information assets managed by related and third parties. Entities must assess whether that testing is commensurate with their own, rather than assume a third party has it covered.
