Controls that have never been tested are assumptions, not assurance. CPS 234 recognises this directly, requiring APRA-regulated entities to test the effectiveness of their information security controls on an ongoing basis and to have that testing reviewed independently. Done well, this is the feedback loop that keeps a security program honest. Done poorly, it produces a binder of reports that nobody acts on.
What CPS 234 actually asks for
The standard requires a systematic testing program covering the effectiveness of information security controls. Importantly, CPS 234 does not prescribe a single test type or a fixed calendar. Instead, it sets the principle that the nature and frequency of testing must reflect:
- The rate at which vulnerabilities and threats change.
- The criticality and sensitivity of the information asset.
- The consequences of an information security control failing.
- The risks associated with the way the asset is managed, including by third parties.
This is a proportionality test, and it ties straight back to your information asset classification. A top-tier system holding sensitive member or policyholder data, exposed to a fast-moving threat landscape, demands more frequent and more rigorous testing than a low-criticality internal tool.
Building a systematic testing program
A systematic program means testing is planned, risk-driven and continuous, not a once-a-year penetration test bolted on to satisfy an auditor. A mature program typically blends several techniques, each answering a different question:
- Vulnerability assessment — frequent, broad scanning to find known weaknesses across the estate.
- Penetration testing — deeper, manual testing of high-value systems to see whether controls actually withstand a determined attacker.
- Control and configuration reviews — checking that controls such as access management, logging and backups are configured and operating as intended.
- Scenario and red-team exercises — for the most critical entities, testing detection and response against realistic attack chains.
Map each technique to your asset tiers and to a frequency that reflects risk. The output should be a documented, board-visible testing plan that shows what is tested, how often and why, so the program itself is defensible to APRA.
What independence really means
The independence requirement is where many programs fall short. CPS 234 expects testing to be conducted by appropriately skilled and functionally independent specialists. In plain terms, the people testing a control must not be the people who designed, built or run it. A team that grades its own homework provides comfort, not assurance.
Independence can be achieved in two ways. External specialists provide clear separation and fresh perspective, which is why they are commonly used for penetration testing of critical systems. Alternatively, a suitably skilled and organisationally separated internal function can test controls operated by other teams. What does not satisfy the standard is the operational team assessing the effectiveness of its own controls. Where third parties operate your controls, their own testing can contribute, but you remain responsible for ensuring it is sufficient and genuinely independent.
The role of internal audit
CPS 234 gives internal audit a specific and non-negotiable role. Internal audit must review the design and operating effectiveness of information security controls, including those maintained by third and related parties. Just as importantly, internal audit must assess the information security control testing program itself, evaluating whether its scope and frequency are appropriate and whether the results are reliable.
This creates a layered assurance model. The first layer is the operational testing program. The second is internal audit, independently checking both the controls and the program that tests them. Together they give the board confidence that what management reports about security effectiveness can be trusted. This structure aligns naturally with the assurance expectations of ISO 27001 and complements the maturity assessment approach behind the Essential Eight.
Testing third-party and related-party controls
CPS 234 explicitly extends testing and assurance to information assets managed by third and related parties. Outsourcing a control does not outsource the obligation to know it works. In practice this means:
- Securing contractual rights to test, or to receive evidence of independent testing, from critical vendors.
- Reviewing third-party assurance reports and certifications, and assessing whether their scope actually covers the controls you rely on.
- Folding vendor testing evidence into your overall program so gaps are visible.
This should sit within your broader vendor risk and due diligence process rather than being treated as a separate, occasional check.
From findings to action
Testing only adds value if findings drive change. Every test should feed a tracked remediation process with owners, priorities and deadlines tied to the criticality of the affected asset. Two further consequences matter under CPS 234. First, the board must receive meaningful reporting on testing results and the state of remediation, because the board is accountable for information security. Second, if testing uncovers a material control weakness that you expect you cannot remediate in a timely manner, you are obliged to notify APRA within 10 business days. Testing, remediation and regulatory notification are therefore a single connected chain, not separate activities.
Choosing and managing testers
The quality of testing depends heavily on who performs it and how the engagement is scoped. When selecting testers, look for demonstrable skills relevant to the systems in question, recognised methodologies, and genuine independence from the teams that built or run the controls. Scope is just as important as skill. A penetration test confined to an internet-facing login page tells you little about whether an attacker who gets inside could move laterally to a core system. Define scope by reference to your asset classification, so that the most critical and sensitive assets receive the deepest testing and realistic attack scenarios, not just a perimeter scan.
Manage testers as you would any critical third party. Confirm what data they will access, how they will protect it, and how findings will be reported and stored. A test that leaks the very vulnerabilities it discovered is a control failure in itself.
Frequency in practice
Because CPS 234 ties frequency to risk rather than the calendar, a one-size cadence is the wrong model. A workable pattern for many entities looks like this:
- Continuous or frequent vulnerability scanning across the whole estate, so new weaknesses surface quickly.
- At least annual penetration testing of high-criticality, high-sensitivity systems, and more often after significant change.
- Event-driven testing triggered by major releases, new integrations, infrastructure changes or shifts in the threat landscape.
- Periodic control and configuration reviews aligned to the audit cycle.
The key is that the cadence is documented, justified by risk and actually followed. APRA is less interested in a specific number than in whether your frequency is defensible given your assets and threats.
Common gaps to fix
Recurring weaknesses include relying on a single annual penetration test as the entire program, allowing operational teams to assess their own controls, leaving third-party controls untested, scoping tests so narrowly that they prove little, and producing reports that never reach the board or never get remediated. Each of these is a defensible target for APRA scrutiny, and each is straightforward to address with a properly structured program.
Maturing the program over time
A testing and assurance program should not look the same in three years as it does today. As your environment changes and the threat landscape shifts, the program needs to evolve. Two signals indicate maturity. The first is that testing increasingly stresses real-world attack paths rather than isolated controls, moving from checking individual locks to asking whether an attacker could actually get from the front door to the crown jewels. The second is that results are trending in the right direction, with fewer repeat findings, faster remediation and shrinking time between a weakness emerging and being detected. If the same high-severity findings recur test after test, the problem is not the testing but the remediation discipline behind it, and that is exactly the kind of issue internal audit and the board should be surfacing. Treat each cycle of testing as an opportunity to ask not only whether controls work, but whether the program that tests them is getting sharper.
Making assurance count
Independent testing and assurance are how an APRA-regulated entity proves, rather than hopes, that its controls work. If your testing is ad hoc, your independence questionable or your findings unactioned, those gaps undermine the entire CPS 234 posture. For the bigger picture, see our CPS 234 explained guide.
CISO Advisory designs and reviews testing and assurance programs that satisfy CPS 234 and stand up to internal audit and APRA review. To strengthen your assurance, call 07 2112 8502 or speak with us through our Virtual CISO service.
Frequently asked questions
What does CPS 234 require for independent testing?
CPS 234 requires entities to test the effectiveness of their information security controls through a systematic testing program. The nature and frequency of testing must reflect the rate of change in vulnerabilities and threats, the criticality and sensitivity of the asset, and the consequences of a control failure.
How often should controls be tested under CPS 234?
There is no fixed interval. Frequency must be commensurate with how fast threats change and how critical the asset is. High-criticality, high-sensitivity systems facing fast-moving threats warrant frequent testing, while lower-tier assets can be tested less often within a documented program.
What does independent mean in this context?
The tester must be functionally independent of the people who designed, implemented or operate the control being tested. This can be an external provider or an appropriately separated internal team, but a team grading its own work does not satisfy the independence expectation.
Does internal audit have a role under CPS 234?
Yes. CPS 234 requires internal audit to review the design and operating effectiveness of information security controls, including those maintained by third parties, and to assess whether the testing program itself is sufficient and the results are reliable.
How do test results connect to APRA notification?
If testing reveals a material control weakness that cannot be remediated in a timely manner, the entity must notify APRA within 10 business days. Testing is therefore not just assurance; it can directly trigger a regulatory obligation.
Need this handled for your organisation?
Confidential and no obligation. We respond the same business day — on-site same day / next business day, or remote, Australia-wide. Prefer to talk now? Call us 24/7 on 07 2112 8502.