Penetration Testing Compliance Guide: Which Frameworks Require It and What Each Demands

"Do we need a penetration test for compliance?"

Security teams hear this question every audit cycle. The answer varies by framework, and the details matter: which systems must be tested, how often, what methodology, what qualifications the testers need, and what the report must contain. Getting any of these wrong doesn't just create a compliance gap. It wastes the testing budget on an engagement that doesn't satisfy the auditor.

The challenge is that compliance requirements for penetration testing are spread across dozens of framework documents, written in regulatory language, and frequently updated. PCI DSS explicitly mandates annual penetration testing with specific scope requirements. SOC 2 expects it without mandating it by name. ISO 27001 requires security testing without prescribing methodology. HIPAA requires risk analysis that penetration testing best satisfies. GDPR requires "regularly testing" security effectiveness. Each framework has its own language, scope definition, and expectations.

This guide maps penetration testing requirements across every major compliance framework in one place: what each framework requires, how to scope testing for each, what frequency satisfies auditors, what the report must contain, where frameworks overlap (so one test can serve multiple), and which types of penetration testing each framework expects.

The Compliance-Penetration Testing Matrix

PCI DSS: The Most Prescriptive

PCI DSS has the most explicit, detailed penetration testing requirements of any compliance framework.

What PCI DSS Requires

Requirement 11.3: Annual internal and external penetration testing of the cardholder data environment. Testing must follow industry-accepted methodology (NIST SP 800-115, PTES, OWASP).

Requirement 11.3.1: External penetration testing covering the CDE perimeter.

Requirement 11.3.1.1: Internal penetration testing covering network segmentation, Active Directory, and lateral movement paths.

Requirement 11.3.1.2: Penetration testing after significant infrastructure or application changes to the CDE.

Requirement 11.3.2: Segmentation validation if network segmentation reduces PCI scope. Testers must attempt to cross from out-of-scope networks into the CDE.

Requirement 11.2: Quarterly vulnerability scanning (internal + external ASV).

How to Scope for PCI DSS

Test every system that stores, processes, or transmits cardholder data. Include systems connected to the CDE. Validate segmentation controls isolating the CDE. Include web applications processing payments and APIs handling card data.

Testing Types Required

External penetration testing of the CDE perimeter. Internal penetration testing of the CDE and connected systems. Web application testing covering OWASP Top 10 for payment applications.

Report Requirements

Methodology documented (referencing NIST, PTES, or OWASP). Scope confirming CDE coverage. Tester qualifications. Findings with severity and remediation. Segmentation test results. Remediation evidence for identified vulnerabilities.

Deep dive: PCI DSS Penetration Testing Guide

SOC 2: Expected but Not Mandated by Name

What SOC 2 Requires

SOC 2 Trust Services Criteria don't use the words "penetration testing." However, CC4.1 (Monitoring Activities), CC7.1 (System Operations), and CC7.2 (Change Management) expect that security controls are tested and validated. Every experienced SOC 2 auditor expects penetration testing evidence.

How Auditors Evaluate

Auditors examine whether the organisation has a process for identifying and addressing security vulnerabilities. Penetration testing reports demonstrating proactive vulnerability identification and remediation directly satisfy this expectation. Organisations without pentest evidence face auditor questions about how they validate security control effectiveness.

How to Scope for SOC 2

Test all systems within the SOC 2 boundary (in-scope systems supporting the service). Include customer-facing web applications and APIs. Include cloud infrastructure hosting in-scope systems. Include network infrastructure protecting the service boundary.

Testing Types Expected

Application testing for customer-facing platforms. Infrastructure testing for hosting environments. Cloud security testing for AWS, Azure, or GCP environments.

Deep dive: SOC 2 Penetration Testing Guide

ISO 27001: Risk-Based Security Testing

What ISO 27001 Requires

ISO 27001 Annex A.8.8 (Management of Technical Vulnerabilities) requires organisations to identify and address technical vulnerabilities. Annex A.8.25 (Secure Development Life Cycle) requires secure development including testing. The standard requires "regular" assessment proportionate to risk without prescribing specific methodology.

How Auditors Evaluate

ISO 27001 auditors assess whether the ISMS includes appropriate security testing. Penetration testing reports demonstrate systematic vulnerability identification. The depth and frequency of testing should be proportionate to the organisation's risk profile as documented in the risk assessment.

How to Scope for ISO 27001

