APRA CPS 234 security testing requirements — control testing, tester independence and what CPG 234 says about penetration testing

Prudential Standard CPS 234 Information Security applies to all APRA-regulated entities:

• Authorised deposit-taking institutions (ADIs), including foreign ADIs, and authorised banking non-operating holding companies (NOHCs).
• General insurers, including Category C insurers, authorised insurance NOHCs and parent entities of Level 2 insurance groups.
• Life companies, including friendly societies and eligible foreign life insurance companies (EFLICs), and registered life NOHCs.
• Private health insurers registered under the PHIPS Act.
• RSE licensees under the SIS Act, in respect of their business operations.

For a foreign ADI, a Category C insurer or an EFLIC, the obligations apply only to the Australian branch operations. An entity that is the Head of a group applies the requirements throughout the group, including to entities that are not APRA-regulated. The standard commenced on 1 July 2019; for information assets managed by third parties it applied from the next contract renewal or 1 July 2020, whichever came first, so every in-scope asset is now covered.

The standard applies to information assets managed by related parties and third parties as well, which matters for testing: if a service provider tests the controls on your assets and you rely on that testing, paragraph 28 makes you assess whether its nature and frequency meet the same criteria as your own.

Under the heading Testing control effectiveness:

• Para 27: test the effectiveness of information security controls through a systematic testing program. Its nature and frequency must be commensurate with (a) the rate at which vulnerabilities and threats change, (b) the criticality and sensitivity of the information asset, (c) the consequences of an incident, (d) the risks of exposure to environments where the entity cannot enforce its security policies (untrusted environments), and (e) the materiality and frequency of change to information assets.
• Para 28: where a related party or third party manages the assets and you rely on its testing, assess whether that testing is commensurate with 27(a) to (e).
• Para 29: escalate and report to the Board or senior management any test results that identify control deficiencies that cannot be remediated in a timely manner.
• Para 30: ensure that testing is conducted by appropriately skilled and functionally independent specialists.
• Para 31: review the sufficiency of the testing program at least annually or when there is a material change to information assets or the business environment.

Three nearby paragraphs complete the picture:

• Para 26: review and test information security response plans annually.
• Paras 32 to 34: internal audit reviews the design and operating effectiveness of controls, including those maintained by related and third parties, with appropriately skilled personnel, and assesses third-party assurance it intends to rely on where an incident could materially affect the entity or its customers.
• Paras 35 and 36: notify APRA no later than 72 hours after becoming aware of a material information security incident, and no later than 10 business days after becoming aware of a material control weakness the entity expects it will not be able to remediate in a timely manner.

Paragraph 36 is the one that links testing to the regulator. A penetration test that finds a material weakness on a critical system is not only a finding; if the fix will take longer than is timely, it starts a notification clock.

Prudential Practice Guide CPG 234 (June 2019) is APRA's view of sound practice. APRA states that practice guides discuss requirements from legislation and prudential standards but do not themselves create enforceable requirements. They show what a supervisor will compare you against.

• Frequency. In APRA's view the frequency and scope of testing would ensure that a sufficient set of information security controls is tested at least annually, and controls protecting information assets exposed to untrusted environments, including the internet and connections to service providers and customers, would typically be tested throughout the year. Additional testing can be triggered by changes to vulnerabilities, threats or information assets.
• Design. An entity would normally outline the population of its controls and keep a program that validates their design and operating effectiveness over time. Success criteria are defined in advance, including when re-testing is required, and results are reported with follow-up actions formally tracked.
• Independence. Testers should be sufficiently independent to give a bias-free assessment, unimpeded by a conflict of interest, which includes using testers who do not have operational responsibility for the controls being validated. The level of independence depends on the nature and importance of the test.
• Techniques (Attachment G). Penetration tests for network protection; penetration tests including more advanced techniques commonly referred to as “red team” tests for timely detection of unauthorised access; design reviews, penetration tests, code review and scanning and fuzzing for secure software; a penetration test of the backup environment; and vulnerability scans and penetration testing for timely identification and remediation of new vulnerabilities.
• Capability and reporting. Security testing, including penetration testing, is listed among the capabilities an entity typically maintains, and Attachment H lists “penetration testing (by type, count and finding rating)” among the metrics commonly reported to Boards and management.
• Internal audit reliance. Where internal audit relies on control testing performed by other areas, APRA expects it to assess the scope and quality of that testing.

