Web Application Penetration Testing for Compliance: SOC 2, PCI DSS, HIPAA, and ISO 27001 Requirements

Compliance · Penetration Testing · April 2026

Your auditor said you need a penetration test. Your customer security questionnaire requires one. But which frameworks actually mandate pentesting, what exactly do they require, and how do you ensure the report satisfies the auditor? This guide maps every major compliance framework to specific pentest requirements.

💫 Key Takeaways

• PCI DSS is the only major framework that explicitly mandates penetration testing with detailed requirements (Requirement 11.4 in v4.0)
• SOC 2 does not explicitly require pentesting, but auditors almost universally expect it as evidence for Trust Service Criteria CC7.1 and CC7.2
• HIPAA requires security risk assessments and “testing of security measures” — penetration testing is the most defensible way to meet this requirement
• ISO 27001 Annex A controls A.8.8 and A.8.34 point to technical vulnerability management that auditors verify through pentest evidence
• A single well-scoped penetration test can satisfy multiple frameworks simultaneously if the report includes compliance-mapped findings
• The number one reason pentest reports fail audit scrutiny: insufficient scope documentation — auditors need to see what was tested, not just what was found

Before diving into each framework, here is a side-by-side comparison of how the four major compliance frameworks treat penetration testing. This matrix shows you at a glance where pentesting is mandatory, where it is expected, and where it is recommended.

The key insight from this matrix is that PCI DSS is the only framework that explicitly mandates penetration testing with detailed prescriptive requirements. The other three frameworks either imply it, expect it as a best practice, or leave it to the auditor’s judgment. However, in practice, nearly every SOC 2 auditor and ISO 27001 certification body expects to see penetration test results as evidence. And for HIPAA-covered entities, not conducting penetration testing creates a significant risk posture that is difficult to defend in an OCR investigation.

SOC 2 is governed by the AICPA Trust Service Criteria (TSC). The criteria do not use the phrase “penetration testing.” What they require is that organizations monitor their systems for vulnerabilities and test security controls. Specifically, CC7.1 requires detection and monitoring of security events, and CC7.2 requires the organization to monitor system components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives.

In practice, this means auditors look for evidence that you are actively testing your security controls, not just assuming they work. Penetration testing is the most commonly accepted form of this evidence. In our experience working with dozens of SOC 2 audits, the auditor will specifically ask: “Do you conduct penetration testing? How often? Can we see the most recent report and evidence of remediation?”

What the auditor expects to see in the penetration test report depends on the Trust Service Criteria in scope. For the Security criterion (which is always in scope), the pentest should cover access controls, authentication mechanisms, encryption in transit and at rest, and vulnerability identification. If Availability is in scope, the report should address denial-of-service resilience. If Confidentiality is in scope, it should cover data exposure and information leakage testing.

The critical requirement: Your pentest must cover all systems within your SOC 2 audit scope. If your SOC 2 boundary includes a web application, an API, and the underlying infrastructure, then a pentest that only tests the web application will leave a gap that the auditor will flag. Ensure your scope statement in the pentest report aligns with the system description in your SOC 2 report.

PCI DSS version 4.0 (Requirement 11.4, formerly 11.3 in v3.2.1) is the most detailed and prescriptive penetration testing requirement in any major compliance framework. It does not merely suggest penetration testing — it dictates exactly what must be tested, how often, and what qualifications the tester must hold. If you process, store, or transmit cardholder data, this requirement applies to you.

Here are the specific requirements under PCI DSS v4.0 Requirement 11.4:

11.4.1: Penetration testing methodology. You must define, document, and implement a penetration testing methodology. The methodology must include industry-accepted approaches (NIST SP 800-115, OWASP Testing Guide, PTES, or equivalent). It must cover the entire cardholder data environment (CDE) perimeter and all critical systems. Both network-layer and application-layer tests are required. The methodology should address threats and vulnerabilities experienced in the last 12 months.

11.4.2: Internal penetration testing. Internal penetration tests must be performed at least annually and after any significant infrastructure or application changes. The tests must cover the internal network, not just internet-facing systems. This is a requirement that many organizations miss — they commission external-only penetration tests and assume they are compliant.

11.4.3: External penetration testing. External penetration tests must also be performed annually and after significant changes. These tests focus on the internet-facing perimeter of the CDE, including web applications that handle card data, payment pages, and any internet-facing API endpoints.