Align testing scope with the ISMS scope (the systems covered by your ISO 27001 certification). Include all systems processing information assets classified as requiring protection. Testing depth proportionate to risk classification.

Testing Types Expected

Proportionate to risk. Minimum: annual vulnerability assessment and penetration testing of highest-risk systems. Comprehensive: testing covering web applications, APIs, cloud, networks, and mobile applications.

Deep dive: ISO 27001 Penetration Testing Guide

HIPAA: Risk Analysis Best Satisfied by Pentesting

What HIPAA Requires

The HIPAA Security Rule requires risk analysis (§164.308(a)(1)(ii)(A)) identifying vulnerabilities to ePHI and periodic evaluation (§164.308(a)(8)) of security measure effectiveness. HIPAA doesn't name penetration testing but OCR enforcement actions consistently cite inadequate risk analysis when breaches occur.

How to Scope for HIPAA

Test all systems storing, processing, or transmitting electronic Protected Health Information. Include EHR systems, patient portals, healthcare APIs, cloud infrastructure hosting ePHI, internal networks providing access to ePHI systems, and mobile health applications.

Testing Types Expected

Web application testing for patient portals and clinical applications. Network testing for clinical network segmentation. Cloud testing for cloud-hosted ePHI.

Deep dive: Healthcare Penetration Testing Guide

GDPR: Article 32 Security Effectiveness Testing

What GDPR Requires

Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." Article 32(1)(a) specifically mentions encryption. DPAs evaluate whether testing was conducted when investigating breaches.

How to Scope for GDPR

Test all systems processing personal data of EU/EEA residents. Include customer-facing applications collecting personal data, APIs transmitting personal data, databases storing personal data, and cloud infrastructure hosting personal data.

Testing Emphasis

GDPR testing emphasises vulnerabilities threatening personal data: IDOR exposing other users' data, authentication bypass enabling account access, encryption validation, and data exposure through API responses.

Deep dive: GDPR Penetration Testing Guide

NIST CSF: Framework-Wide Testing Support

How Penetration Testing Maps to NIST CSF

Identify (ID.RA): Penetration testing is risk assessment, identifying vulnerabilities to organisational assets.

Protect (PR.AC, PR.DS, PR.PS): Testing validates whether protection controls resist attack.

Detect (DE.CM): Red teaming validates whether detection controls identify real attacks.

Testing depth and frequency should align with the organisation's target implementation tier.

Deep dive: NIST CSF Implementation Guide

UAE NESA: Required for Critical Infrastructure

UAE National Electronic Security Authority standards require security testing for Critical Information Infrastructure operators. NESA's control domains align with international frameworks, requiring vulnerability assessment and penetration testing proportionate to infrastructure criticality.

How to Scope for UAE NESA

Cover critical infrastructure systems, network infrastructure, and applications supporting essential services. Testing should address NESA's information assurance control domains.

UAE DIFC and ADGM

Dubai International Financial Centre and Abu Dhabi Global Market regulators expect security testing for financial institutions. Annual penetration testing demonstrating security validation satisfies regulatory expectations for financial services in the UAE.

MAS TRM (Singapore): Annual Required Testing

The Monetary Authority of Singapore Technology Risk Management guidelines require annual penetration testing for financial institutions.

What MAS Expects

Vulnerability assessment and penetration testing covering critical systems. Testing methodology following industry standards. Results documented with remediation plans. Testing frequency aligned with system criticality.

NYDFS 23 NYCRR 500

New York Department of Financial Services cybersecurity regulation requires annual penetration testing for covered entities. Quarterly vulnerability assessments. Risk-based testing programme documented in the cybersecurity policy.

EU DORA (Digital Operational Resilience Act)

DORA requires Threat-Led Penetration Testing (TLPT) for significant financial entities. TLPT follows the TIBER-EU framework with advanced red team testing simulating real threat actor techniques specific to the financial sector.

Multi-Framework Alignment: One Test, Multiple Frameworks

Most organisations maintain multiple compliance frameworks simultaneously. Well-scoped penetration testing satisfies overlapping requirements.

Common Multi-Framework Combinations

SaaS companies: SOC 2 + ISO 27001 + GDPR. One pentest covering in-scope systems with dual-framework reporting satisfies all three. See our SaaS security guide.

Healthcare SaaS: HIPAA + SOC 2 + ISO 27001. Testing covering ePHI systems with triple-framework mapping.

