Guidance IT/Security Expert PCI-DSS

PCI-DSS Penetration Testing Requirements

Last reviewed: April 29, 2026
Key Takeaways
  • Penetration testing is mandatory annually and after significant network or application changes per PCI-DSS Requirement 11.3; both external and internal scopes must be tested, with actual exploitation attempts required—vulnerability scanning alone is insufficient.
  • Testers must be qualified professionals using documented, comprehensive methodologies (OWASP or NIST-aligned); maintain evidence of certifications and independence, and retain all reports and findings under your control.
  • Remediation is a compliance obligation, not optional; establish timelines for fixing vulnerabilities (Critical/High within 30–90 days) and conduct documented retesting to prove closure before your annual assessment.
  • Significant changes to your cardhode environment trigger immediate retesting requirements; include this in your change management process to avoid compliance gaps and audit delays.
  • Document your entire penetration testing program—scoping, methodology, findings, remediation actions, and retesting evidence—as assessors will require detailed evidence of compliance with Requirement 11.3.

PCI-DSS Penetration Testing Requirements

Penetration testing is a cornerstone control in the Payment Card Industry Data Security Standard (PCI-DSS), designed to identify vulnerabilities before attackers do. For enterprise compliance professionals, understanding the specific requirements, scope, and execution standards is essential to maintaining audit readiness and demonstrating effective security posture to assessors.

Regulatory Foundation and Scope

PCI-DSS v4.0 Requirement 11.3 mandates penetration testing as a detective control across your cardholder data environment (CDE). This requirement explicitly states that organizations must "perform penetration testing at least once every 12 months and after any significant changes to the network or application, such as upgrades or patches, new functionality, or changes to network segmentation controls." The regulation recognizes that penetration testing serves as validation that technical and procedural defenses actually work in practice, not just in theory.

The scope of your penetration test must encompass both external and internal testing. External testing evaluates your perimeter defenses—firewalls, intrusion detection systems, and externally-facing applications. Internal testing simulates a compromised insider or lateral movement scenario, probing your network segmentation, access controls, and backend systems that handle payment data. Both dimensions are non-negotiable under PCI-DSS Requirement 11.3.1 and 11.3.2.

Testing Standards and Methodology

PCI-DSS Requirement 11.3.4 specifies that penetration tests must be "performed by qualified internal staff or qualified external third parties." The critical word here is "qualified." Your tester must demonstrate expertise in network penetration testing methodologies. The Council does not prescribe a specific framework, but the industry standard is the OWASP Testing Guide or NIST SP 800-115. Your assessor will verify that the methodology is comprehensive and documented, covering both network infrastructure and application-layer vulnerabilities.

Testing must include attempts to access or extract cardholder data (PCI-DSS 11.3.1). This means your penetration tester should actively attempt to compromise systems, escalate privileges, and reach restricted data stores. Passive vulnerability scanning alone does not satisfy this requirement. Your tester must execute actual exploitation techniques to demonstrate real-world risk.

Remediation and Evidence Management

Requirement 11.3.3 requires that organizations "address vulnerabilities identified during penetration testing and retest as needed." This is where many compliance programs falter. Simply running a test and filing the report creates significant compliance risk. You must:

Document all findings in a formal report that categorizes vulnerabilities by severity (Critical, High, Medium, Low). The report should include evidence of exploitation, business impact, and specific remediation steps.

Establish a remediation timeline. Critical and High severity findings should be addressed within 30-90 days, depending on your organization's risk tolerance. Medium and Low findings can be tracked in your regular patching and maintenance cycles, but you must demonstrate active tracking and closure.

Conduct rescans or retesting. After remediation, your tester or internal team should verify that vulnerabilities are actually closed. This evidence is mandatory for your PCI-DSS audit. Assessors will ask: "What did you find?" "What did you fix?" and "How do you know it's fixed?"

Frequency and Trigger Events

The annual requirement is a baseline. However, Requirement 11.3.2 adds critical context: you must also test "after any significant changes to the network or application." Significant changes include:

Major operating system or application upgrades, network architecture modifications, changes to network segmentation or firewall rules, implementation of new payment processing applications, and changes to authentication mechanisms or access controls. If you deploy a new payment gateway or modify your CDE boundaries, a new penetration test is required before the system goes live, not after.

Working with Qualified Testers

If using external testers, your contract should explicitly state that they will follow PCI-DSS testing standards and that you retain ownership of all findings and reports. Ensure your tester signs an NDA and agrees not to retain cardholder data or attempt unauthorized access beyond the agreed scope. Internal testers must have documented security training and no conflicts of interest (for example, a tester should not be responsible for systems they're testing, to maintain independence).

Request evidence that your tester is current on vulnerability research, holds relevant certifications (OSCP, CEH, GPEN), and maintains liability insurance. Many assessors will verify this directly during your audit.

Documentation for Your Assessor

Maintain a penetration testing portfolio that includes the scoping document, methodology, executive summary, detailed findings report, remediation evidence, and retesting confirmation. Your PCI-DSS assessor will review this as a core evidence artifact. Gaps here—missing retesting, unresolved findings, or lack of methodology documentation—can result in a failed audit or a conditional pass.

Regulations Referenced