11.4.4: Segmentation testing. If network segmentation is used to reduce PCI DSS scope, the penetration test must verify that segmentation controls are effective and isolate the CDE from out-of-scope networks. This is one of the most commonly failed requirements — the pentest must actively attempt to break out of the CDE and confirm that segmentation holds.

11.4.5: Remediation and retesting. All exploitable vulnerabilities discovered during penetration testing must be corrected and the fixes verified through retesting. You cannot simply accept risk on PCI pentest findings — they must be remediated and re-verified.

The HIPAA Security Rule (45 CFR Part 164, Subpart C) does not use the words “penetration testing.” However, it contains several provisions that make penetration testing the most defensible approach to compliance. Specifically, the Security Rule requires covered entities and business associates to:

§164.308(a)(1)(ii)(A) — Risk Analysis: Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI). A penetration test is the most thorough form of technical risk analysis available.

§164.308(a)(8) — Evaluation: Perform a periodic technical and nontechnical evaluation that establishes the extent to which security policies and procedures meet the requirements of the Security Rule. Penetration testing directly evaluates whether technical security controls actually work under adversarial conditions.

§164.312(a)(1) — Access Controls: Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to authorized persons or software programs. Penetration testing is the only reliable way to verify that access controls work as intended, especially for complex web applications and APIs.

The HHS Office for Civil Rights (OCR) has consistently emphasized that organizations should use penetration testing as part of their risk analysis process. In enforcement actions following HIPAA breaches, the OCR has repeatedly cited the failure to conduct adequate security testing as a contributing factor. Organizations that can demonstrate regular penetration testing are in a significantly stronger position during OCR investigations.

Scope for HIPAA pentesting: Focus on every system that creates, receives, maintains, or transmits ePHI. This includes patient portals, EHR integrations, telehealth platforms, claims processing systems, and any APIs that exchange health data. Don’t forget business associate systems — if a third-party vendor handles ePHI on your behalf, their systems should be tested as well (or you should require evidence of their own penetration testing).

ISO 27001:2022 takes a risk-based approach to information security. The standard itself (clauses 4-10) establishes the information security management system (ISMS), while Annex A provides the reference control set. Several Annex A controls are directly addressed through penetration testing:

A.8.8 — Management of technical vulnerabilities: Organizations must obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures. Penetration testing is the most comprehensive method for identifying technical vulnerabilities in your live systems. While vulnerability scanning satisfies part of this control, penetration testing provides the exploitation context and impact assessment that scanning alone cannot.

A.8.34 — Protection of information systems during audit testing: This control addresses how audit testing (including penetration testing) should be planned and controlled to minimize impact on business operations. It implicitly acknowledges that penetration testing is an expected audit activity.

A.5.36 — Compliance with policies, rules, and standards: Regular reviews of compliance with the organization’s information security policy must be conducted. Penetration testing verifies that security policies translate into effective technical controls.

A.8.9 — Configuration management: Configurations of hardware, software, services, and networks must be established, documented, and maintained. Penetration testing validates that configurations are secure in practice, not just on paper. We frequently find systems where the documented configuration is secure but the deployed configuration has drifted.

ISO 27001 certification bodies (registrars) will review your Statement of Applicability (SoA) and verify that you have evidence for each applicable control. For the controls listed above, a penetration test report is the most commonly accepted evidence. Without one, you will need to demonstrate alternative controls that provide equivalent assurance, which is often more difficult than simply conducting the pentest.

The good news: if you scope and structure your penetration test correctly, a single engagement can satisfy SOC 2, PCI DSS, HIPAA, and ISO 27001 simultaneously. The key is ensuring the report contains the right elements for each framework. Here is what each auditor looks for:

Explicit scope documentation. The pentest report must clearly state which systems, networks, and applications were tested. Auditors cross-reference this against your compliance boundary. If your SOC 2 scope includes your production web application, API, and cloud infrastructure, all three must appear in the pentest scope statement. For PCI DSS, the scope must explicitly mention the cardholder data environment.

Methodology reference. PCI DSS requires an industry-accepted methodology. Even if SOC 2 and HIPAA don’t mandate a specific methodology, referencing OWASP, PTES, or NIST SP 800-115 adds credibility. Include a section in the report that describes the methodology used, the tools employed, and the testing approach (black-box, gray-box, or white-box).

