PCI DSS Penetration Testing Requirements: What v4.0 Actually Demands

Penetration Testing Is Not Optional Under PCI DSS

PCI DSS has required penetration testing since version 1.0, but with the transition to v4.0 -- now mandatory since March 31, 2025 -- the requirements have become significantly more prescriptive about what constitutes an acceptable penetration test. The days of running an automated scanner, exporting its output, and calling it a penetration test are over.

Requirement 11.4 in PCI DSS v4.0 specifies detailed expectations for penetration testing methodology, scope, frequency, and tester qualifications. Organizations that process, store, or transmit cardholder data must meet every sub-requirement, and QSAs (Qualified Security Assessors) are trained to identify programs that check boxes rather than actually test security.

This article breaks down what Requirement 11.4 actually demands, the common audit findings that trip organizations up, and how to scope a penetration test that satisfies both the letter and the intent of the standard.

Requirement 11.4: The Specifics

PCI DSS v4.0 Requirement 11.4 is organized into seven sub-requirements. Each one addresses a different facet of the penetration testing program.

11.4.1 -- Penetration Testing Methodology

The organization must define, document, and implement a penetration testing methodology. This is not a suggestion to "have a process." The requirement explicitly states that the methodology must:

• Be based on an industry-accepted penetration testing approach
• Include coverage of the entire CDE (Cardholder Data Environment) perimeter and critical systems
• Include testing from both inside and outside the network
• Include validation of any segmentation and scope-reduction controls
• Define application-layer penetration testing that covers, at minimum, the vulnerabilities listed in Requirement 6.2.4
• Define network-layer penetration testing that covers all components supporting network functions as well as operating systems

The PCI Council cites several industry-accepted frameworks as examples:

NIST SP 800-115  — Technical Guide to Information Security Testing and Assessment
OWASP Testing Guide  — Application security testing methodology
PTES  — Penetration Testing Execution Standard
CREST  — Council of Registered Ethical Security Testers methodology

Your methodology does not need to adopt one of these frameworks verbatim, but your QSA will compare your documented approach against these standards. If your methodology lacks reconnaissance, exploitation, post-exploitation, and reporting phases, it will not pass muster.

11.4.2 -- Internal Penetration Testing

Internal penetration testing must be performed at least annually and after any significant infrastructure or application changes. "Significant changes" is defined broadly under PCI DSS v4.0 and includes:

• Network architecture modifications
• New system component installations
• Operating system or application upgrades
• Changes to firewall rules or access controls
• Product version changes or new integrations

The internal test simulates an attacker who has gained access to the internal network -- whether through a compromised employee workstation, a phishing attack, or a rogue insider. The tester should attempt to move laterally, escalate privileges, and reach the CDE from a starting position outside the cardholder data environment.

11.4.3 -- External Penetration Testing

External penetration testing follows the same frequency requirements as internal testing: annually and after significant changes. The external test evaluates the attack surface visible from the internet, targeting all externally facing systems in the CDE scope.

This is distinct from the ASV (Approved Scanning Vendor) vulnerability scans required by Requirement 11.3.2. Vulnerability scans identify known vulnerabilities through automated checks. Penetration tests exploit vulnerabilities, chain findings together, and assess real-world impact. Both are required. One does not substitute for the other.

For a deeper understanding of how automated scanning and penetration testing complement each other in a PCI compliance program, see our coverage of continuous scanning for PCI DSS.

11.4.4 -- Remediation and Retesting

All exploitable vulnerabilities discovered during penetration testing must be corrected and the corrections must be verified through retesting. This creates a closed-loop process:

1. Penetration test identifies exploitable vulnerabilities
2. Organization remediates each finding
3. Penetration tester retests to confirm remediation effectiveness
4. Retesting results are documented

Your QSA will look for evidence of this complete cycle. A penetration test report with critical findings and no corresponding retest report is an audit finding waiting to happen.

11.4.5 -- Segmentation Testing

If network segmentation is used to reduce PCI DSS scope, the penetration test must specifically validate that segmentation controls are effective. This means the tester must attempt to traverse segmentation boundaries and confirm that systems outside the CDE cannot reach cardholder data.

Segmentation testing is required:

• At least every six months (not annually -- this is more frequent than the general PT requirement)
• After any changes to segmentation controls or methods

This sub-requirement catches many organizations off guard. Segmentation testing is not the same as running a port scan across VLANs. It requires active attempts to bypass, tunnel through, or circumvent the controls that separate the CDE from the rest of the network.

11.4.6 -- Service Provider Segmentation Testing

Service providers that use segmentation to isolate individual customer environments must test segmentation controls at least every six months and after any changes. This applies to hosting providers, managed service providers, and any entity that operates shared infrastructure with logical segmentation between customers.

11.4.7 -- Multi-Tenant Service Provider Testing

New in v4.0, this requirement mandates that multi-tenant service providers support their customers' external penetration testing of the customer's environment. The provider cannot refuse a customer's request to test the customer's own instance of the shared service.

Application-Layer Testing Requirements

PCI DSS v4.0 Requirement 6.2.4 defines the minimum set of vulnerabilities that application-layer penetration testing must cover. These map closely to the OWASP Top 10 but are framed in PCI-specific language:

• Injection flaws (SQL injection, OS command injection, LDAP injection)
• Buffer overflows
• Insecure cryptographic storage
• Insecure communications
• Improper error handling
• Cross-site scripting (XSS)
• Improper access control (insecure direct object references, failure to restrict URL access)
• Cross-site request forgery (CSRF)
• Broken authentication and session management

A penetration test that focuses exclusively on network-layer testing and skips application-layer analysis will fail Requirement 11.4.1's mandate for coverage of the vulnerabilities in 6.2.4.

