Blogs

Not every compliance framework treats penetration testing the same way. Some name it explicitly and set a strict schedule. Others imply it through a broader control requirement and leave the frequency to your auditor’s judgement.

Knowing which is which before you scope an engagement saves you from either under-testing and failing an audit, or over-testing and spending on evidence nobody asked for.

This guide covers penetration testing requirements across six frameworks: PCI DSS, SOC 2, ISO 27001, Essential 8, HIPAA and CPS 234. Because CyberSapiens delivers penetration testing services across all of these frameworks rather than specialising in just one, this is a comparison a single-framework provider cannot credibly write.

Penetration Testing Requirements by Framework

Six frameworks, side by side: what each one requires, how often, and what evidence auditors actually accept.

PCI DSS: The Most Explicit Requirement

Of every framework in this guide, PCI DSS is the clearest. PCI DSS Requirement 11.4 states plainly that external and internal penetration testing must be regularly performed, and it does not leave “regularly” open to interpretation. Internal and external testing is required at least annually and after any significant infrastructure or application change.

If your organisation relies on network segmentation to reduce the scope of your cardholder data environment, that segmentation must also be validated by penetration testing, and service providers must do this every six months rather than annually.

This is also the framework where Qualified Security Assessors are strictest about what counts as a genuine penetration test. Requirement 11.4 explicitly distinguishes a real penetration test from automated vulnerability scanning: a scan finds known issues, while a proper test demonstrates that a vulnerability is actually exploitable and confirms the fix works through retesting. Organisations preparing for an assessment often bring in PCI DSS compliance services specifically to close this gap between scanning and genuine testing.

SOC 2: Implied But Expected

SOC 2’s Trust Services Criteria do not contain a line that says perform a penetration test. Instead, the requirement is implied through CC7.1, which covers detecting and monitoring for vulnerabilities. In practice, most SOC 2 Type 2 auditors expect to see a recent penetration test as part of the evidence supporting this criterion, particularly for companies handling customer data at scale.

The practical takeaway: you can technically pass a SOC 2 audit without a formal pentest if your auditor accepts alternative vulnerability-detection evidence, but going into a Type 2 audit without one increases the risk of a qualified opinion on CC7.1. Annual testing aligned to your audit window is the safest default, and organisations preparing for certification typically build this into their SOC 2 compliance services engagement from the outset.

ISO 27001: Part of Technical Vulnerability Management

ISO 27001’s Annex A control A.8.8 covers technical vulnerability management, and penetration testing is the standard way organisations demonstrate they are actively identifying and addressing vulnerabilities rather than just tracking patch levels. Like SOC 2, there is no fixed clause number that says penetration test annually. Your certification body will expect to see testing evidence proportionate to your risk profile, referenced in your risk treatment plan and covered in your internal audit programme.

For most organisations pursuing or maintaining certification, annual testing, or testing after major infrastructure changes, satisfies this expectation. This is a standard part of what CyberSapiens builds into every ISO 27001 certification and implementation engagement.

Essential 8: Context-Dependent

Essential 8 is the framework where “does this require a pentest” has the least straightforward answer. The ACSC Essential Eight Maturity Model does not mandate independent penetration testing at every maturity level for every organisation. However, independent testing is increasingly required in specific contexts, most notably, NSW Government’s Cyber Security Policy mandates an annual independent assessment for suppliers at certain maturity requirements.

If your organisation is pursuing Essential 8 maturity purely as a baseline security uplift, independent testing may not be strictly required. If you are supplying to government, or your contract or insurer specifically requires independent verification, it likely is. This is worth clarifying with whoever is setting your maturity target before you scope anything through ACSC Essential Eight compliance services.

HIPAA and CPS 234

HIPAA: The Security Rule does not name penetration testing as a line-item requirement. What it does mandate is a Security Risk Analysis under 45 CFR §164.308(a)(1), and in practice, a thorough risk analysis is expected to include technical vulnerability testing. Most healthcare organisations and their business associates treat annual penetration testing as the practical way to satisfy this expectation, even though the regulation itself does not use that specific term, which is why HIPAA compliance services typically build testing in as standard.

CPS 234: APRA’s CPS 234 is the most explicit of the frameworks in this section. It requires regulated entities to maintain a testing program that includes penetration testing performed by appropriately skilled, functionally independent specialists. Unlike PCI DSS, CPS 234 does not set a fixed annually requirement in the standard itself. Instead, entities define their own risk-based testing cadence, which APRA then expects to see justified and followed.

One Test, Many Frameworks

If your organisation is pursuing more than one of these frameworks at once, which is common for SaaS companies chasing both ISO 27001 and SOC 2, or Australian companies balancing Essential 8 alongside CPS 234, you do not need a separate penetration test for each one.

A single, well-scoped engagement can produce evidence multiple auditors will accept, provided the scope covers everything each framework cares about, the full cardholder data environment for PCI DSS, customer-data-handling systems for SOC 2, your ISMS-in-scope assets for ISO 27001, and so on, and the report is structured so each piece of evidence maps clearly back to the relevant framework’s requirement. This is exactly the kind of scoping decision covered in more depth when managing multiple compliance frameworks at once.

FAQs