Risk-rated findings with business context. Every finding should include a severity rating (Critical, High, Medium, Low, Informational) with a clear explanation of potential business impact. HIPAA auditors specifically want to understand the risk to ePHI. PCI DSS assessors want to know the risk to cardholder data. SOC 2 auditors want to see findings mapped to Trust Service Criteria. A well-written finding achieves all three by describing the technical vulnerability, the exploitation scenario, and the data at risk.

Evidence of remediation. All four frameworks require evidence that identified vulnerabilities have been addressed. The pentest report should include a remediation status section, ideally updated after retesting, showing which findings have been fixed, which are in progress, and which have been accepted with a risk acceptance rationale. PCI DSS is the strictest here — exploitable vulnerabilities must be corrected and retested, not risk-accepted.

Compliance mapping appendix. The most audit-ready pentest reports include an appendix that maps findings to specific compliance controls. For example: “Finding #3 (Broken Access Control) relates to SOC 2 CC6.1, PCI DSS Requirement 7.2, HIPAA §164.312(a)(1), and ISO 27001 A.8.3.” This mapping saves the auditor significant time and demonstrates that the pentest provider understands your compliance obligations.

1. Testing too late in the audit cycle. If your SOC 2 observation period ends in December and you schedule your pentest in November, there is no time to remediate findings and retest before the auditor reviews evidence. Schedule your pentest at least 3 months before the end of your observation period. This gives you 6–8 weeks for remediation and retesting, plus a buffer for scheduling delays.

2. Scope mismatch with audit boundary. The pentest scope must align with your compliance scope. If your SOC 2 includes systems A, B, and C, but your pentest only tested system A, the auditor will flag systems B and C as untested. We see this frequently when organizations have expanded their service offering but haven’t updated their pentest scope to match.

3. Using automated scan results as a “penetration test.” Automated vulnerability scanning is not penetration testing. Most auditors can immediately identify a scan report masquerading as a pentest report. Scan reports list known CVEs and configuration issues. Pentest reports describe exploitation scenarios, demonstrate business impact, and document manual testing of business logic, authentication, and authorization controls. If your report consists primarily of tool output, the auditor will likely request a proper penetration test.

4. No remediation evidence. The pentest is only half the equation. Auditors want to see a complete vulnerability lifecycle: identification, assessment, remediation, and verification. Keep records of your remediation tickets, code changes, and retest results. For PCI DSS, this is mandatory, not optional.

5. Using an unqualified provider. While most frameworks do not mandate specific certifications, auditors look for indicators of competence. Does the provider follow a recognized methodology? Do they employ certified testers (OSCP, CREST, GPEN)? Can they provide references from organizations in your industry? A report from an unqualified provider may not withstand auditor scrutiny.

6. Testing production with no change control. Penetration testing can be disruptive, particularly when testing for denial-of-service vulnerabilities or performing heavy authentication testing. Auditors want to see that you managed the testing process with appropriate change control — including a signed rules of engagement document, emergency contacts, and a clear go/no-go decision process.

7. Not testing after significant changes. Both PCI DSS and ISO 27001 require retesting after significant changes to the environment. If you deployed a new payment page, migrated to a new cloud provider, or added a new customer-facing API between annual pentests, you need an interim test covering those changes. Annual-only testing is a minimum, not a ceiling.

Here is a realistic timeline for a compliance-driven penetration test. Plan backward from your audit date to ensure everything is complete with time to spare.

Total timeline: 6–12 weeks from scoping to final report. For organizations subject to PCI DSS, add additional time for segmentation testing and internal network penetration testing. For HIPAA-covered entities, factor in time for testing business associate integrations if they fall within your scope.

The most common scheduling mistake we see is organizations contacting pentest providers 4 weeks before their audit. By the time scoping, scheduling, testing, and remediation are completed, the audit deadline has passed. Start the process at least 3 months before your audit observation period ends. For PCI DSS, where both internal and external tests plus segmentation validation are required, start 4–5 months ahead.

Need a Compliance-Ready Penetration Test?

We deliver pentest reports designed to satisfy SOC 2, PCI DSS, HIPAA, and ISO 27001 auditors. Every report includes compliance mapping, remediation guidance, and complimentary retesting. Tell us which frameworks you need to satisfy and we will scope accordingly.