Financial services: PCI DSS + SOC 2 + NYDFS (+ MAS TRM for Singapore operations). Testing covering CDE and broader financial systems.

E-commerce: PCI DSS + SOC 2 + GDPR. Payment systems + customer data systems.

UAE financial: UAE NESA + DIFC/ADGM + ISO 27001 + PCI DSS. Comprehensive testing with multi-framework mapping.

How Multi-Framework Testing Works

Step 1: Map each framework's scope to your systems. Identify overlap (systems in scope for multiple frameworks).

Step 2: Define the superset scope covering all frameworks. The pentest scope is the union of all framework scopes.

Step 3: Conduct testing using methodology satisfying the most prescriptive framework (typically PCI DSS).

Step 4: Report maps findings to each framework's specific requirements. One test, one engagement, multiple compliance deliverables.

Multi-Framework Mapping Table

What Auditors Actually Check

Documentation Auditors Request

Penetration testing reports from the past 12 months. Scope documentation confirming coverage of in-scope systems. Tester qualifications (certifications, independence). Methodology documentation referencing industry standards. Remediation evidence for identified findings. Retesting confirmation that fixes work. Quarterly vulnerability scan reports (PCI DSS).

Common Audit Failures

Missing test. No penetration test conducted in the past 12 months. Immediate finding.

Scope gap. Test scope doesn't cover all in-scope systems for the framework. QSAs compare pentest scope to CDE diagram. SOC 2 auditors compare to system boundary.

Unresolved findings. Critical or high findings without remediation evidence or documented compensating controls.

Independence failure. Testing conducted by the team responsible for the tested systems rather than independent testers.

Methodology gap. Report doesn't reference industry-accepted methodology.

For report quality expectations, see our penetration testing reports guide.

Compliance Testing Frequency Guide

For detailed frequency guidance, see our guide on how often to do penetration testing.

Choosing a Compliance-Qualified Testing Provider

What to Look For

Multi-framework experience. The provider should have experience with your specific frameworks and understand what each auditor expects. See our guide on choosing penetration testing companies.

Compliance-mapped reporting. Reports should map findings to specific framework requirements without additional work from your compliance team.

Tester certifications. OSCP, CREST, GXPN demonstrate practical testing skill. Certifications that satisfy PCI DSS's "qualified" tester requirement.

Retesting inclusion. Compliance requires demonstrating remediation. Retesting must be included. See our guide on evaluating penetration testing quality.

VAPT capability. Some frameworks require both vulnerability assessment and penetration testing. The provider should deliver the complete VAPT process.

AI Systems and Compliance

AI systems processing regulated data inherit compliance requirements.

AI processing payment data: PCI DSS applies. AI penetration testing must cover AI-specific and PCI-specific requirements.

AI processing health data: HIPAA applies. See our AI security assessment guide.

AI under ISO 42001: Emerging AI-specific compliance. See our ISO 42001 AI governance guide.

AI under EU AI Act: High-risk AI requires conformity assessment. See our AI security testing best practices.

How AppSecure Delivers Compliance-Aligned Penetration Testing

AppSecure provides penetration testing designed for audit success across every framework in this guide.

Multi-Framework Reporting. Every engagement maps findings to your applicable frameworks: PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, UAE NESA, MAS TRM, NYDFS. One test, one report, multiple compliance requirements addressed.

Complete Testing Types. Web application, API, cloud, network (external and internal), mobile, and AI. Application security assessment for comprehensive coverage.

Audit-Ready Reports. Methodology documented referencing NIST, PTES, and OWASP. Tester qualifications included. Scope confirmed against compliance boundaries. Findings with severity, evidence, and framework mapping.

Zero False Positives. Manual testing validates every finding through exploitation. Auditors review confirmed vulnerabilities, not scanner output.

3-Week Delivery. 90-day remediation support. Complimentary retesting providing the remediation evidence auditors require. Continuous testing and PTaaS maintain ongoing compliance validation. Red teaming for DORA TLPT requirements.

Contact AppSecure:

• Schedule Compliance Penetration Testing
• Application Security Assessment
• What Is Penetration Testing?

Frequently Asked Questions

1. Which compliance frameworks require penetration testing?

