APRA CPS 234 Security Testing Requirements

APRA Prudential Standard CPS 234 — Information Security has been in force since July 2019, yet many APRA-regulated entities are still running testing programmes that would not survive rigorous examination by APRA's supervisory teams. The standard's requirements for security testing are substantive: it mandates that regulated entities test information security controls commensurate with the vulnerability and threat environment, and that they do so with defined regularity. But 'commensurate' and 'defined regularity' are terms that require interpretation — and the gap between what organisations believe satisfies the standard and what APRA's Prudential Practice Guide CPG 234 actually describes is often significant.

This guide is written for Chief Information Security Officers, Heads of Technology Risk, and CTOs at APRA-regulated organisations — banks, insurers, superannuation funds, and their third-party service providers. It covers the specific testing obligations under CPS 234, the testing activities that APRA examiners have consistently focused on in thematic reviews, and what a testing programme that genuinely satisfies the standard — and reduces real security risk — looks like in practice.

What CPS 234 Actually Requires: The Testing Obligations

CPS 234 paragraph 36 requires that regulated entities test the effectiveness of their information security controls through a testing programme that is commensurate with the magnitude of vulnerabilities and threats they face. APRA's CPG 234 (the accompanying Prudential Practice Guide) provides considerably more detail about what 'commensurate' looks like in practice:

• Penetration testing — CPG 234 specifically references penetration testing as a key control-testing mechanism. APRA expects penetration testing of internet-facing systems, internal network segments, and critical systems to be conducted at defined intervals — typically annually as a minimum, and following material system changes.
• Vulnerability scanning — automated vulnerability scanning of the entity's technology environment at regular intervals, with a defined process for prioritising and remediating identified vulnerabilities within risk-appropriate timeframes.
• Control effectiveness testing — testing that verifies specific security controls are operating as designed. This goes beyond vulnerability scanning to test whether controls (access controls, encryption, logging, monitoring) are actually effective, not just present.
• Third-party testing — CPS 234 paragraph 15 requires that regulated entities manage the information security of service providers. This includes requiring that material service providers maintain security standards commensurate with the entity's own — and obtaining evidence that they do.
• Incident response testing — CPG 234 references testing of the entity's ability to detect, respond to, and recover from a security incident. Tabletop exercises and simulated incident scenarios satisfy this obligation — but they must be conducted and evidenced regularly.

What APRA Examiners Actually Focus On

APRA's thematic reviews of CPS 234 compliance — most recently in 2023 and 2024 — have consistently identified common gaps across regulated entities. Understanding what examiners scrutinise helps organisations prioritise their testing programmes correctly.

• Testing frequency and scope — many entities conduct annual penetration tests of a subset of their internet-facing systems and treat this as satisfying the standard. APRA examiners have consistently found this inadequate: the scope should cover all internet-facing systems, internal critical systems, and should be risk-prioritised rather than arbitrarily bounded.
• Third-party assurance — the management of information security in service provider arrangements remains the most commonly identified gap in APRA's thematic reviews. Regulated entities are required to obtain assurance that material service providers maintain adequate security controls — but many rely on SOC 2 reports and questionnaire-based attestations rather than testing-based assurance.
• Timeliness of remediation — identifying vulnerabilities through testing and not remediating them within risk-appropriate timeframes is a CPS 234 compliance failure. APRA expects documented remediation processes with defined SLAs based on vulnerability severity, and evidence of remediation completion.
• Board and executive reporting — CPS 234 requires that the board be informed of material information security incidents and that management reporting on security posture is adequate. Testing programmes that do not produce reporting usable by executive and board audiences are failing a governance requirement, not just an operational one.
• Evidence quality — in an APRA examination, verbal assurances do not satisfy prudential obligations. Examiners review documentation: penetration test reports, vulnerability scan outputs, remediation records, evidence of board reporting, and testing schedules. Testing that cannot be evidenced is treated as testing that did not occur.

Building a CPS 234-Compliant Testing Programme: The Practical Framework

A testing programme that genuinely satisfies CPS 234 — and reduces real security risk, not just audit risk — has five components:

