ANALYSIS · Reference synthesis. Based on published framework requirements; primary sources linked. Not legal advice.

The short answer: PCI DSS explicitly requires penetration testing. SOC 2, ISO 27001, and HIPAA do not name it, yet in practice you will struggle to pass an audit or clear an enterprise security review without one. The longer answer is worth having, because the difference between mandatory and merely expected changes what you buy, how often you buy it, and what the report has to prove.

PCI DSS, explicitly required

PCI DSS is the one framework that says it outright. Requirement 11.4 of version 4.0 mandates internal and external penetration testing at least once every 12 months and after any significant change to infrastructure or applications. The testing has to follow an industry-accepted methodology, cover the full cardholder data environment and its perimeter, and any exploitable finding must be corrected and then retested. Service providers carry an extra obligation: they must test their segmentation controls at least every six months, because a failure there quietly collapses the boundary the entire assessment depends on. If you handle cardholder data, this is neither optional nor annual by accident.

SOC 2, not named but expected

SOC 2 is built on the AICPA Trust Services Criteria, which describe outcomes rather than a checklist, so no line reads run a pentest. The pressure comes from two criteria in particular. CC4.1 expects you to evaluate whether your controls are operating, and CC7.1 expects you to detect vulnerabilities in your environment. A penetration test is the most direct evidence that you do both. In practice, auditors ask for a recent test, and enterprise buyers ask for it again in their security questionnaire. A Type II report also covers a window of time rather than a single day, which is why one point-in-time test carries less weight than a testing program you can show ran across the review period.

ISO 27001, implied through Annex A

ISO/IEC 27001:2022 does not mandate a pentest by name either, but two Annex A controls make it the obvious route to compliance. Control 8.8, technical vulnerability management, expects you to find and address weaknesses, and control 8.29 expects security testing during development. Combined with the standard's risk-based core and the clause 9 duty to evaluate performance, penetration testing becomes the normal way to evidence that your controls actually work rather than merely exist on paper. Certification auditors expect to see it.

HIPAA, recommended and risk-driven

The HIPAA Security Rule requires a risk analysis under 45 CFR 164.308 and a periodic technical and non-technical evaluation, but it stops short of naming penetration testing. Guidance from HHS and NIST Special Publication 800-66 treats a technical evaluation, which a pentest satisfies, as a recommended part of demonstrating due diligence for systems that handle protected health information. Not required by the letter, strongly advisable in practice.

The bottom line

• PCI DSS: Required. Internal and external testing at least every 12 months and after significant change, plus segmentation testing every six months for service providers.

• SOC 2: Not named, but expected by auditors and customers as evidence for CC4.1 and CC7.1.

• ISO 27001: Not named, expected as evidence for Annex A 8.8 and 8.29.

• HIPAA: Not required, recommended as part of the risk analysis and evaluation.

What a compliance-ready pentest report needs

Passing an audit is not only about running the test, it is about what the report proves. Whatever framework you answer to, assessors look for the same things: a clearly defined scope that matches the systems in question, a stated methodology, findings rated by severity, evidence for each finding, practical remediation guidance, and a retest confirming the important issues were actually closed. A report that lists problems without showing they were fixed tends to create audit questions rather than answer them.

How often

PCI sets a floor of once a year and after significant change, and that floor is a reasonable default for the others too. The harder truth is that annual testing leaves long gaps. Our exposure window analysis found the median vulnerability went from public disclosure to active exploitation in 26 days, well inside a yearly cycle. Compliance sets the minimum, the threat sets the case for testing more often than once.

Caveats

Framework versions change. PCI DSS is on version 4.0.1 and ISO 27001 on its 2022 revision, and your assessor's interpretation is what ultimately governs your audit. Treat this as a map, not a substitute for your QSA, auditor, or counsel.

Where this fits

If you need a penetration test for an audit or a customer's security review, that is exactly what our VAPT produces: an independent test and a report you can map to the framework you are being held to.