Penetration testing for compliance: what PCI DSS, SOC 2, ISO 27001 and HIPAA actually require

PCI DSS v4.0.1, published by the PCI Security Standards Council, is the current version. Requirement 11.4 covers penetration testing of the cardholder data environment (CDE) and the systems that can affect it. In summary:

• 11.4.1: a documented methodology based on industry-accepted approaches, covering the entire CDE perimeter and critical systems, both application and network layers, and testing performed by a qualified internal resource or qualified external party with organizational independence (it does not have to be a QSA or ASV).
• 11.4.2 and 11.4.3: internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change.
• 11.4.4: exploitable vulnerabilities and security weaknesses found are corrected according to the entity's risk ranking, and penetration testing is repeated to verify the corrections.
• 11.4.5: if segmentation is used to reduce scope, segmentation controls are tested at least every 12 months and after changes to them.
• 11.4.6: service providers test segmentation at least every six months and after changes.
• 11.4.7: multi-tenant service providers support their customers' external penetration testing.

PCI DSS also separately requires internal and external vulnerability scans at least every three months (Requirement 11.3). Scans do not satisfy 11.4, and a penetration test does not satisfy 11.3.

Not strictly. A SOC 2 report is an auditor's opinion on your controls against the AICPA's Trust Services Criteria. The criteria do not list a mandatory penetration test. Under CC4.1 (monitoring activities), one of the points of focus names penetration testing among the kinds of ongoing and separate evaluations an organization may use, and CC7.1 deals with detecting vulnerabilities. Points of focus are guidance, not a checklist of requirements.

In practice, many auditors and most enterprise customers reviewing your report expect to see a recent third-party test, and having none means you must show another way your controls are evaluated. If you are preparing for SOC 2, ask your auditor early what evidence they expect, and time the test inside your observation period.

ISO/IEC 27001:2022 is a management system standard. You assess risk, choose controls from Annex A (or justify excluding them) in a Statement of Applicability, and show those controls operate. No clause says "perform a penetration test".

Two Annex A controls are where penetration testing usually lands. 8.8, management of technical vulnerabilities, requires obtaining information about technical vulnerabilities, evaluating your exposure and taking appropriate measures. 8.29, security testing in development and acceptance, requires security testing processes in the development lifecycle. A penetration test is one of the clearest ways to evidence both, and certification auditors commonly ask how you identify vulnerabilities beyond scanning.

The current HIPAA Security Rule does not name penetration testing. It requires covered entities and business associates to conduct an accurate and thorough risk analysis of risks to electronic protected health information (45 CFR 164.308(a)(1)(ii)(A)) and to perform periodic technical and nontechnical evaluations (164.308(a)(8)). Penetration testing is a common input to both.

Sector rules increasingly name testing directly. The EU Digital Operational Resilience Act (DORA), applicable from January 17, 2025, requires financial entities to run a digital operational resilience testing programme that can include penetration tests (Articles 24 and 25), and requires entities identified by their competent authority to perform threat-led penetration testing at least every three years (Article 26). U.S. federal cloud authorizations, state financial regulators and customer contracts often impose their own testing clauses too.

Contracts are frequently the strictest source. Security questionnaires from enterprise customers often ask for an annual third-party test and a summary letter, regardless of which framework you follow.

1. Start from the strictest requirement in scope (usually PCI DSS if you handle card data) and design the scope and methodology to meet it.
2. Write the scope so it maps to each framework's boundary: the CDE for PCI DSS, the systems in your SOC 2 description, the ISMS scope for ISO 27001.
3. Ask for a report that states the dates, scope, methodology and tester independence, plus an executive summary or attestation letter you can share with customers.
4. Keep evidence of remediation and retesting. PCI DSS requires it, and other auditors look for it. See retesting and fix verification.

A compliance test is a floor, not a ceiling. The scope an auditor accepts can be narrower than the systems an attacker would target, so it is worth asking what you would test if no auditor were involved.