• Risk-based scoping — the testing scope should be derived from the entity's information asset register and threat assessment, not from arbitrary system boundaries. Internet-facing systems, systems that process or store sensitive customer data, core banking or policy administration platforms, and systems operated by material third parties should all be within scope.
• Penetration testing with defined methodology — penetration testing for CPS 234 purposes should follow a recognised methodology (PTES, OWASP, NIST) and be conducted by testers with appropriate qualifications (OSCP, CREST, or equivalent). The test report should document scope, methodology, findings classified by severity, and specific remediation recommendations.
• Continuous vulnerability management — annual penetration testing is a control-effectiveness checkpoint, not a continuous assurance mechanism. Between penetration tests, automated vulnerability scanning of the full environment with integrated remediation tracking provides the continuous assurance the threat environment demands.
• Third-party security assurance programme — for each material service provider, the entity should have a defined assurance approach: what testing evidence is required, at what frequency, and what the escalation process is when a provider cannot demonstrate adequate security posture.
• Testing governance and reporting — the testing programme should be documented in a security testing policy with defined frequencies, scope criteria, and remediation SLAs. Results should be reported to executive risk committees and the board on a schedule that allows the board to discharge its CPS 234 governance obligations.

Penetration Testing for Australian Banks and Insurers: What Good Looks Like

Penetration testing is the highest-visibility element of a CPS 234 testing programme — and the element most commonly performed inadequately. For APRA-regulated entities, a penetration test that satisfies the standard has specific characteristics that distinguish it from a vulnerability scan dressed up as a pen test:

• Scope — a CPS 234-compliant penetration test covers internet-facing applications and infrastructure, internal network segments accessible from the DMZ, privileged access paths and authentication systems, APIs used by customer-facing and internal systems, and cloud environments (AWS, Azure, GCP) and hybrid architectures where applicable
• Methodology — a black-box test of internet-facing systems alone does not satisfy the control-effectiveness requirement. CPS 234 requires testing that verifies controls work as designed — which requires a grey-box or white-box approach for internal systems, where testers work with architecture knowledge to verify whether controls that are supposed to be present are actually effective
• Findings classification — findings should be classified against a consistent severity framework (Critical / High / Medium / Low / Informational). APRA expects remediation timelines proportionate to severity: Critical findings should have remediation SLAs measured in days, not next-quarter roadmap items
• Remediation verification — a penetration test followed by remediation that is not independently verified provides incomplete assurance. APRA expects that critical and high-severity findings are retested after remediation to confirm the vulnerability has been addressed
• Qualified testers — for findings to be credible in an APRA examination, testing should be conducted by CREST-accredited providers or testers holding OSCP, OSEP, GPEN, or equivalent certifications — providing the professional basis for relying on test results as assurance evidence

CPS 234 and Third-Party Risk: The Testing Obligation Most Entities Are Getting Wrong

Third-party information security risk is where APRA's thematic reviews have most consistently found non-compliance. CPS 234 paragraph 15 requires regulated entities to assess and manage the information security of arrangements involving third parties. For the largest APRA-regulated entities — those with dozens or hundreds of material service providers — this is a significant programme management challenge.

The most common gap is reliance on questionnaire-based assurance and point-in-time certifications (ISO 27001, SOC 2) as the sole evidence of a service provider's security posture. For material service providers — particularly cloud service providers, core system vendors, and offshore managed service providers — APRA expects the regulated entity to obtain evidence of security testing performed on the service, review penetration test results, and assess whether identified vulnerabilities have been remediated.

Beyond CPS 234: Building a Mature Security Testing Programme

CPS 234 is the minimum floor for APRA-regulated entities — but the threat environment demands more than minimum compliance. The most mature Australian financial services organisations are running security testing programmes that go well beyond what CPS 234 explicitly requires:

• Red team exercises — adversarial simulations that test the organisation's ability to detect and respond to sophisticated attacks, not just identify technical vulnerabilities. APRA's CPG 234 references threat-led penetration testing (TLPT) as a more rigorous assurance mechanism for the largest and most complex regulated entities.
• Application security testing in the SDLC — shift-left security: integrating static analysis (SAST), dynamic analysis (DAST), and software composition analysis (SCA) into the CI/CD pipeline so that security vulnerabilities are identified and remediated during development, not after production deployment.
• Cloud security posture management — as Australian banks and insurers migrate workloads to cloud environments, continuous assessment of cloud configuration against security benchmarks (CIS Benchmarks, AWS/Azure/GCP security baselines) provides ongoing assurance that cloud environments do not drift into non-compliant states between point-in-time assessments.
• API security testing — financial services applications are increasingly API-first. The OWASP API Security Top 10 provides a structured framework for testing the security of APIs that handle customer data and financial transactions — and API vulnerabilities are consistently among the highest-severity findings in financial services penetration tests.