How Often Does Compliance Require a Penetration Test?

Most compliance frameworks that apply to Australian businesses require a penetration test at least once a year, with extra testing after any significant change. The exact frequency depends on which framework actually applies to you.

PCI DSS 4.0 sets specific testing clauses for anyone handling card payments, APRA's CPS 234 ties frequency to risk rather than a fixed calendar, and neither leaves the decision to your IT provider's judgement alone. Here is what each one actually requires, and how to work out your own minimum.

Why "Once a Year" Isn't the Full Answer

A lot of what ranks for penetration testing frequency online repeats the same generic line: test once a year and after major changes. That's directionally right but incomplete, because it treats every business as if the same clock applies.

PCI DSS 4.0 sets specific, numbered clauses with fixed cycles. APRA's CPS 234 does the opposite, it deliberately avoids a fixed number and ties frequency to your own risk profile. Knowing which regime applies to you, if either does, changes what "compliant" actually looks like.

A financial advice practice with no card processing and no APRA licence of its own might reasonably assume neither framework touches it, then find out it is a material service provider to a super fund or insurer under CPS 230, at which point that client's testing expectations flow through contractually even though the practice was never directly regulated.

PCI DSS 4.0: The Specific Clauses

If your business stores, processes or transmits card data, Requirement 11.4 of PCI DSS 4.0 is explicit. External and internal penetration testing must be performed at least once every 12 months, and again after any significant change to your infrastructure or applications. Testing must be human-led, performed by an independent and qualified tester, and must cover your entire cardholder data environment.

Segmentation testing, which confirms that your card data environment is actually isolated from the rest of your network, runs on the same 12-month cycle under clause 11.4.5, tightening to every six months for service providers under 11.4.6. Findings have to be remediated and retested, not just logged.

APRA CPS 234: Frequency Tied to Risk, Not a Fixed Date

CPS 234 takes a different approach. It requires a systematic testing program, but instead of naming a cycle, it says the nature and frequency of testing must be commensurate with:

• The rate at which vulnerabilities and threats change.
• The criticality and sensitivity of the information asset, and the consequences of an incident.
• The entity's reliance on third parties it cannot directly enforce policy over.

In practice, APRA treats annual testing as a floor, not a target. A high-risk system, or one relying on a third party that APRA-regulated entities must monitor under CPS 230, may need testing more often than once a year. Where a third party manages your information assets, you are still required to assess whether their testing is frequent enough for your risk.

What This Means If No Single Framework Applies to You

Plenty of Australian businesses fall outside both PCI DSS and CPS 234, no card processing, no APRA licence. There is no legal mandate in that case, but two things still push testing onto the calendar.

Cyber insurers increasingly ask for evidence of a recent penetration test before binding or renewing cover, and a growing number of larger clients now require their suppliers to demonstrate recent testing as part of their own vendor risk process. Annual testing, plus a retest after any major system change, is a reasonable baseline even without a framework naming it directly.

How to Set Your Own Testing Calendar

Work through these checks in order, rather than defaulting to "whenever we get around to it."

• If you store, process or transmit card data: PCI DSS 4.0 sets your minimum. Annual penetration testing, annual segmentation testing, and a retest after any significant change to infrastructure or applications.
• If you are an APRA-regulated entity, or a material service provider to one: CPS 234's risk-based standard applies. Treat annual as the floor, and reassess frequency whenever your risk profile, threat exposure, or reliance on third parties changes.
• If neither applies directly: Check your cyber insurance policy wording and any client contracts for a testing clause before you set your own calendar.

Either way, log the date, scope and findings of every test. A regulator, insurer or client asking "when was this last tested" expects a specific answer, not an estimate. See what a penetration test actually involves if you need to brief your team before commissioning one.

Written by All IT Services. All IT is a Sydney-based managed IT provider supporting financial services, not-for-profit and hospitality businesses across Australia.