APRA CPS 234 is the information security standard APRA regulated organisations in Australia use to guide how they manage cyber risk and protect critical information assets.
The harder part is turning that expectation into a testing program that reflects the actual risk around your information assets. Penetration testing can play an important role here by exposing weaknesses in technical controls before they become larger security problems.
This guide looks at how APRA CPS 234 penetration testing should be planned and documented so the testing you perform is relevant, proportionate, and useful for compliance.
Does CPS 234 Require Penetration Testing?
No. CPS 234 does not make penetration testing a standalone requirement for every APRA-regulated organisation. What it does require is systematic testing of information security controls, with the type and frequency of testing matched to risk.
The distinction between CPS 234 and CPG 234 is also important here. CPS 234 contains the mandatory prudential requirements. CPG 234 is APRA guidance that gives regulated entities examples of how those requirements can be addressed.
Within CPG 234, APRA specifically includes penetration testing as a suitable testing method for several technical controls. In CPG 234, G points to penetration tests for firewalls, routers, and network segmentation. It also recommends penetration testing and more advanced red team exercises for testing unauthorised access detection. For secure software, suggested techniques include design reviews, penetration testing, code review, scanning, traffic analysis, fault testing, and fuzzing.
This means a penetration test can provide useful evidence that selected technical controls are operating effectively. However, a successful test should not be treated as proof that all cps 234 compliance requirements have been met. CPS 234 also covers areas such as governance, information asset protection, incident management, third party arrangements, and broader assurance activities.
What CPS 234 Paragraphs 27 to 31 Require From Your Testing Program
Paragraphs 27 to 31 set the expectations for how security testing should be planned, carried out, reviewed, and escalated when problems remain unresolved.
Paragraph 27: Build a Risk-Based Systematic Testing Program
CPS 234 expects testing to reflect the risk around each information asset. The same testing schedule will not suit every system.
You need to consider:
- How quickly threats and vulnerabilities are changing
- How critical or sensitive the asset is
- What could happen if a security incident occurs
- Whether the asset is exposed to an untrusted environment
- How often major changes are made to the asset
A critical internet-facing banking system will usually need deeper and more frequent testing than a low-impact internal application.
Paragraph 28: Validate Third Party Testing
If you use cloud infrastructure, SaaS platforms, hosted services, or systems managed by another provider, you still need to check whether their testing is relevant to your environment.
A third-party risk assessment CPS 234 review should answer questions such as:
- What systems and configurations were included?
- Was your environment actually covered?
- Which methodology was used?
- When was the test completed?
- Are any findings still open?
- Has the environment changed since the test?
The presence of a provider report alone does not tell you whether the testing is enough for your risk profile.
Paragraph 29: Escalate Control Deficiencies
Findings that cannot be fixed within a suitable timeframe need to move beyond the security team. CPS 234 requires those control deficiencies to be escalated and reported to the Board or senior management.
Paragraph 30: Use Skilled and Functionally Independent Testers
The people carrying out the assessment must have the right expertise and enough independence to give an objective result.
Functional independence means the tester should not be responsible for operating the control being assessed.
Choosing a CREST-accredited penetration testing provider in Australia ensures the assessment meets international quality standards and satisfies APRA auditor expectations for technical competence.
Paragraph 31: Review the Testing Program
The testing program itself must also be reviewed.
CPS 234 requires a review of its sufficiency:
- At least once every year
- When a material change affects information assets or the business environment
This requirement applies to the overall testing program. It should not be read as an instruction to perform a penetration test on every system every year.
How to Build a CPS 234 Penetration Testing Program
Step 1: Identify and Classify Information Assets
First, confirm what is actually in your environment. Include applications, APIs, networks, infrastructure, cloud services, and relevant assets managed by external providers.
Classify them according to criticality and sensitivity. Criticality considers the effect of losing availability. Sensitivity looks at the consequences if confidentiality or integrity is compromised. Assets carrying greater business or customer impact should receive stronger technical assurance.
Step 2: Map Threats, Exposure and Business Consequences
Look at the attack scenarios that matter for each important asset. Internet exposure, stolen credentials, API abuse, privilege escalation, ransomware, cloud configuration weaknesses, insider access, and supplier compromise may all require consideration.
Then ask what a successful attack could affect, such as:
- Customer data
- Critical operations
- Regulated services
- Access to sensitive information
Step 3: Select the Right Security Testing Technique
Not every control needs a penetration test. CPG 234 recommends choosing testing methods according to the control being assessed.
For example:
- Network protection can use penetration testing
- Secure software can use code review, scanning, fuzzing, and penetration testing
- Monitoring controls can use red team exercises
- Recovery controls can use technical recovery tests
A vulnerability assessment and penetration testing (VAPT) engagement should therefore be selected where it fits the control and risk being examined.
Step 4: Define Scope, Success Criteria and Rules of Engagement
Set the boundaries of the test before any work begins. The team should know what is being assessed, what is off limits, and what result would count as a successful test. CPG 234 specifically recommends clear success criteria and defined circumstances for retesting.
Document:
- Assets and environments in scope
- Exclusions and testing limits
- Production safeguards
- Testing window and emergency contacts
- Data handling requirements
- Required third-party permissions
- Severity criteria and retesting conditions
Step 5: Conduct Testing and Capture Evidence
The assessment should examine whether realistic attack paths can bypass the controls being tested, rather than stopping at automated scanner results.
Keep evidence that shows:
- What was tested
- How the weakness was confirmed
- What access or impact could result.
Screenshots, logs, requests, reproduction steps, and validated findings can also support cyber security auditing Australia activities by giving reviewers traceable evidence of control performance.
Step 6: Remediate, Retest and Close Findings
Once testing identifies a significant weakness, assign responsibility and keep the finding visible until the risk has been addressed. APRA has specifically warned about weak management and oversight of security test findings.
For each important finding, record:
- Severity and remediation owner
- Target completion date
- Interim mitigation
- Any accepted residual risk
- Retest result
Retesting should confirm that the technical weakness has actually been corrected before closure.
What Should a CPS 234 Penetration Test Cover?
Once penetration testing has been selected, the scope should concentrate on the environments and controls where a successful attack could expose critical or sensitive information assets.
External Infrastructure
External testing should examine the systems and services reachable from outside your organisation.
Typical areas include:
- Internet-exposed services
- Perimeter devices and network boundaries
- Administrative interfaces
- Unsupported or legacy systems
- Known exploitable weaknesses
- Firewall and segmentation controls
Web Applications and APIs
Applications and APIs should be tested for weaknesses that could expose data or allow users to perform actions beyond their intended permissions.
Focus on:
- Authentication and session handling
- Authorisation controls
- Business logic
- Sensitive data exposure
- API object-level access
- Token handling
- Privilege boundaries
- Administrative endpoints
Identity and Authentication
Identity controls need close attention where they protect privileged access or remote access to sensitive systems.
Testing may include:
- MFA bypass
- MFA enrolment and account recovery
- Password reset flows
- SSO and federation
- Privileged accounts
- Service accounts
- Conditional access
- Remote administration
- Session security
APRA specifically calls for stronger authentication around privileged access, remote access, and other high-risk activities.
Cloud and Internal Environments
Internal and cloud testing should look for routes an attacker could use after gaining an initial foothold.
Relevant areas include:
- IAM permissions
- Privilege escalation
- Exposed storage
- Secrets and credentials
- Security groups
- Control plane access
- Logging gaps
- Active Directory weaknesses
- Credential reuse
- Lateral movement
- Network segmentation
These tests help show whether an attacker could move from one compromised system into more sensitive parts of the environment.
Vulnerability Scanning vs Penetration Testing vs Red Teaming Under CPS 234
APRA recognises several forms of security testing, so the choice should match the control and assurance objective rather than relying on one method for everything. CPG 234 also lists security testing, including penetration testing, as part of an effective information security capability.
| Method | Primary purpose |
| Vulnerability scanning | Identify known weaknesses across systems on a regular basis |
| Penetration testing | Confirm whether weaknesses can be exploited and combined into realistic attack paths |
| Red teaming | Challenge broader defensive capabilities by testing whether an attacker can achieve a defined objective |
Scanning is useful when you need recurring visibility across a large environment. It is well suited to finding known weaknesses quickly, but it does not show whether those issues can be used successfully in an attack.
Human-led penetration testing adds that validation. Testers can examine how separate weaknesses interact and whether they create a meaningful route into sensitive systems or data.
Red team exercises can assess whether monitoring teams detect suspicious activity and whether response processes work once an attacker begins moving through the environment.
When Can a Penetration Test Finding Trigger Board or APRA Reporting?
A penetration test finding does not automatically need to be reported to APRA. What happens next depends on whether the issue is an unresolved control deficiency, an information security incident, or a material control weakness.
Reporting Testing Deficiencies Internally
Paragraph 29 requires testing results to be escalated to the Board or senior management when they identify information security control deficiencies that cannot be remediated on time. APRA also expects reporting arrangements to give governing bodies enough information to carry out their security responsibilities.
This means serious unresolved findings should not remain only within technical teams. They need to reach the appropriate decision makers when remediation cannot be completed promptly.
72 Hours: Material Information Security Incidents
Paragraph 35 applies when the organisation becomes aware of an information security incident that materially affected, or had the potential to materially affect, the entity or its customers. The same notification requirement also applies when the incident has been reported to another regulator.
APRA must be notified as soon as possible and no later than 72 hours after the organisation becomes aware of the incident. A vulnerability discovered during testing is not automatically an information security incident.
10 Business Days: Material Control Weaknesses
Paragraph 36 covers a different situation. If the organisation becomes aware of a material information security control weakness that it expects it cannot remediate promptly, APRA should be notified as soon as possible and no later than 10 business days.
How Qualysec Can Support APRA CPS 234 Penetration Testing
If penetration testing forms part of your CPS 234 testing programme, Qualysec provides CREST-aligned penetration testing across web applications, APIs, cloud environments, external networks, mobile applications, and IoT assets. The scope can be built around the systems that need technical assurance rather than using the same test for every environment.
Our testing combines automated checks with manual validation and controlled exploitation. This helps confirm whether a reported weakness can actually be used by an attacker and how far that access could go.
After testing, you receive findings with severity ratings, supporting evidence, technical details, remediation guidance, and validation once fixes are applied. These records can support the technical evidence needed as part of a wider CPS 234 assurance programme.
Qualysec does not certify CPS 234 compliance. Our role is to provide the penetration testing evidence your team can use alongside its wider governance and assurance activities.
If you are planning APRA CPS 234 penetration testing, speak with Qualysec to define a scope around the systems you need assessed.
Conclusion
CPS 234 requires more than a routine penetration test repeated on a fixed schedule. Security testing should continue to reflect the risks affecting your information assets and the controls protecting them.
Penetration testing has a clear place when you need to validate technical controls against realistic attack methods. What matters afterwards is whether confirmed weaknesses are addressed, fixes are checked, and the results remain available as evidence of control effectiveness.
A well-planned testing programme gives you a much stronger basis for CPS 234 assurance than relying on a single annual assessment.
FAQs
Does CPS 234 require penetration testing?
Not in every case. CPS 234 requires organisations to test information security controls systematically. CPG 234 then points to penetration testing as one suitable option for areas such as network protection and secure software.
Is vulnerability scanning enough for CPS 234?
Usually not by itself. Scanning is useful for finding known weaknesses, but APRA expects the testing method to suit the control being checked. Some controls need manual testing or other forms of assurance.
Does CPS 234 apply to third-party and cloud systems?
Yes. If another organisation manages your information assets, you still need to judge whether its security testing is suitable for the risks affecting those assets. That responsibility remains with the APRA-regulated entity.
What evidence should be retained after CPS 234 penetration testing?
Keep records that show the scope of the assessment and how the test was performed. The file should also show confirmed findings plus the actions taken after testing and any retest results.
Do penetration testing findings need to be reported to APRA?
No. A finding becomes reportable when it amounts to a material information security control weakness that cannot be fixed on time. In that case, CPS 234 sets a 10-business-day notification period.
