Penetration Testing for Compliance in Australia
Every few weeks someone calls us holding a penetration test report that cost them real money, and it’s the wrong report. The testing was fine. The findings were fine. It just doesn’t answer the question their auditor asked, so now they’re paying twice.
That happens because “we need a pen test” is where most of these conversations start, when the actual question is “which framework are we evidencing, and what does it expect?” Six of them matter in Australia: APRA CPS 234, ISO/IEC 27001:2022, PCI DSS, the Privacy Act 1988 (APP 11), the ASD Essential Eight and the SOCI Act. Each one phrases the requirement differently. Two of them put a number on it. One never says the words “penetration testing” at all.
Here’s what each one actually wants, with links to the source documents so you can check us.
Why Penetration Testing Sits at the Centre of Australian Compliance
The shift over the last few years has been from policy to proof. It’s no longer enough to have a document saying you manage security risk. Regulators, auditors, cyber insurers and boards want evidence that someone independent tried to break in and wrote down what happened.
Penetration testing is how that evidence gets produced. You’ll also see it called ethical hacking, or VAPT, or just “the annual test” if your compliance calendar has been running a while.
The trap is assuming one test covers everything. Scope, depth, tester independence and reporting format all shift depending on who’s going to read the report. A test scoped for an ISO 27001 surveillance audit will not satisfy a PCI QSA, and neither one automatically tells your board where you sit on the Essential Eight maturity model.
What Auditors Actually Check When They Ask Who Tested You
Before the frameworks, a word on providers. When procurement or an audit committee asks “who did your penetration testing?”, they’re checking a short list:
- CREST accreditation. An independent assessment of the provider’s methodology, tester competency, quality assurance and data handling. Borderless CS holds it twice over, through CREST ANZ and CREST International.
- The tester’s own certifications. ISO/IEC 27001:2022, ISO 9001:2015, ISO 45001:2018, SOC 2 Type II. If a firm is auditing your controls, its own house should be in order.
- Manual testing, not just a scan. A vulnerability scan is a starting point, not a penetration test. CPS 234, PCI DSS and any CREST-scope engagement expect a human chaining findings together the way an attacker would.
- Professional indemnity and cyber insurance. Regulated entities increasingly want to see the certificates before anyone touches a production system.
- A report your compliance team can hand over without rewriting it. This one gets underrated until the week before an audit.
Miss the first item and you can end up re-testing. We’ve seen an insurer reject a report because the testing firm couldn’t evidence an independently assessed methodology. The work was probably sound. It just couldn’t be proven to someone who wasn’t in the room.
1. APRA CPS 234: Information Security (Banks, Insurers, Super Funds)
CPS 234 is the Australian Prudential Regulation Authority’s information security standard. It binds ADIs, general and life insurers, private health insurers and super trustees, and it reaches into their supply chains too, which catches a lot of organisations by surprise.
The standard asks regulated entities to test the effectiveness of their information security controls through a systematic testing program. The phrase that matters is who does the testing: appropriately skilled and functionally independent specialists.
That’s the whole reason accreditation comes up in APRA conversations. A CREST-accredited penetration test settles both halves of that phrase before anyone has to argue about it. Skill is independently assessed. Independence is structural. Your audit committee gets a clean answer instead of a debate.
Frequency is risk-based rather than fixed, but in practice most APRA-regulated entities we work with test annually and after any material change to a customer-facing system.
Sources: APRA: CPS 234 Information Security | APRA Prudential Handbook: CPS 234
2. ISO/IEC 27001:2022: The Standard That Never Says "Penetration Testing"
Search ISO/IEC 27001:2022 for the phrase “penetration testing” and you won’t find it. That trips people up.
What you will find is Annex A control 8.29, security testing in development and acceptance, sitting alongside 8.8 on the management of technical vulnerabilities. Between them they expect you to test systems for exploitable weaknesses before you ship and after you deploy. Certification auditors and surveillance auditors then ask how you do that, and a penetration test report is the answer almost everyone gives, because writing one from scratch in any other form is harder.
If you’re heading into a Stage 2 certification audit, get the testing done early enough that you can close the high findings first. Turning up with an unremediated critical is a bad look that costs you nothing to avoid.
3. PCI DSS: The One With Hard Dates
If you store, process or transmit cardholder data, PCI DSS applies, currently at version 4.0.1. Requirement 11.4 is refreshingly blunt about it:
- A penetration test at least once every 12 months
- Another one after any significant change to the cardholder data environment
- Segmentation testing every six months, if you’re using segmentation to shrink your PCI scope
That six-monthly segmentation requirement is the one teams miss most often. It’s easy to book the annual test, forget the segmentation check, and find out during your assessment.
The fix is unglamorous: put both in the calendar as recurring events and scope the penetration testing engagement around the CDE boundary rather than around whatever was tested last year.
4. Privacy Act 1988 and APP 11: Proving "Reasonable Steps"
Australian Privacy Principle 11 requires you to take “reasonable steps” to protect personal information. Reasonable is doing a lot of work in that sentence, and the OAIC’s own guidance fills it in: regular security testing, penetration testing included, is listed as evidence of taking those steps.
Where this bites is after a breach. Under the Notifiable Data Breaches scheme, you’ll be explaining what you did beforehand. “We never tested it” is a difficult position to argue from once the vulnerability is public and the OAIC is asking.
Health data raises the bar again, because the Privacy Act treats it as sensitive information and layers state health records legislation and TGA obligations on top. If you build clinical software or integrate with My Health Record, we’ve written that up separately in our guide to penetration testing for healthcare software developers in Australia.
5. ASD Essential Eight: Testing Whether the Controls Hold
The Essential Eight is the ACSC’s baseline: application control, patching applications, patching operating systems, Office macro settings, user application hardening, restricting admin privileges, multi-factor authentication and regular backups. Mandatory for non-corporate Commonwealth entities, strongly recommended for everyone else, and assessed across maturity levels 0 to 3.
Most Essential Eight assessments are documentary. Someone checks the configuration, ticks the control, records a maturity level. That’s a reasonable start, and it’s also where the gap opens up.
Application control that’s enabled but bypassable through a writable directory still ticks the box. MFA that can be dodged on a legacy authentication endpoint still ticks the box. Penetration testing is what turns “configured” into “verified”, and if you’re reporting a maturity level to a board or a government customer, that difference is the one that eventually matters.
6. SOCI Act 2018: Critical Infrastructure and CIRMP
The Security of Critical Infrastructure Act 2018 covers responsible entities across eleven sectors: energy, water, communications, healthcare, financial services, transport, food and grocery, data storage, defence, higher education and research, and space technology. The 2021 and 2022 amendments added mandatory incident reporting timeframes and the Critical Infrastructure Risk Management Program, known everywhere as CIRMP.
CIRMP asks you to identify and mitigate material risks to your asset, then review the program regularly. Independent penetration testing of the systems supporting that asset is one of the cleaner pieces of evidence you can put into that review, and the Cyber and Infrastructure Security Centre references it directly in its guidance.
One practical note. Plenty of SOCI-covered organisations are also APRA-regulated or handle card data. Scope once, test once, report against all of them. There’s no prize for running three separate engagements.
Framework-to-Testing Quick Reference
| Framework | Who It Applies To | Testing Cadence |
|---|---|---|
| APRA CPS 234 | Banks, insurers, super funds and their suppliers | Risk-based, typically annual |
| ISO/IEC 27001:2022 | Any certified organisation | Annual, plus after major change |
| PCI DSS 4.0.1 | Anyone handling cardholder data | Annual, segmentation testing 6-monthly |
| Privacy Act (APP 11) | APP entities handling personal information | Regular, risk-based |
| ASD Essential Eight | All Australian orgs, mandatory for non-corporate Commonwealth entities | Aligned to maturity review cycle |
| SOCI Act 2018 | Responsible entities, 11 critical infrastructure sectors | Regular CIRMP review cycle |
Which Engagement Do You Actually Need?
Two questions decide it. What’s in scope, and who’s going to read the report.
If you’re scoping by asset, start with our penetration testing services. That page covers web applications, APIs, external and internal networks, cloud environments, mobile apps and wireless, along with how we scope, how findings get risk-rated, and how retesting works. It’s the right entry point for ISO 27001 preparation, an Essential Eight uplift, or testing a product before launch.
If the report is going somewhere it’ll be scrutinised, go to CREST-accredited penetration testing. An APRA-facing audit committee, a PCI QSA, a cyber insurer, a government procurement panel: these readers want the provider assessed, not just the systems. Under CPS 234, PCI DSS or the SOCI Act, that’s where to start.
Lots of engagements sit across both, which is fine. What matters is agreeing the framework mapping before testing begins rather than after.
What “CREST-accredited” actually means — and why it matters more in healthcare
CREST-accredited penetration testing is delivered by an independently accredited provider with demonstrated standards for technical capability, methodology and quality assurance. It matters everywhere, but it matters more in healthcare for a specific reason: several of the gatekeepers above — platform partner programmes, government conformance processes, hospital procurement panels — either name CREST accreditation explicitly or treat it as the default evidence of “independent” testing performed to a defensible standard.
A generic vulnerability scan, or a test from a provider without third-party accreditation, often won’t satisfy these gates at all. You end up doing the work twice — once to tick a box, and again properly when a platform or agency rejects the first report.
How We Run Compliance-Ready Penetration Testing
We scope against the framework you’re reporting against, not a template. The testing itself covers web applications, APIs, internal and external networks, cloud, mobile and wireless, with manual exploitation rather than a scanner and a cover page. Findings come back risk-rated, with the reasoning behind each rating, in a format built for whoever’s receiving it.
On credentials: dual CREST accreditation through CREST ANZ and CREST International, ISO/IEC 27001:2022, ISO 9001:2015 and ISO 45001:2018 certification, SOC 2 Type II attestation, GDPR-aligned data handling, and Public and Products Liability, Professional Indemnity and Cyber cover sized for regulated-sector work.
Our CEO and Director of Cybersecurity Practice, Jayaprakash Muthusamy, sits on the Board of Directors of CREST ANZ, which means we see where accreditation and testing standards are heading across the region rather than finding out when the requirements change.
We’re based in Melbourne, with offices in Sydney, Brisbane and Fiji, and the testers are local.
Talk to our penetration testing team about scoping against CPS 234, ISO 27001:2022, PCI DSS, the Privacy Act, the Essential Eight or the SOCI Act. Tell us which audit is coming and when, and we’ll work backwards from there.
This article was reviewed by cybersecurity professionals experienced in penetration testing, compliance frameworks, and Australian cyber security regulations.
Frequently Asked Questions
1. Is penetration testing mandatory under APRA CPS 234?
CPS 234 doesn’t list penetration testing by name. It requires you to test the effectiveness of your information security controls using specialists who are appropriately skilled and functionally independent of the control being tested. In practice that means an independent penetration test, at a frequency that matches your risk profile.
2.Does CREST accreditation matter, or will any tester do?
No Australian framework makes CREST mandatory. Several require testers to be demonstrably skilled and independent, and CREST is the recognised way to evidence that without a debate. Auditors, QSAs, insurers and government procurement panels increasingly name it in requirements. Here’s what CREST accreditation actually covers and how it differs from a standard vulnerability assessment.
3. How often does PCI DSS require penetration testing?
At least once every 12 months, plus after any significant change to the cardholder data environment. If you rely on segmentation to reduce PCI scope, add segmentation testing every six months. That’s Requirement 11.4 of PCI DSS v4.0.1.
4. Does ISO/IEC 27001:2022 require penetration testing?
Not in those words. Annex A control 8.29 (security testing in development and acceptance) and 8.8 (management of technical vulnerabilities) are the relevant controls, and penetration testing is how most organisations evidence them. Certification auditors routinely ask to see the report.
5. What is the ASD Essential Eight and is it mandatory?
Eight baseline mitigation strategies from the Australian Cyber Security Centre, assessed against maturity levels 0 to 3. Mandatory for non-corporate Commonwealth entities and strongly recommended for everyone else. Penetration testing is how you verify the controls hold up rather than just exist.
6. Do I need to comply with the SOCI Act?
It applies to responsible entities for assets across eleven critical infrastructure sectors named in the Act. Obligations vary by sector and asset class, so check your status against the Cyber and Infrastructure Security Centre’s guidance rather than assuming.
7. Can one penetration test satisfy more than one framework?
Usually yes, if it’s scoped that way from the start. The technical testing overlaps heavily. What differs is the scope boundary and how findings are presented. Tell your tester every framework you report against before scoping, and you’ll normally get one engagement instead of three.
8. How does penetration testing support Privacy Act APP 11 compliance?
APP 11 requires reasonable steps to protect personal information, and the OAIC’s guidance lists regular security testing as evidence of those steps. It also shapes your position under the Notifiable Data Breaches scheme if a breach ever happens.