Binding, in CPS 234:

• A systematic testing program whose nature and frequency follow the five criteria in paragraph 27.
• Testing by appropriately skilled and functionally independent specialists.
• An annual review of the program's sufficiency, and escalation of deficiencies that cannot be remediated in time.
• Internal audit of control design and operating effectiveness.
• Notification to APRA within 72 hours for material incidents and within 10 business days for material control weaknesses that will not be remediated in a timely manner.

APRA's expectation, in CPG 234:

• A sufficient set of controls tested at least annually, and continuous testing through the year for controls exposed to untrusted environments.
• Penetration testing and red team tests among the techniques for network protection, detection and vulnerability management.
• Testers without operational responsibility for the controls they test.

Not written in either:

• A universal annual penetration test for every system.
• An obligation to use an external firm or a certified tester. Functional independence can be achieved inside the entity, as long as the testers are not the people who run the controls.
• A mandated methodology.

1. Outline the control population, as CPG 234 suggests, and map each control to the information assets it protects and their criticality and sensitivity.
2. Pick the test type per control: vulnerability scans and penetration tests for vulnerability management and network protection, red team style tests for detection, code review and application testing for in-house software, recovery and backup environment tests for resilience.
3. Test untrusted-facing controls continuously. Internet-facing services, remote access and connections to service providers and customers are where CPG 234 expects testing throughout the year rather than once.
4. Record independence. For each test, who ran it and why they have no operational responsibility for the controls under test.
5. Define success criteria and re-test triggers before the test, and track follow-up actions to closure.
6. Write the notification decision into the process. When a finding is material and the fix will not be timely, someone must decide within days whether paragraph 36 applies and escalate under paragraph 29.
7. Review the program each year and after material change, and keep the review.

• The testing program: the control population, the test type and frequency for each group of controls, and the reasoning against 27(a) to (e).
• Test reports with scope, date, technique, success criteria, results and the testers' names and roles.
• Independence records showing that testers had no operational responsibility for the controls under test.
• Third-party testing assessments under paragraph 28 for assets managed by related or third parties.
• The findings register with remediation, re-tests, and escalations to the Board or senior management under paragraph 29.
• Paragraph 36 decisions: for each material weakness, whether it could be remediated in a timely manner, and the notification if not.
• The annual sufficiency review of the program and the internal audit reports that relied on it.
• Board reporting, for example penetration tests by type, count and finding rating, as CPG 234 Attachment H suggests.

An autonomous AI red team for networks and infrastructure does not make your testers functionally independent: paragraph 30 is about who runs and reviews the tests, not which tool they use, and that remains yours to document. It does not replace the specialist or red team tests your program calls for. It gives you a way to test the untrusted-facing controls throughout the year, as CPG 234 expects. For the category itself, see automated penetration testing.

• Continuous testing of untrusted exposure. Black-box campaigns from outside and gray-box campaigns with standard-user access, on a schedule and after changes, on the internet-facing and partner-facing systems.
• Proof for triage. Findings say whether they were proven exploitable in your environment, which helps decide quickly whether a weakness is material in the sense of paragraph 36.
• Re-test as success criterion. Each fix can be checked with the same proof that found it, so a finding closes on evidence.
• Human approval of risky steps. Five autonomy levels define what waits for an operator, and exploit proofs of concept can be held for review. See human in the loop.
• Framework mapping and records. APRA CPS 234 is one of the 34 frameworks the engine maps findings to, with exportable compliance reports; tying reports to paragraphs 27 to 31 stays in your documentation. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain per campaign, verifiable offline, which gives internal audit a record it can rely on.
• No new third party. The models run on the appliance with no external AI service, and no customer data leaves it, so testing does not create another third party whose controls you must assess under CPS 234. See on-premise AI red team and the on-premise pentest platform buyer's guide.

• APRA Prudential Standard CPS 234 Information Security, paragraphs 3-6 and 26-36 (apra.gov.au)
• APRA Prudential Practice Guide CPG 234 Information Security, June 2019 (PDF, apra.gov.au)