APRA's Prudential Standard CPS 234 Information Security, in force since 1 July 2019, does not contain the words "penetration test". What it contains is paragraph 27: "An APRA-regulated entity must test the effectiveness of its information security controls through a systematic testing program." Penetration testing is named one level down, in Prudential Practice Guide CPG 234, which lists "security testing, including penetration testing" among the capabilities an entity typically needs and names penetration tests in five rows of its table of example testing approaches.
Quick answer. CPS 234 requires testing, not a penetration test by name. An APRA-regulated bank, insurer or superannuation trustee must run a systematic testing program (paragraph 27), have it carried out "by appropriately skilled and functionally independent specialists" (paragraph 30), escalate deficiencies that cannot be fixed in time (paragraph 29) and review the program at least annually (paragraph 31). CPG 234, which is guidance, expects a sufficient set of controls to be tested "at least annually", expects internet-facing and other untrusted-environment controls to be tested "throughout the year", and names penetration tests as an example approach for networks, detection, software, backups and new vulnerabilities. A vendor to an APRA-regulated entity is not bound directly: the entity must assess the vendor's capability, control design and testing (paragraphs 16, 22 and 28), so the vendor answers with a recent independent penetration test, retest results and a stated testing cadence.
This guide is for two readers: the security or risk lead at an APRA-regulated entity who has to show a testing program that stands up, and the software vendor or service provider whose customer has sent a CPS 234 questionnaire. Every statement about the rules below was read from APRA's own published standard, practice guide, letters and court filings, or from the Federal Register of Legislation, on 13 November 2026, and links to that source. It explains published requirements and guidance; it is not legal advice.
What CPS 234 is, and who it covers
CPS 234 is a legislative instrument, not a guideline. It was made on 30 November 2018 under the Banking Act 1959, the Insurance Act 1973, the Life Insurance Act 1995, the Private Health Insurance (Prudential Supervision) Act 2015 and the Superannuation Industry (Supervision) Act 1993, and the Federal Register of Legislation lists it as in force. Paragraph 5 says: "This Prudential Standard commences on 1 July 2019, subject to paragraph 6." The register holds a single version of the instrument, so the text has not been amended since, and it lists a scheduled repeal date of 1 April 2029 under section 50 of the Legislation Act 2003, the sunsetting provision.
Paragraph 2 applies it to all APRA-regulated entities:
banks and other "authorised deposit-taking institutions (ADIs), including foreign ADIs", and their non-operating holding companies;
general insurers, life companies (including friendly societies) and private health insurers;
RSE licensees, the trustees of superannuation funds, "in respect of their business operations".
Three scope points matter for testing. A foreign bank or insurer branch is covered "only in relation to the Australian branch operations of that entity" (paragraph 3). The head of a group must apply each requirement "appropriately throughout the group, including in relation to entities that are not APRA-regulated" (paragraph 4), which pulls unregulated subsidiaries and shared service companies into the testing program. And assets managed by a third party have been in scope since "the earlier of the next renewal date of the contract with the third party or 1 July 2020" (paragraph 6), so every such arrangement is now covered.
The companion document, CPG 234, is dated June 2019. APRA's own introduction to it says prudential practice guides "provide guidance on APRA's view of sound practice in particular areas" and "do not themselves create enforceable requirements." That split, a binding standard that says "must" and a guide that says "would typically", is the key to reading everything below. APRA describes the design this way in its cyber security explainer of 13 October 2025: "CPS 234 is principles-based, rather than prescribing specific cyber security controls, which might become outdated or inadequate over time."
What CPS 234 says about testing
The heading "Testing control effectiveness" covers five paragraphs. They are short enough to quote in full.
Paragraph 27. An APRA-regulated entity must test the effectiveness of its information security controls through a systematic testing program. The nature and frequency of the systematic testing must be commensurate with: (a) the rate at which the vulnerabilities and threats change; (b) the criticality and sensitivity of the information asset; (c) the consequences of an information security incident; (d) the risks associated with exposure to environments where the APRA-regulated entity is unable to enforce its information security policies; and (e) the materiality and frequency of change to information assets.
Paragraph 28. Where an APRA-regulated entity's information assets are managed by a related party or a third party, and the APRA-regulated entity is reliant on that party's information security control testing, the APRA-regulated entity must assess whether the nature and frequency of testing of controls in respect of those information assets is commensurate with paragraphs 27(a) to 27(e) of this Prudential Standard.
Paragraph 29. An APRA-regulated entity must escalate and report to the Board or senior management any testing results that identify information security control deficiencies that cannot be remediated in a timely manner.
Paragraph 30. An APRA-regulated entity must ensure that testing is conducted by appropriately skilled and functionally independent specialists.
Paragraph 31. An APRA-regulated entity must review the sufficiency of the testing program at least annually or when there is a material change to information assets or the business environment.
Read together, the five paragraphs set six obligations.
A program, not a test. "Systematic" means the entity can show which controls exist and when each one is tested. A single annual penetration test of one application is a test. It is not a program.
Calibrated nature and frequency. The five factors in paragraph 27 decide how deep and how often. A fast-changing, internet-facing, customer-critical system sits at the top on every factor.
An assessment of any third-party testing the entity relies on. Paragraph 28 does not ask the entity to test its vendor. It asks the entity to judge whether the vendor's testing is deep and frequent enough.
Escalation. Results that show deficiencies which cannot be fixed in a timely manner go to the Board or senior management.
Skilled, independent testers.
An annual look at the program itself, and another after any material change.
Four neighboring requirements complete the picture. Paragraph 26 says an entity "must annually review and test its information security response plans". Paragraph 35 requires notifying APRA of a material information security incident "as soon as possible and, in any case, no later than 72 hours". Paragraphs 32 to 34 require internal audit to review "the design and operating effectiveness of information security controls, including those maintained by related parties and third parties". And paragraph 36 can turn a test result into a regulatory clock: the entity must notify APRA "as soon as possible and, in any case, no later than 10 business days, after it becomes aware of a material information security control weakness which the entity expects it will not be able to remediate in a timely manner."
The standard never says "penetration test"
The phrase does not appear anywhere in CPS 234, and neither do "vulnerability scan" or "red team". An article or a sales page that says "CPS 234 mandates annual penetration testing" is describing the practice guide and market convention, not the instrument. The accurate statement is narrower and more useful: the standard requires effective, independent, risk-calibrated testing of every information security control, and APRA's guidance names penetration testing as an example way to do part of it.
Where penetration testing is named: CPG 234
CPG 234 uses the phrase in three places: a capability list, a table of testing approaches and a list of board metrics.
As a capability. Paragraph 16 says the "current threat landscape has necessitated information security capabilities that extend beyond information technology general controls to more specialised information security capabilities", and item (e) of its list is "security testing, including penetration testing".
As an example testing approach. Paragraph 80 says the "nature of testing would be a function of the type of control, and would typically consider a variety of testing approaches informed by contemporary industry practices (refer to Attachment G for further guidance)." Attachment G is a three-column table of control objectives, example controls and example testing approaches. Penetration tests appear in five rows:
Control objective in Attachment G | Example testing approach APRA lists |
|---|---|
Protect networks from unauthorised network traffic | Penetration tests |
Timely detection of unauthorised access and use | Penetration tests including more advanced techniques commonly referred to as "red team" tests |
Implement secure software | Design reviews, penetration tests, code review and scanning, network traffic analysis, fault testing, fuzzing |
Recovery under all plausible scenarios (controls to protect backups from compromise) | Technical recovery tests; backup environment penetration test |
Timely identification and remediation of new vulnerabilities | Vulnerability scans, penetration testing |
The other rows name different techniques: a social engineering test for access controls, audits of user access for authentication, table top exercises for incident response, and an independent capability review for threats.
As a board metric. Attachment H lists "Penetration testing (by type, count and finding rating)" among the common metrics reported to Boards and management.
Two further passages bear on it without using the phrase. Paragraph 47(a) expects change management to include "security testing (including reviews) to identify vulnerabilities and confirm information security requirements have been met", scaled to "the scope of the change and the sensitivity and criticality of the impacted information asset". And when APRA wrote to all regulated entities on 15 August 2024 with additional insights on common cyber resilience weaknesses, its guidance on security testing was to use "a variety of testing approaches informed by contemporary industry practices including IT general controls, vulnerability scanning, traditional penetration tests of software and infrastructure, red-team and gold-team exercises."
So the position is this. An entity that ran no penetration testing at all would not breach a sentence of CPS 234 that names it, because there is no such sentence. It would struggle to show that its network, detection, software, backup and vulnerability management controls had been effectively tested, because APRA's own examples for those five objectives are penetration tests, and its 2024 letter points entities back to exactly that guidance.
How often CPS 234 expects testing
CPS 234 sets no interval for any security test. The only frequencies it fixes are for reviewing the testing program (paragraph 31, "at least annually") and for testing incident response plans (paragraph 26, annually). How often to test a control is the entity's decision, driven by the five factors in paragraph 27.
CPG 234 fills the gap with three expectations.
At least annually, for a sufficient set of controls. Paragraph 79: "In APRA's view, the frequency and scope of testing would ensure that a sufficient set of information security controls are tested, at least annually, in order to validate that information security controls remain effective."
Throughout the year, for anything exposed. The same paragraph continues: "controls protecting information assets exposed to 'untrusted' environments would typically be tested throughout the year." The footnote defines those environments as ones "where an APRA-regulated entity is unable to enforce its information security policies, including exposures to the internet and connections to service providers and customers."
On triggers. Paragraph 78: "Additional testing could be triggered by changes to vulnerabilities/threats, information assets or the threat landscape."
For a penetration testing calendar, a reasonable reading of that guidance is:
Asset | What the guidance points to | A cadence that fits it |
|---|---|---|
Internet banking, member and policyholder portals, public APIs, customer authentication | Tested "throughout the year" (untrusted environment) | A full penetration test each year, plus testing after each significant release or on a continuous program |
Connections to service providers and customers (file transfer, partner APIs, remote access) | Tested "throughout the year" (untrusted environment) | Included in the annual external test, and retested when the connection changes |
Internal network, Active Directory, core systems | Tested "at least annually", as part of a sufficient set of controls | An annual internal penetration test, sized to criticality |
Backup environment | Named in Attachment G | A penetration test of the backup environment within the annual cycle |
Detection and response | Red team tests named in Attachment G | A red team or purple team exercise at a frequency the entity can justify |
Anything after a material change | CPS 234 paragraph 27(e) and CPG 234 paragraph 47(a) | A scoped test before or soon after go-live |
The asset mapping and the right-hand column are our reading, not APRA's wording: paragraph 79 names no asset types beyond the footnote's internet exposures and connections to service providers and customers. The standard's own test is whether the cadence follows the paragraph 27 factors, so the entity should be able to show its reasoning for each asset. Our guide to how often to run a penetration test covers the same decision across frameworks, and continuous penetration testing explains the model that suits the "throughout the year" assets.
Who can do the testing
Paragraph 30 sets two tests for the tester: "appropriately skilled" and "functionally independent". CPG 234 paragraph 82 explains the second: testers must be "sufficiently independent in order to provide a bias-free assessment of controls (i.e. unimpeded by a conflict of interest). This includes the use of testers who do not have operational responsibility for the controls being validated. The level of functional independence required would typically be determined by the nature and importance of the testing."
Four practical consequences follow.
There is no APRA list. Neither CPS 234 nor CPG 234 names a certification, an accreditation scheme or an approved panel of testers. CPS 234 and CPG 234 set no accreditation requirement for testers, so they give no provider a basis to call itself "APRA-approved" or "CPS 234 certified". The entity decides who is appropriately skilled and has to be able to defend the choice.
An internal team can qualify, if its members have no operational responsibility for the controls they test. A security operations team testing its own firewall rules does not.
A managed service provider that runs a control should not be the only party that tests it. The words "functionally independent" rule that out for testing that matters.
Skill needs evidence. Named testers, their certifications and research record, and a firm-level accreditation such as CREST are the usual ways to show it. Those are the entity's evidence for its own judgment, not APRA requirements. Our RFP question bank turns paragraph 30 into pass-or-fail prequalification questions.
For selected institutions there is a separate, regulator-coordinated exercise. The Council of Financial Regulators released the Cyber Operational Resilience Intelligence-led Exercises (CORIE) framework in December 2020 "to test and demonstrate the cyber maturity and resilience of institutions". Its July 2022 release on version 2.0 says the selection of participants for future exercises "will take a risk-based approach" and that procuring the threat intelligence and red teaming providers "is the responsibility of the participating financial institution". The CORIE Provider Guide (Appendix B to framework version 2.0, July 2022) does list tester credentials for those exercises: for the red team lead a "Required certification" chosen from a named list and "7 years of red teaming or penetration testing experience", and for the threat intelligence lead a required certification and "3 years of related intelligence experience". Those are role requirements inside a CORIE exercise, not an accreditation of firms. CORIE sits beside the CPS 234 testing program; nothing in CPS 234 treats it as a substitute. Our comparison of TIBER-EU, CBEST and DORA TLPT covers its overseas counterparts.
Third parties and vendors: what reaches a service provider
CPS 234 binds the regulated entity. It reaches a vendor chiefly through four paragraphs, each about information assets managed by a related party or third party.
Paragraph | What the entity must do about the third party |
|---|---|
16 | "assess the information security capability of that party, commensurate with the potential consequences of an information security incident affecting those assets" |
22 | "evaluate the design of that party's information security controls that protects the information assets of the APRA-regulated entity" |
28 | where it relies on the party's control testing, "assess whether the nature and frequency of testing of controls in respect of those information assets is commensurate with paragraphs 27(a) to 27(e)" |
34 | have internal audit "assess the information security control assurance provided by a related party or third party" where an incident could materially affect the entity or its customers and audit intends to rely on that assurance |
A footnote to each one closes the obvious loophole. The paragraph "applies to all information assets managed by related parties and third parties, not only those captured under agreements with service providers of outsourced material business activities". A small SaaS tool that holds customer data is in scope alongside the core banking platform; what changes with size is the depth of the assessment, which is "commensurate with the potential consequences".
CPG 234 says how entities form that view. Paragraph 17: "This could be achieved through a combination of interviews, service reporting, control testing, certifications, attestations, referrals and independent assurance assessments." Paragraph 19 adds the instruction that explains most of the follow-up questions a vendor receives: the entity "could also consider the scope, depth and independence of certifications, attestations and assurance provided and take steps to address any limitations identified." For bought software, Attachment D lists "due diligence as to the security testing conducted to identify vulnerabilities" among the factors when selecting and configuring vendor-supplied software, including software as a service.
APRA has said repeatedly that entities do this badly, which is why the questions keep getting sharper. In November 2021 it reported, from a pilot data collection, that "60 percent of entities had not managed to assess all of their IT service providers' information security control testing as per the requirements of CPS 234", and that some "relied heavily on control self-assessments or surveys completed by their service providers, and had not taken any steps to independently verify that the information security controls were effective" (APRA, 23 November 2021). The first tranche of its CPS 234 tripartite assessments, published on 5 July 2023, found that "control design and operating effectiveness are often based on the third party's self-assessment only, without verification through additional independent testing" and that "the nature and frequency of testing is not aligned to the criticality and sensitivity of information assets managed by third parties."
What CPS 230 adds for material service providers
CPS 230 Operational Risk Management took effect on 1 July 2025, and an updated version with limited exemptions for certain non-traditional service providers such as central banks and clearing facilities commenced on 1 July 2026. It does not mention penetration testing. It changes the vendor relationship in four ways that affect testing evidence.
A register of material service providers. Paragraph 48 defines them as "those on which the entity relies to undertake a critical operation or that expose it to material operational risk", and paragraph 49 says providers of "risk management, core technology services and internal audit" must be classified as material for all entities "unless it can justify otherwise".
Contract terms. For material arrangements the formal agreement must set out rights including "audit access" (paragraph 53), and must "allow APRA access to documentation, data and any other information related to the provision of the service" and "allow APRA the right to conduct an on-site visit to the service provider" (paragraph 54).
Ongoing monitoring. Paragraph 59 requires a regular assessment of "the effectiveness of controls to manage the risks associated with the use of the service provider". The updated CPG 230 says periodic reviews could cover "control effectiveness; information security capabilities and business continuity capabilities".
A link back to CPS 234. Paragraph 24 says that in managing technology risks an entity must "meet the requirements for information security in Prudential Standard CPS 234".
The practical effect: a vendor classed as a material service provider should expect its customer to ask for testing evidence at onboarding and again on a regular cycle, under contract terms that give the customer, and APRA, a right to look behind the summary. APRA's System Risk Outlook of 12 November 2026 shows why overseas vendors are in the frame: "Of the top 100 providers reported by APRA-regulated institutions, 80 are headquartered or have their principal operations outside Australia."
What APRA has found since 2019
APRA has tested compliance with CPS 234 at scale. Its tripartite assessment program required entities "to appoint an independent auditor to assess their compliance" with the standard; more than 300 banks, insurers and superannuation trustees were due to take part by the end of 2023. The findings on testing have been consistent.
July 2023, first tranche. "Findings from the first tranche have shown that, in many cases, the testing programs of entities are incomplete, inconsistent, lack independence and do not provide adequate assurance for management and the Board." The listed gaps include testing that "is not performed by functionally independent testers" and evidence that "is not retained".
August 2024, letter to all entities. Two observations on security testing: "Inadequate and insufficient testing coverage, often with repeated testing of the same limited set of IT assets" and "Inadequate management and oversight of security test findings." The letter adds that where an entity's review finds gaps that could materially affect its risk profile, "APRA considers this a material security control weakness notifiable under paragraph 36 of CPS 234."
June 2025, letter to superannuation trustees. After credential stuffing attacks on funds, APRA required RSE licensees to self-assess their information security controls, authentication controls in particular, and to complete the actions by 31 August 2025. Funds directly affected by the attacks were "required to undertake a special purpose engagement, as opposed to the self-assessment".
October 2025, APRA Member Suzanne Smith. The tripartite program "revealed sector wide deficiencies", among them "sporadic third-party security assurance" and "irregular and inconsistent testing" (speech of 28 October 2025).
November 2026, System Risk Outlook. "AI is increasing the speed and scale at which software vulnerabilities can be identified and exploited", and "malicious actors may be able to exploit vulnerabilities sooner, leaving financial institutions and material service providers less time to assess exposures, apply patches and contain cyber-attacks." Under paragraph 27(a), a faster rate of change in vulnerabilities and threats is a reason to test more often.
The 2026 court case: penetration test findings that were logged and left open
On 10 August 2026 APRA commenced civil penalty proceedings in the Federal Court against Bendigo and Adelaide Bank over a March 2023 cyber attack on its Alliance Bank business, which the agreed facts describe as "a network of five authorised representatives" and which ran on a separate core banking platform. The bank admitted the contraventions, and APRA published the Statement of Agreed Facts and Admissions with its media release of 11 August 2026. It is a detailed public account of how a testing program missed one platform, and the gap was not a missing penetration test. Two limits apply to everything below. The facts and admissions "are agreed to and made solely for the purpose of the Proceeding". And under an adjustment APRA approved in June 2020, CPS 234 applied to the bank's information assets managed by a third party, this platform among them, from 1 January 2021.
The agreed facts, in order:
A test was recommended for years. A 2017 external review said the bank "should perform regular application penetration testing" of the platform. In October 2019 a board committee was told the recommendation remained open.
The test was done, and it found the problem. On or about 2 June 2020 an external firm reported on a penetration test of the instance used by one of the five Alliance Bank partners. It found that it was possible to set an easily guessed password such as "password1" and that valid customer numbers could be identified from the login error messages, and it rated each of those findings "moderate". It said that, coupled with weak passwords, this would let an attacker "perform password spray attacks". It also noted that there was no CAPTCHA and that one-time passwords were optional.
The findings were logged and left open. They were reviewed and logged in a vulnerability tracking tool. They "were not further escalated", were not assessed against the bank's risk escalation matrix, and "the vulnerabilities identified were not remediated until March 2023." The agreed facts say no similar testing was prepared for the other four partners before March 2023.
The assurance reports did not cover the control. The bank received annual assurance reports on the hosting provider's infrastructure, which "did not consider individual applications hosted on that infrastructure", and a 2022 control validation that "reviewed existing documentation and artefacts" without assessing the design or operating effectiveness of the customer authentication controls.
A warning attack led to partial fixes. On or about 27 October 2022 brute force login attacks hit two instances. No accounts were accessed. The bank notified APRA and added a web application firewall and CAPTCHA for online banking, but CAPTCHA "was inadvertently not implemented for Mobile Banking", and the bank "did not subsequently undertake a substantive review" of the attacks or of the customer authentication controls.
The attack succeeded. Between 3 and 7 March 2023 an attacker reached approximately 257 customer accounts. When it started, 1,598 of that partner's customer accounts were protected by the password "123456". The attacker made 286 transactions involving 87 accounts. The bank's automated fraud controls stopped 51 payments; a further A$140,110 could not be recovered, and the bank repaid those funds within four days.
The retest told the story. Penetration testing after the attack "identified the same vulnerabilities that were identified in the Penetration Test Report." The bank's own review found "it was possible that the Cyber Attack could have been avoided had the risks identified in the penetration test in 2020 been properly assessed, escalated and managed".
The bank admitted that it did not have "a systematic testing program for the customer authentication controls applicable to Alliance Bank Digital Access". The legal contraventions are of the Banking Executive Accountability Regime in the Banking Act, with the CPS 234 testing failure as one of the admitted grounds. APRA's release of 11 August 2026 says the "parties propose orders in the proceedings that Bendigo Bank pays a pecuniary penalty of $8 million", that this is "subject to Court approval", that the weaknesses "were satisfactorily remediated following the cyber attack" and that, at that date, APRA "does not currently have concerns regarding the adequacy of Bendigo Bank's information security controls." As of 13 November 2026 the Court has made no judgment or penalty order. The court file shows the proceeding open, submissions on penalty filed on 23 October 2026 (the date the Court set for the parties' joint submissions) and a hearing, estimated at one day, listed for 24 November 2026 before Justice O'Bryan. In the release, Deputy Chair Therese McCarthy Hockey drew the general lesson: "all APRA-regulated entities must have appropriate cyber protection systems and regularly test the adequacy of those controls."
Four lessons carry over to every testing program.
Coverage is the program. Before the attack, the customer authentication controls were penetration tested once, on the instance used by one of the five partners. CPG 234 paragraph 78 builds a testing program from the whole population of controls, and APRA's 2024 letter had already called out "repeated testing of the same limited set of IT assets".
A finding is not closed by being logged. Paragraph 29 turns on whether a deficiency can be "remediated in a timely manner". A moderate finding still open more than two years after CPS 234 applied to the platform is a paragraph 29 matter, whatever its rating. The bank's own June 2023 breach assessment was made "in respect of paragraphs 21 and 29 of CPS 234".
Read findings together, not one rating at a time. The weak-password and enumeration findings were each rated moderate, and the report itself said that, coupled with weak passwords, enumeration would let an attacker "perform password spray attacks". The bank's later review found the findings "should have been identified and reported as significant risks" and considered "in an aggregated way". A rating alone does not carry that message to the people who can act on it; the escalation rule has to. Our guide to evaluating a penetration test report covers reading findings in combination, and our password spraying guide explains the technique from the defender's side.
An assurance report only covers what it covers. Infrastructure assurance from a hosting provider said nothing about application-level authentication. That is the "scope, depth and independence" question in CPG 234 paragraph 19.
Stingrai's own data points the same way. In The State of Penetration Testing 2026, authentication and session weaknesses were the largest single class of finding, 253 of 1,206 verified findings, and the median tracked finding was resolved in 26 days. The gap between finding and fixing is where a testing program is won or lost.
What a CPS 234 testing program should cover
CPG 234 paragraph 78 describes the starting point: the entity "would normally outline the population of information security controls across the regulated entity, including any group of which it is a part, and maintain a program of testing which validates the design and operating effectiveness of controls over time." Penetration testing is one technique inside that program. Mapped to the Attachment G objectives where APRA names it, the scope looks like this.
Networks. External perimeter and internal network penetration testing, including segmentation between environments and between group entities. See internal and external network penetration testing and the Active Directory security assessment for the identity paths behind them.
Software. Web application, API and mobile application penetration testing, authenticated across every user role, with customer authentication and account recovery in scope by name. The Bendigo facts are a case for writing "customer authentication controls" into the scope statement.
Cloud. The control plane, identity configuration and workloads behind those applications (cloud penetration testing).
Detection. A red team or purple team exercise that tests whether monitoring sees an attack in progress. In the Bendigo facts, neither the bank nor its providers monitored suspicious or increased login activity, though they did monitor transactions, and the bank learned of both attacks from customers.
Backups. A penetration test of the backup environment, which Attachment G lists. APRA's letter of 3 June 2024 on backups found "insufficient control testing coverage and rigour to ensure backups are protected from compromise".
People. Attachment G lists a "social engineering test" for access controls and staff awareness (phishing campaigns).
Third parties. For each provider that manages the entity's information assets, either the provider's own independent test results, assessed under paragraph 28, or testing the entity commissions under its contract.
Vulnerability scanning belongs in the program too, as APRA's list of approaches says, but it answers a different question. A scan reports known weaknesses; a penetration test shows what an attacker can do with them and with the logic flaws a scanner does not see. Our comparison of vulnerability assessment and penetration testing sets out which requirement each one meets.
The evidence APRA, internal audit and an assessor look for
Neither CPS 234 nor CPG 234 contains a penetration testing checklist. The evidence that matters is whatever shows each testing paragraph was met, and the tripartite findings show where assessors found it missing.
The control population and the testing plan against it: which controls exist, which technique tests each one and when (CPG 234 paragraph 78).
The frequency rationale, written against the five factors in paragraph 27.
Scope statements and rules of engagement for each penetration test, with exclusions and the reason for each.
Tester independence and skill: who tested, who they work for, their qualifications, and confirmation that they have no operational responsibility for the controls (paragraph 30).
Success criteria and retest rules, defined before the test (CPG 234 paragraph 81).
The full reports, with a stated severity method and the combined effect of findings.
The findings register, with owner, due date and status, and proof that results were "reported to the appropriate governing body or individual, with associated follow-up actions formally tracked and reported" (paragraph 81).
Escalation records for anything that could not be fixed in time (paragraph 29), and any paragraph 36 notification to APRA.
Retest reports that confirm closure.
The annual sufficiency review of the program (paragraph 31), and the trigger log for material changes.
For each third party, the assessment of its testing under paragraph 28 and of its assurance under paragraph 34.
Retained test evidence. APRA found evidence "is not retained" often enough to list it twice in 2023.
Board reporting closes the loop. CPG 234 says a Board could "regularly seek assurance from and, as appropriate, challenge management on the sufficiency of testing coverage across the control environment", and Attachment H suggests reporting penetration testing "by type, count and finding rating".
For vendors: scoping a test and answering the CPS 234 question
A vendor meets CPS 234 as a section of a security questionnaire, a set of contract clauses and, for material service providers, a recurring evidence request. The customer is trying to complete its own paragraph 16, 22 and 28 assessments. Give it what those paragraphs need.
Scope the test around the customer's information assets
Test the service the customer uses, in the configuration it uses: the web application, its APIs, the mobile app if there is one, the admin console and the cloud environment behind them.
Put authentication and tenant isolation in the scope statement by name. Customer authentication is where APRA's 2025 letter and 2026 court case both landed, and for a multi-tenant product the first question is whether one customer can reach another's data. Our multi-tenant SaaS scope guide lists the checks.
Include the connections to the customer: single sign-on, file transfer, webhooks and partner APIs. CPG 234 treats "connections to service providers and customers" as untrusted environments.
Cover what you rely on. CPS 230 asks the entity about fourth parties that a material service provider depends on, so say which sub-processors and hosting layers were inside the test boundary and which were not.
Use an independent firm and name it. The customer has to weigh the independence of any assurance it relies on (CPG 234 paragraph 19), and paragraph 30 is the yardstick it already applies to its own testing.
Set a cadence you can state in one sentence: at least annually and after material change, with internet-facing components tested more often.
Buy the retest. A report with open Highs and no retest raises a paragraph 29 question for the customer.
Our guide to scoping a penetration test covers the mechanics.
What the questionnaire asks, and what to hand over
What the customer asks | The paragraph behind it | What answers it |
|---|---|---|
Do you run independent penetration testing, how often, and who performs it? | CPS 234 paragraph 28, with paragraph 30 as the yardstick for independence | The testing firm's name, test dates, cadence and a statement of independence |
What was in scope? | Paragraph 28; CPG 234 paragraph 19 on "scope, depth and independence" | The scope statement: applications, APIs, cloud accounts, environments, user roles |
Can we see the results? | Paragraphs 22 and 28; CPS 230 paragraph 53 on audit access | An executive summary or attestation letter from the testing firm, and the full report under NDA where the contract requires it |
Were the findings fixed? | Paragraph 28, and the customer's own paragraph 29 duty if a deficiency stays open | The retest report, with dates and any open items and their target dates |
What triggers a new test? | Paragraphs 27(e) and 31 | Your written testing policy: annual minimum, material change triggers |
Do you scan for vulnerabilities between tests? | CPG 234 Attachment G | Scan frequency and remediation targets |
Will you tell us about a control weakness? | Paragraph 36, because the customer has 10 business days once it becomes aware | A notification clause and a named contact |
The middle column is our mapping of each question to the paragraph that prompts it; customers word these questions in their own ways.
A direct answer to the core question can be three sentences long:
Our production web application, APIs and cloud environment are penetration tested at least annually and after material changes by an independent CREST-accredited firm with no role in operating our controls. The last test ran from [date] to [date]; all High and Critical findings were remediated and retested on [date]. The attestation letter and executive summary are attached, and the full report is available under NDA.
Three things weaken an answer. A SOC 2 report or ISO 27001 certificate offered instead of test results invites the paragraph 19 question about scope and depth, because it may not test the application's own controls. The Bendigo facts describe that gap for infrastructure assurance reports. A self-assessment without independent evidence is the exact pattern APRA criticized in 2021 and 2023. And a test more than a year old sits outside the "at least annually" expectation in CPG 234.
The questionnaire usually asks more than testing questions. For the rest of the pack, see our guides to the completion letter versus the full report, the right-to-test clause for when a customer wants to test you itself, and the report that unblocks an enterprise security review.
Common mistakes
Calling one annual penetration test "the CPS 234 testing program". The program is the map of controls to tests. The penetration test is one line in it.
Testing the same assets every year. APRA named this in 2024. Rotate coverage and record why each asset is in or out.
Logging findings without escalating them. Paragraph 29 needs a rule for when an open finding goes to senior management or the Board, and the rule has to be applied: in the Bendigo facts the findings were not assessed against the bank's escalation matrix before the attack.
Reading one rating at a time. Findings that are moderate alone can combine into a serious attack path; assess and escalate them together.
Relying on vendor self-assessments. APRA has criticized survey-based assurance twice.
Accepting an assurance report without reading its scope. An infrastructure report does not test an application.
Skipping the retest. CPG 234 expects success criteria that include "the circumstances under which re-testing would be required".
Letting the operator test its own control. That fails "functionally independent".
Forgetting the annual sufficiency review and the material change trigger in paragraph 31.
Missing the APRA clock. A test that reveals a material weakness the entity cannot fix in a timely manner starts the 10 business days in paragraph 36.
Believing a provider's "APRA-approved" badge. No such status exists under CPS 234.
CPS 234 next to other financial regulators' rules
CPS 234 sits at the principles end of the range. Canada's OSFI Guideline B-13 names the technique, saying institutions "should also regularly perform tests and exercises, to identify vulnerabilities or control gaps in its cyber security programs (e.g., penetration testing and red teaming)", and also leaves the frequency to the institution. New York's 23 NYCRR 500.5 is the prescriptive end: "penetration testing of their information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually". A group that answers to more than one of these usually builds to the strictest and documents the CPS 234 reasoning on top. Our guides to OSFI B-13, NYDFS Part 500 and the FTC Safeguards Rule follow the same format as this one, and the requirements-by-framework matrix puts them side by side.
What it costs
CPS 234 says nothing about budget; scope decides the price. Stingrai publishes fixed prices for one web application and associated APIs on its pricing page: the Autonomous Pentest, run by Snipe with no penetration testers, is US$3,000 per assessment or US$650 a month on a 12-month plan and delivers a pentest report; the Hybrid Pentest, with penetration testers and Snipe working together, is US$6,800 per assessment or US$1,275 a month on a 12-month plan and delivers a human-validated report and an attestation letter. For CPS 234 evidence, where paragraph 30 asks about the specialists who did the testing, a Hybrid or fully human-led engagement is the stronger answer. Network, Active Directory, cloud, mobile, social engineering and red team scopes are quoted per engagement through Get a Quote. For Australian dollar market ranges and local providers, see our ranking of the top penetration testing companies in Australia.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing company offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters. Founded in Toronto, Canada in 2021, with a London office, it delivers remotely for organizations in Australia, across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
Against the CPS 234 testing paragraphs, that means:
Paragraph 30, skilled and independent. Stingrai Inc. holds CREST accreditation for Penetration Testing and AI-Enabled Penetration Testing (CREST listing). Each human-led engagement is run by two named penetration testers from a team holding OSCE³, OSWE, OSEP and CREST CRT certifications, with 18 published CVEs across the team, and reviewed by the team lead. As an outside firm, Stingrai has no operational responsibility for the controls it tests.
Paragraph 29, findings that reach someone. Findings are posted to the PTaaS portal as they are confirmed, each with a working proof of concept and prioritized remediation guidance, and can be pushed to Jira and Slack, so the people who own the fix see each finding when it is confirmed, not weeks later in a report.
CPG 234 paragraph 81, retesting. Retesting of remediated findings is included, and the retest record is the closure evidence.
Paragraph 27, cadence. Engagements run as a one-time annual test or as a continuous program that keeps testing through the year. Snipe, Stingrai's autonomous AI agent, covers web applications and associated APIs; in a Hybrid engagement, penetration testers and Snipe test together throughout.
Paragraph 28, for vendors. Every human-led and hybrid report comes with an attestation letter that a vendor can give its APRA-regulated customers, with the full report kept for NDA review.
CPS 234 and CPG 234 set no accreditation requirement for testers, and Stingrai claims no APRA status. Its part is the testing and the evidence from it. The testing program, the Board reporting and internal audit's review stay with the entity.
Frequently Asked Questions
Does APRA CPS 234 require penetration testing?
Not by name. CPS 234 never uses the words "penetration test". Paragraph 27 requires an APRA-regulated entity to "test the effectiveness of its information security controls through a systematic testing program", and paragraph 30 requires that testing be done "by appropriately skilled and functionally independent specialists". Penetration testing is named in APRA's guidance, CPG 234, which lists "security testing, including penetration testing" as a typical capability and gives penetration tests as an example testing approach for networks, detection, secure software, backups and new vulnerabilities. In practice an entity cannot easily show those controls were effectively tested without it.
What does CPS 234 paragraph 27 require?
Paragraph 27 requires a systematic testing program for information security controls, with the nature and frequency of testing commensurate with five factors: the rate at which vulnerabilities and threats change, the criticality and sensitivity of the information asset, the consequences of an information security incident, the risks of exposure to environments where the entity cannot enforce its security policies, and the materiality and frequency of change to information assets. It sets no fixed interval and names no technique.
How often does CPS 234 require testing?
CPS 234 sets no testing interval; the entity sets the frequency using the five factors in paragraph 27 and must review the sufficiency of the program at least annually under paragraph 31. APRA's guidance is more specific. CPG 234 paragraph 79 says a sufficient set of controls would be tested "at least annually", and that controls protecting information assets exposed to untrusted environments, which include the internet and connections to service providers and customers, "would typically be tested throughout the year".
Who can perform CPS 234 testing?
Anyone the entity can show is appropriately skilled and functionally independent, which are the two tests in paragraph 30. CPG 234 paragraph 82 explains that independence "includes the use of testers who do not have operational responsibility for the controls being validated". An internal team can qualify on that basis, and an external penetration testing firm usually does by default. Neither document names a certification, an accreditation or an approved list: CPS 234 and CPG 234 set no accreditation requirement for testers.
Does CPS 234 apply to vendors and service providers?
Not directly. CPS 234 binds APRA-regulated entities. It reaches vendors because paragraphs 16, 22, 28 and 34 require the entity to assess a third party's information security capability, evaluate the design of its controls, assess the nature and frequency of its control testing where the entity relies on it, and have internal audit assess its assurance. Those paragraphs apply to all information assets managed by third parties, not only outsourced material business activities. A vendor therefore answers through due diligence and contract terms, typically with a recent independent penetration test, retest results and a written testing cadence.
What is the difference between CPS 234 and CPG 234?
CPS 234 is a prudential standard, a legislative instrument whose requirements use the word "must". CPG 234 is a prudential practice guide dated June 2019 that sets out APRA's view of sound practice. APRA states that practice guides "do not themselves create enforceable requirements". The testing duties are in CPS 234 paragraphs 27 to 31. The "at least annually" expectation, the independence explanation and every mention of penetration testing are in CPG 234.
How does CPS 230 affect vendors to APRA-regulated entities?
CPS 230 Operational Risk Management took effect on 1 July 2025, with an updated version from 1 July 2026. It does not mention penetration testing. It requires entities to keep a register of material service providers, to hold formal agreements for material arrangements that include audit access and allow APRA access to information and on-site visits, and to regularly assess "the effectiveness of controls to manage the risks associated with the use of the service provider". A vendor classed as a material service provider should expect recurring requests for testing evidence under those terms.
What happened in APRA's 2026 court case about testing?
On 10 August 2026 APRA commenced Federal Court proceedings against Bendigo and Adelaide Bank over a March 2023 cyber attack on its Alliance Bank business. The agreed facts say a penetration test reported in June 2020 found weak password rules and customer number enumeration, that the findings were not escalated and were not remediated until March 2023, and that an attacker reached approximately 257 customer accounts that month. The bank admitted that it did not have a systematic testing program for those customer authentication controls. APRA's release of 11 August 2026 says the parties proposed an A$8 million penalty, subject to Court approval. As of 13 November 2026 the Court had made no judgment or penalty order, and a hearing is listed for 24 November 2026.
Does a vulnerability scan satisfy CPS 234?
Not alone. APRA's guidance treats scanning and penetration testing as different approaches for different control objectives: Attachment G of CPG 234 lists "Vulnerability scans, penetration testing" together for new vulnerabilities and names penetration tests separately for networks, detection, software and backups. APRA's August 2024 letter asks for "a variety of testing approaches" and criticizes narrow coverage. A scan-only program leaves most of those objectives untested.
When does a penetration test finding have to be reported to APRA?
When it reveals a material information security control weakness that the entity expects it cannot remediate in a timely manner. Paragraph 36 of CPS 234 requires notification "as soon as possible and, in any case, no later than 10 business days" after the entity becomes aware of it. Separately, paragraph 29 requires testing results that identify deficiencies which cannot be remediated in a timely manner to be escalated to the Board or senior management.
Related reading
Top Penetration Testing Companies in Australia (2026): Melbourne, Sydney and CREST Picks
OSFI B-13 and Penetration Testing (2026): What FRFIs and Their Critical Third Parties Need
Penetration Testing Requirements by Framework: The 2026 Matrix
Best Banking and Credit Union Penetration Testing Companies (2026)
How Often Should You Do Penetration Testing? Frequency by Framework and Risk (2026)
The Pentest and Red Team RFP Question Bank: 75 Scored Questions With Red Flag Answers
Password Spraying: How the Attack Works, Detection and Defense (2026)
Pentest Completion Letter vs Full Report: What to Share With Customers and Auditors (2026)
References
Australian Prudential Regulation Authority. Prudential Standard CPS 234 Information Security. July 2019. https://www.apra.gov.au/standards/cps-234 and https://www.apra.gov.au/sites/default/files/cps_234_july_2019_for_public_release.pdf. Source of every CPS 234 quotation on this page.
Federal Register of Legislation. Banking, Insurance, Life Insurance, Health Insurance and Superannuation (prudential standard) determination No. 1 of 2018 (F2018L01745). https://www.legislation.gov.au/F2018L01745/asmade/text. Making date and in-force status.
APRA. Prudential Practice Guide CPG 234 Information Security. June 2019. https://www.apra.gov.au/practice-guides/cpg-234. Paragraphs 16 to 19, 47, 63 to 65 and 78 to 82, and Attachments D, G and H.
APRA. Prudential Standard CPS 230 Operational Risk Management (version commencing 1 July 2026) and CPG 230. https://www.apra.gov.au/standards/cps-230 and https://www.apra.gov.au/practice-guides/cpg-230.
APRA. APRA finalises new prudential standard on operational risk. 17 July 2023. https://www.apra.gov.au/news-and-publications/apra-finalises-new-prudential-standard-operational-risk. The 1 July 2025 commencement of CPS 230.
APRA. APRA finalises targeted amendments to CPS 230 Operational Risk Management. 30 April 2026. https://www.apra.gov.au/news-and-publications/apra-finalises-targeted-amendments-cps-230-operational-risk-management
APRA. Improving cyber resilience: the role boards have to play. 23 November 2021. https://www.apra.gov.au/news-and-publications/improving-cyber-resilience-role-boards-have-play
APRA. Cyber security stocktake exposes gaps. 5 July 2023. https://www.apra.gov.au/news-and-publications/cyber-security-stocktake-exposes-gaps
APRA. Additional insights on common cyber resilience weaknesses. Letter to all APRA-regulated entities, 15 August 2024. https://www.apra.gov.au/news-and-publications/additional-insights-common-cyber-resilience-weaknesses. Also Security and adequacy of backups, letter of 3 June 2024. https://www.apra.gov.au/news-and-publications/security-and-adequacy-backups
APRA. For action: Information Security Obligations and Critical Authentication Controls. Letter to RSE licensee board chairs, 10 June 2025. https://www.apra.gov.au/news-and-publications/action-information-security-obligations-and-critical-authentication-controls
APRA. Cyber security (APRA Explains). 13 October 2025. https://www.apra.gov.au/cyber-security
APRA. Speech by APRA Member Suzanne Smith to the Financial Services and ASX Sector Assurance Forum 2025. 28 October 2025. https://www.apra.gov.au/news-and-publications/apra-member-suzanne-smiths-speech-financial-services-and-asx-sector-assurance
APRA. Bendigo and Adelaide Bank admits to breaching its BEAR obligations in relation to cyber incident. Media release, 11 August 2026. https://www.apra.gov.au/news-and-publications/bendigo-and-adelaide-bank-admits-breaching-its-bear-obligations-relation
Federal Court of Australia, VID897/2026. Australian Prudential Regulation Authority v Bendigo and Adelaide Bank Limited, Statement of Agreed Facts and Admissions. 10 August 2026, stamped copy published by APRA. https://www.apra.gov.au/system/files/2026-08/Stamped%20Statement%20of%20Agreed%20Facts%20and%20Admissions.pdf. Court file (status, order of 1 September 2026, documents filed and listings): https://www.comcourts.gov.au/file/Federal/P/VID897/2026/actions
APRA. APRA's System Risk Outlook, November 2026. 12 November 2026. https://www.apra.gov.au/news-and-publications/apras-system-risk-outlook-november-2026
Council of Financial Regulators. Revised CORIE framework and rollout. Media release 2022-03, 29 July 2022. https://www.cfr.gov.au/news/2022/mr-22-03.html. Also CORIE Framework v2.0, Appendix B: Provider Guide, July 2022. https://www.cfr.gov.au/publications/policy-statements-and-other-reports/2022/revised-corie-framework-rollout/pdf/corie-guide-providers.pdf
Office of the Superintendent of Financial Institutions. Guideline B-13, Technology and Cyber Risk Management, section 3.1.2. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
New York State Department of Financial Services. Second Amendment to 23 NYCRR 500, section 500.5(a)(1), text of 1 November 2023. https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_text_20231101.pdf
Stingrai. The State of Penetration Testing 2026 and Pricing. https://www.stingrai.io/blog/state-of-penetration-testing-2026 and https://www.stingrai.io/pricing
Talk to Stingrai
Stingrai tests the applications, APIs, cloud environments and networks that a CPS 234 testing program has to cover, and gives you the evidence a testing program needs: a dated report, an attestation letter with human-led and hybrid engagements, and a retest record, from named penetration testers at a CREST-accredited firm, as a one-time annual test or a continuous program. Get a quote or book a free discovery call.