For organizations with custom payment applications, patient portals, or e-commerce platforms, this means the penetration tester must have application security expertise -- not just network and infrastructure skills.

Qualified Tester Requirements

PCI DSS v4.0 requires that penetration testing be performed by a qualified internal resource or qualified external third party. The standard defines "qualified" through several criteria:

• Organizational independence. The tester must be independent of the area being tested. An internal tester cannot test their own work. If the same team that built the payment application also penetration tests it, the QSA will flag this as a conflict of interest.

• Demonstrated competence. While PCI DSS does not mandate specific certifications, QSAs typically look for industry-recognized credentials such as OSCP, CREST CRT/CCT, GPEN, or GXPN. The tester should be able to demonstrate hands-on penetration testing experience, not just vulnerability scanning capability.

• Methodology adherence. The tester must follow the organization's documented methodology (per 11.4.1) and produce evidence that all required testing areas were covered.

Using an automated scanning tool without manual analysis does not satisfy the qualified tester requirement. The PCI Council has been explicit that penetration testing involves human analysis, creative exploitation, and scenario-based testing that automated tools cannot replicate.

Common PCI Audit Findings Related to Penetration Testing

Having reviewed hundreds of PCI assessments, these are the penetration testing gaps that QSAs flag most frequently:

Scope Gaps

The penetration test did not cover the full CDE. This happens when the pentest scope document excludes systems that the QSA later determines are in scope -- typically because the scoping exercise was performed by a different team than the one that defined the CDE boundary. Cross-referencing the pentest scope against the network diagram and data flow documentation required by Requirement 1.2 eliminates this issue.

No Segmentation Validation

The annual penetration test was performed, but segmentation testing was not performed separately at the six-month mark. Many organizations conflate the annual pentest with the semi-annual segmentation test. They are separate requirements with separate frequencies.

Automated Scan Repackaged as a Pentest

The "penetration test report" is clearly the output of an automated vulnerability scanner (Nessus, Qualys, or similar) with a cover page added. QSAs recognize scanner output. A penetration test report should document the tester's methodology, the attack chains attempted, the manual analysis performed, and the business impact of successfully exploited vulnerabilities.

Missing Retest Evidence

Findings were identified but there is no documentation that remediation was verified through retesting. The organization remediated the issues but never had the tester confirm the fixes were effective.

Stale Testing After Significant Changes

A major infrastructure change occurred mid-year -- a cloud migration, a new payment gateway integration, or a platform upgrade -- and no penetration test was performed afterward. The annual cadence only applies if no significant changes occur during the year.

Internal Testing Omitted

The organization performed external penetration testing but skipped internal testing, or vice versa. Both are required.

How to Scope a PCI-Compliant Penetration Test

Scoping is where most PCI penetration testing engagements go wrong. Getting the scope right before testing begins prevents wasted effort and audit findings.

Step 1: Define the CDE Boundary

Start with your current network diagram and cardholder data flow documentation (required by Requirements 1.2.3 and 1.2.4). Every system that processes, stores, or transmits cardholder data is in scope. Every system that directly connects to or provides security services to those systems is also in scope.

Step 2: Identify Connected Systems

Systems that share a network segment with the CDE, provide authentication services to CDE systems, or can initiate connections into the CDE are "connected-to" systems and must be included in the penetration test scope. Firewalls, DNS servers, Active Directory controllers, and jump hosts are common examples.

Step 3: Map Segmentation Controls

If you use segmentation to reduce scope, document every control that enforces the boundary: firewall rules, VLAN configurations, ACLs, and any logical separation mechanisms. These become explicit test targets for segmentation validation.

Step 4: Include All Application Layers

For each payment application, identify the full technology stack: web server, application framework, database, API integrations, and third-party libraries. The application-layer testing scope must cover every component that handles cardholder data.

Step 5: Define Significant Change Triggers

Document what constitutes a "significant change" for your environment and establish a process to trigger ad-hoc penetration testing when those changes occur. This is easier to define in advance than to argue about retroactively with your QSA.

Step 6: Engage the Right Tester

Select a penetration testing provider whose team has demonstrable PCI testing experience, relevant certifications, and a methodology that aligns with industry-accepted approaches. If you are evaluating whether your organization needs a penetration test, understanding the PCI requirements helps define the minimum acceptable engagement.

Integrating Penetration Testing with Continuous Monitoring

Penetration testing and continuous scanning serve different purposes, but they are most effective as complementary layers in a PCI compliance program.

Continuous scanning, as we cover in detail in our PCI DSS compliance scanning guide, provides ongoing visibility into your security posture between penetration tests. It catches configuration drift, certificate expirations, new open ports, and missing security headers in near real-time.

Penetration testing goes deeper. It identifies vulnerabilities that scanners cannot detect -- business logic flaws, multi-step attack chains, privilege escalation paths, and weaknesses that only become apparent through manual analysis.

Together, they satisfy the full spectrum of Requirement 11: continuous scanning handles 11.3 (vulnerability scanning), while penetration testing handles 11.4 (penetration testing). Neither replaces the other.

Understanding penetration testing methodology in detail helps you evaluate whether your current provider is delivering the depth of testing that PCI DSS demands.

Next Steps

If your organization processes payment card data and your penetration testing program has not been updated for PCI DSS v4.0, the gap between what you are doing and what your QSA expects is likely wider than you think.

Start by auditing your current penetration testing scope, methodology documentation, and retest records against the seven sub-requirements of 11.4. Identify where your program falls short and address those gaps before your next assessment.

Our Penetration Testing Scoping Wizard walks you through the process of defining the right scope for a compliance-driven penetration test, including PCI DSS-specific considerations. And our services team can help you design a testing program that satisfies Requirement 11.4 end to end.