PCI DSS explicitly mandates annual penetration testing (Requirement 11.3). NYDFS requires annual penetration testing (23 NYCRR 500). MAS TRM requires annual testing for Singapore financial institutions. DORA requires threat-led penetration testing for significant EU financial entities. SOC 2 strongly expects it without naming it. ISO 27001 requires security testing proportionate to risk. HIPAA requires risk analysis best satisfied by penetration testing. GDPR requires regularly testing security effectiveness. UAE NESA requires testing for critical infrastructure. Most frameworks either explicitly require or strongly expect penetration testing evidence.

2. Can one penetration test satisfy multiple compliance frameworks?

Yes. A well-scoped penetration test with multi-framework reporting satisfies overlapping requirements. The testing scope should be the union of all frameworks' scoped systems. The methodology should satisfy the most prescriptive framework (typically PCI DSS). The report maps findings to each framework's specific requirements. Common multi-framework combinations: SOC 2 + ISO 27001 + GDPR for SaaS companies, PCI DSS + SOC 2 for payment processors, and HIPAA + SOC 2 for healthcare SaaS.

3. How often does compliance require penetration testing?

Most frameworks require annual penetration testing at minimum. PCI DSS additionally requires testing after significant changes to the CDE. DORA requires threat-led testing per TLPT schedule. Some frameworks (HIPAA, GDPR) use "periodic" or "regular" without specifying exact frequency, with annual being the accepted standard. Higher-risk environments benefit from semi-annual testing. Continuous testing through PTaaS maintains ongoing compliance between annual assessments.

4. What must a compliance penetration testing report include?

Audit-ready reports include methodology documentation referencing industry standards (NIST SP 800-115, PTES, OWASP), scope documentation confirming coverage of in-scope systems, tester qualifications and independence confirmation, findings with severity ratings, exploitation evidence, and business impact, compliance framework mapping for each finding, remediation guidance specific to the technology stack, and retesting results confirming fix effectiveness.

5. What are common compliance audit failures related to penetration testing?

Common failures include no penetration test conducted in the past 12 months, test scope not covering all compliance-scoped systems, unresolved critical or high findings without compensating controls, testing conducted by non-independent parties (internal teams testing their own systems), report missing methodology documentation or tester qualifications, and missing quarterly vulnerability scans (PCI DSS). Each failure creates an audit finding that delays compliance certification.

6. Does SOC 2 require penetration testing?

SOC 2 Trust Services Criteria don't explicitly name "penetration testing." However, CC4.1, CC7.1, and CC7.2 expect that security controls are tested and validated. Every experienced SOC 2 auditor expects penetration testing evidence. Organizations without pentest reports face auditor questions about how they validate security effectiveness. Practically, penetration testing is expected for SOC 2 Type II compliance.

7. What is the difference between PCI DSS and SOC 2 penetration testing requirements?

PCI DSS prescribes specific requirements: annual external and internal testing, segmentation validation, testing after changes, OWASP Top 10 for web applications, and specific methodology standards. SOC 2 is principles-based: it expects security testing evidence without prescribing methodology, frequency, or scope. PCI DSS auditors verify specific testing requirements. SOC 2 auditors evaluate whether testing is adequate for the organization's risk profile. PCI DSS is more prescriptive; SOC 2 is more flexible.

8. How do I scope penetration testing for compliance?

Map each framework's scope definition to your systems. PCI DSS scope: all systems storing, processing, or transmitting cardholder data plus connected systems. SOC 2 scope: systems supporting the in-scope service. ISO 27001 scope: systems within the ISMS boundary. HIPAA scope: systems processing ePHI. GDPR scope: systems processing EU personal data. For multi-framework testing, define the superset scope covering all applicable frameworks.

9. Do AI systems require compliance penetration testing?

AI systems processing regulated data inherit compliance requirements from the data they process. AI processing payment data falls under PCI DSS. AI processing health data falls under HIPAA. AI processing EU personal data falls under GDPR. Additionally, ISO 42001 requires AI-specific risk assessment, and the EU AI Act requires conformity assessment for high-risk AI. AI penetration testing must cover both traditional and AI-specific vulnerabilities for compliance.

10. How does penetration testing compliance work for UAE organizations?

UAE organizations face NESA requirements for critical infrastructure operators (annual security testing), DIFC and ADGM regulatory expectations for financial institutions (security assessment proportionate to risk), and international framework requirements (ISO 27001, PCI DSS, SOC 2) for organizations operating globally. Multi-framework testing with UAE-specific reporting addresses local regulations alongside international standards.