PCI DSS
7 min read
PCI DSS Penetration Testing Requirements: Scope, Frequency, Methodology & Reporting
PCI DSS Requirement 11.4 mandates that organizations conduct both internal and external penetration testing to identify and address security vulnerabilities in their cardholder data environment. Penetration testing goes beyond automated vulnerability scanning by simulating real-world attacks to validate whether identified vulnerabilities can actually be exploited. This guide covers the complete penetration testing requirements under PCI DSS 4.0, including scope, methodology, frequency, and how testing results must be documented and remediated.
Table of Contents
PCI DSS Penetration Testing vs Vulnerability Scanning
PCI DSS requires both vulnerability scanning (Requirement 11.3) and penetration testing (Requirement 11.4), and understanding the distinction is critical for compliance. Vulnerability scanning is an automated process that identifies known vulnerabilities in systems and applications by comparing configurations and software versions against databases of known issues. ASV (Approved Scanning Vendor) scans are required quarterly for external-facing systems, and internal vulnerability scans must be performed at least quarterly as well. Penetration testing is a manual, targeted exercise where qualified testers attempt to exploit vulnerabilities to demonstrate real-world attack scenarios. While vulnerability scans identify potential weaknesses, penetration tests validate whether those weaknesses can actually be exploited to gain unauthorized access to cardholder data or the cardholder data environment. PCI DSS requires both because they serve complementary purposes. Scanning provides broad coverage and frequent detection of new vulnerabilities, while penetration testing provides depth by demonstrating the actual impact of vulnerabilities in the context of the organization's specific environment, network architecture, and security controls. Neither can substitute for the other, and organizations must perform both to maintain compliance.
- Vulnerability scanning is automated and identifies known vulnerabilities; penetration testing is manual and exploits them
- ASV scans are required quarterly for external systems; internal scans also quarterly
- Penetration testing validates whether vulnerabilities can actually be exploited in context
- Both scanning and penetration testing are required; neither substitutes for the other
- Scanning provides breadth of coverage while penetration testing provides depth of validation
Scope of PCI DSS Penetration Testing
PCI DSS 4.0 Requirement 11.4.1 specifies that penetration testing must cover the entire CDE perimeter and all critical systems. The scope must include all external network interfaces that could be used to access the cardholder data environment, all internal network segments that connect to or are part of the CDE, all application-layer boundaries between the CDE and out-of-scope networks, and all segmentation and scope-reducing controls. If network segmentation is used to reduce PCI DSS scope, Requirement 11.4.5 requires additional penetration testing specifically focused on validating that segmentation controls are operational and effective. This segmentation testing must confirm that out-of-scope networks cannot reach the CDE through any means. The scope of penetration testing must also include testing from both inside and outside the network. External testing simulates attacks from the internet targeting public-facing systems and applications. Internal testing simulates attacks from within the organization's network, representing scenarios such as a compromised insider, a malware infection on an internal workstation, or an attacker who has gained initial access to the internal network. Both perspectives are essential because the threat landscape includes external attackers, malicious insiders, and compromised internal systems.
- Testing must cover the entire CDE perimeter and all critical systems
- Segmentation controls must be separately tested to validate scope reduction
- Both external (internet-facing) and internal (inside-network) testing are required
- Application-layer boundaries between CDE and out-of-scope networks must be tested
- Internal testing simulates compromised insiders, malware, and post-exploitation scenarios
Frequency and Timing of Penetration Tests
PCI DSS 4.0 Requirement 11.4.1 requires penetration testing at least once every 12 months and after any significant change to the environment. Significant changes that trigger additional testing include new system installations, major infrastructure upgrades, changes to network topology or firewall rules affecting the CDE, operating system or application upgrades on CDE systems, changes to segmentation methodology, and modifications to encryption mechanisms protecting cardholder data. Under PCI DSS 4.0's targeted risk analysis approach, organizations may determine that more frequent testing is appropriate based on their risk profile. High-risk environments or organizations that make frequent changes may benefit from semi-annual or quarterly penetration testing. The timing of penetration tests relative to assessments is also important. Tests should be recent enough to reflect the current state of the environment. A penetration test performed 11 months ago may not accurately represent an environment that has undergone significant changes since then. Organizations should plan their testing calendar to ensure results are current at the time of their PCI DSS assessment and that any identified vulnerabilities have been remediated and retested before the assessment.
- Penetration testing is required at least every 12 months and after significant changes
- Significant changes include new systems, network topology changes, and encryption modifications
- Targeted risk analysis under PCI DSS 4.0 may indicate more frequent testing is needed
- Tests should be timed to ensure current results at the time of PCI DSS assessment
- Remediation and retesting of findings should be completed before the assessment
Methodology and Standards
PCI DSS requires that penetration testing follow an industry-accepted methodology. Requirement 11.4.1 specifically states that the testing methodology must cover the entire CDE perimeter and critical systems, include both network-layer and application-layer testing, and include testing from both inside and outside the network. Commonly accepted methodologies include the NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, the OWASP Testing Guide for web application testing, the PTES (Penetration Testing Execution Standard), and the CREST penetration testing guidance. The methodology must include reconnaissance and information gathering, vulnerability identification and analysis, exploitation of identified vulnerabilities, post-exploitation activities including privilege escalation and lateral movement, and documentation and reporting. Application-layer testing must include testing for the OWASP Top 10 vulnerabilities and other common web application security issues relevant to payment applications. Network-layer testing must include testing of network devices, operating systems, and services within scope. The testing must attempt to demonstrate actual exploitation of vulnerabilities, not merely identify them. A penetration test that stops at vulnerability identification without attempting exploitation does not meet PCI DSS requirements.
- Testing must follow an industry-accepted methodology such as NIST SP 800-115 or PTES
- Both network-layer and application-layer testing are required
- Application testing must cover OWASP Top 10 and payment-relevant vulnerabilities
- Testing must include exploitation attempts, not just vulnerability identification
- Post-exploitation activities including privilege escalation and lateral movement are required
Who Can Perform PCI DSS Penetration Testing
PCI DSS does not require penetration testing to be performed by an external third party, but the tester must be qualified and independent. Requirement 11.4.1 states that the tester must be a qualified internal resource or a qualified external third party. If internal resources are used, the tester must be organizationally independent from the environment being tested, meaning they should not be responsible for managing or maintaining the systems they are testing. The tester's qualifications should be documented and should demonstrate expertise in penetration testing methodologies, tools, and techniques. Recognized certifications that demonstrate penetration testing competence include OSCP (Offensive Security Certified Professional), GPEN (GIAC Penetration Tester), CEH (Certified Ethical Hacker), CREST certifications, and PNPT (Practical Network Penetration Tester). While certifications are not explicitly required by PCI DSS, they provide documented evidence of competence that assessors will evaluate. Many organizations choose to use external penetration testing firms for several reasons: independence from the environment being tested is easier to demonstrate, external testers bring diverse experience from testing many environments, and using a recognized firm can carry more weight during assessments. Organizations with mature security teams may use internal resources for routine testing and engage external firms for annual compliance tests.
- Internal resources or external firms can perform testing, but must be qualified and independent
- Internal testers must be organizationally independent from the environment being tested
- Recognized certifications (OSCP, GPEN, CEH, CREST) demonstrate competence to assessors
- External firms provide easier independence demonstration and diverse testing experience
- Tester qualifications must be documented and available for assessor review
Remediation and Retesting Requirements
When penetration testing identifies exploitable vulnerabilities, PCI DSS requires that findings be remediated and the remediation verified through retesting. Requirement 11.4.4 mandates that exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. There is no explicit timeframe mandated for remediation, but the expectation is that critical and high-severity findings are addressed promptly, and the remediation is verified before the next PCI DSS assessment. Organizations should establish a risk-based remediation timeline: critical findings that allow direct access to cardholder data should be addressed within days, high-severity findings within weeks, and medium and lower findings within a defined period based on the organization's targeted risk analysis. Retesting must confirm that the specific vulnerability has been effectively remediated, not just that a patch was applied. This typically involves the penetration tester re-executing the specific attack that previously succeeded and confirming it no longer works. The complete penetration test report should document all findings, their severity ratings, remediation actions taken, and retesting results. This documentation is essential for demonstrating compliance during the PCI DSS assessment and provides valuable evidence of the organization's security posture and remediation capabilities.
- Exploitable vulnerabilities must be remediated and verified through retesting
- Critical findings allowing CDE access should be addressed within days
- Retesting must confirm the specific exploit no longer succeeds, not just that a patch was applied
- Complete documentation of findings, remediation, and retest results is required
- Risk-based remediation timelines should be established and followed consistently
Key Takeaways
- PCI DSS requires both vulnerability scanning (automated, quarterly) and penetration testing (manual, annual)
- Penetration testing must cover the entire CDE perimeter from both internal and external perspectives
- Segmentation controls require separate penetration testing to validate scope reduction
- Testing must follow industry-accepted methodology and include exploitation, not just identification
- Testers must be qualified and independent, whether internal or external
- Exploitable findings must be remediated and verified through retesting
- Significant environmental changes trigger additional penetration testing requirements
Frequently Asked Questions
How often does PCI DSS require penetration testing?
PCI DSS requires penetration testing at least once every 12 months and after any significant change to the cardholder data environment. Significant changes include new systems, network topology changes, and modifications to segmentation controls.
Can I do PCI DSS penetration testing internally?
Yes. PCI DSS allows qualified internal resources to perform penetration testing, provided they are organizationally independent from the environment being tested. Internal testers should hold recognized certifications and their qualifications must be documented.
What is the difference between ASV scanning and penetration testing?
ASV scanning is automated vulnerability identification performed quarterly by an Approved Scanning Vendor on external-facing systems. Penetration testing is a manual, targeted exercise that attempts to exploit vulnerabilities to demonstrate real-world attack impact. Both are required by PCI DSS.
Does PCI DSS require application-layer penetration testing?
Yes. PCI DSS requires both network-layer and application-layer penetration testing. Application testing must cover OWASP Top 10 vulnerabilities and other security issues relevant to payment applications within the cardholder data environment.
What happens if penetration testing finds vulnerabilities?
Exploitable vulnerabilities must be remediated and the remediation verified through retesting. The retesting must confirm the specific exploit no longer succeeds. Critical findings should be addressed within days, with all findings documented including remediation actions and retest results.
Do I need to test segmentation controls?
Yes. If network segmentation is used to reduce PCI DSS scope, Requirement 11.4.5 requires additional penetration testing specifically focused on validating that segmentation controls are operational and that out-of-scope networks cannot reach the CDE.
Generate PCI DSS policies automatically
PoliWriter creates all the policies you need for PCI DSS compliance, customized to your organization. AI-powered, audit-ready, hours not months.
Get Started Free