PCI-DSS Penetration Testing: Requirements, Scope, and What Assessors Look For

PCI-DSS is one of the few compliance frameworks that explicitly requires penetration testing. There is no ambiguity, no "security testing or equivalent," and no room for interpretation. Requirement 11.4 mandates it. Your Qualified Security Assessor will ask for the report. If the report does not meet the standard's expectations, you will have a finding on your Report on Compliance.

And yet, organizations routinely fail the penetration testing requirement. Not because they skip it entirely, but because the scope is wrong, the methodology does not cover what PCI-DSS expects, or the report does not address the specific areas the QSA needs to validate. This guide covers exactly what PCI-DSS v4.0 requires from penetration testing, what your QSA is actually evaluating, and how to avoid the mistakes that cause compliance failures.

PCI-DSS v4.0 Penetration Testing Requirements: Requirement 11.4

PCI-DSS v4.0, which became mandatory on March 31, 2025, restructured and clarified the penetration testing requirements that previously lived under Requirement 11.3 in PCI-DSS v3.2.1. The requirements now sit under Requirement 11.4, and they are more explicit about what testing must cover.

Here is what Requirement 11.4 specifies at a high level:

• 11.4.1: A penetration testing methodology is defined, documented, and implemented. The methodology must be based on an industry-accepted approach (such as NIST SP 800-115, OWASP Testing Guide, or PTES).
• 11.4.2: Internal penetration testing is performed at least once every 12 months and after any significant changes to infrastructure or applications.
• 11.4.3: External penetration testing is performed at least once every 12 months and after any significant changes.
• 11.4.4: Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, and testing is repeated to verify the corrections.
• 11.4.5: If segmentation is used to isolate the CDE from other networks, penetration testing is performed to verify that segmentation controls are operational and effective.
• 11.4.6: (Service providers only) Segmentation testing is performed at least once every six months and after any changes to segmentation controls or methods.

The key word in every sub-requirement is "defined." PCI-DSS v4.0 wants documentation at every step. Your methodology must be documented. Your scope must be documented. Your retesting must be documented. The QSA is not just checking that you ran a pentest; they are checking that you have a repeatable, documented process around it.

Internal vs. External Penetration Testing

PCI-DSS requires both internal and external penetration testing, and the distinction matters. These are not interchangeable, and performing only one will result in a compliance gap.

Why Internal Testing Matters More Than You Think

Many organizations focus their security budget on external defenses and treat internal testing as an afterthought. In the PCI-DSS context, this is backwards. The standard explicitly requires internal testing because the most devastating breaches start from the inside, whether through compromised credentials, a phishing attack that gives an attacker a foothold, or a malicious insider.

Internal penetration testing for PCI-DSS should specifically cover:

• Lateral movement from non-CDE networks to the CDE. Can an attacker on a corporate workstation pivot into the cardholder data environment? If segmentation is supposed to prevent this, the pentest must verify it.
• Privilege escalation within CDE systems. Can a low-privilege user on a CDE system escalate to administrator or root access? Can they access cardholder data they should not be able to see?
• Access to stored cardholder data. Can the tester reach databases, file shares, or application backends that store PAN, track data, or authentication data?
• Exploitation of internal services. Internal services often have weaker security postures than external-facing ones. Unpatched systems, default credentials, and insecure protocols are common findings.

Scoping the Cardholder Data Environment

Getting the scope right is the single most important factor in a successful PCI-DSS penetration test. Scope it too narrowly and your QSA will reject the report. Scope it too broadly and you are spending money testing systems that do not matter for compliance. The CDE definition drives everything.

What Is the CDE?

The Cardholder Data Environment encompasses all people, processes, and technologies that store, process, or transmit cardholder data, plus any systems that are directly connected to or that could impact the security of those systems. In practice, this means:

• Systems that directly handle cardholder data: payment terminals, payment applications, databases storing PAN, transaction processing servers, and encryption/decryption systems.
• Systems connected to the CDE: any system that has network connectivity to systems in the CDE, even if they do not directly process cardholder data. This includes management servers, monitoring systems, DNS servers, and Active Directory controllers that service CDE systems.
• Security-impacting systems: firewalls, IDS/IPS, authentication servers, logging infrastructure, and any system whose compromise could affect the security of the CDE.

Scoping Mistakes That Cause Failures

• Excluding connected-to systems. Organizations frequently scope their pentest to only include systems that directly touch cardholder data. But PCI-DSS defines the CDE to include connected systems. If your Active Directory server authenticates users who access the CDE, it is in scope. If your monitoring server collects logs from CDE systems, it is in scope.
• Not including all payment channels. If you accept payments through a website, a mobile app, and in-store terminals, all three channels are in scope unless you can demonstrate complete segmentation between them. Testing only the website leaves two-thirds of your payment infrastructure unvalidated.
• Ignoring third-party connections. Vendor connections into your CDE, such as payment processor links, managed service provider access, or cloud service integrations, are in scope. If a third party has a network path into your CDE, your pentest needs to evaluate that boundary.
• Assuming tokenization removes everything from scope. Tokenization can significantly reduce scope, but only if implemented correctly. The tokenization system itself, the token vault, and the point where PAN is initially captured are still in scope. Organizations that assume tokenization eliminates the CDE entirely are in for a difficult conversation with their QSA.

Network Segmentation Testing

If your organization uses network segmentation to reduce PCI-DSS scope, Requirement 11.4.5 requires that you specifically test the effectiveness of that segmentation. This is not optional. If you claim segmentation reduces your scope, you must prove it works.

What Segmentation Testing Involves

Segmentation testing is distinct from general penetration testing. It specifically validates that systems outside the CDE cannot reach systems inside the CDE through any network path. The testing must verify:

• No unauthorized network paths exist between CDE and non-CDE segments. This includes checking for misconfigured firewall rules, VLAN hopping vulnerabilities, and routing misconfigurations that could allow traffic to traverse segments.
• Segmentation controls block all unauthorized protocols and ports. It is not sufficient for the firewall to block HTTP if it allows SSH or RDP through. Every protocol must be verified.
• Out-of-band access paths are tested. Management networks, backup networks, and monitoring connections can inadvertently bridge segmented environments. These paths must be tested.
• Bidirectional testing is performed. Segmentation must be effective in both directions. Traffic should not be able to flow from non-CDE to CDE or from CDE to non-CDE through unauthorized paths.

Service Provider Requirements: Semi-Annual Testing

If you are a service provider, Requirement 11.4.6 mandates segmentation testing at least every six months, not annually. This increased frequency reflects the higher risk that service providers represent in the payment ecosystem. Service providers must also retest segmentation after any changes to segmentation controls or methods, regardless of when the last scheduled test occurred.

Application-Layer Testing Requirements

PCI-DSS penetration testing is not just about network infrastructure. Requirement 11.4 explicitly requires application-layer testing for any custom or bespoke applications that are part of the CDE. This means your payment applications, web applications that handle cardholder data, APIs that transmit payment information, and any custom software involved in the payment process.

What Application-Layer Testing Must Cover

PCI-DSS v4.0 references the OWASP Top 10 and requires that application-layer testing address, at a minimum, the following areas:

• Injection vulnerabilities: SQL injection, command injection, LDAP injection, and any other injection attack that could compromise cardholder data or the underlying system.
• Authentication and session management flaws: weak password policies, session fixation, insecure session tokens, and authentication bypass vulnerabilities.
• Cross-site scripting (XSS): reflected, stored, and DOM-based XSS that could be used to capture cardholder data or session tokens.
• Insecure direct object references and broken access control: can a user access another user's payment information? Can a standard user perform administrative actions?
• Security misconfigurations: default credentials, unnecessary services enabled, verbose error messages that leak information, and insecure HTTP headers.
• Sensitive data exposure: is cardholder data transmitted in cleartext? Is PAN stored unencrypted? Are encryption keys properly managed?
• API security: authentication, authorization, rate limiting, input validation, and data exposure through API endpoints that handle payment data.

If your organization uses a third-party payment application (such as an off-the-shelf POS system), the application itself may be validated under PA-DSS or the PCI Software Security Framework. However, your configuration and deployment of that application is still in scope for penetration testing. A validated application deployed insecurely is still a vulnerability.

Frequency Requirements: Annual and After Significant Changes

PCI-DSS requires penetration testing at two distinct triggers:

Annual Testing

Both internal and external penetration testing must be performed at least once every 12 months. The testing must fall within your current assessment period. If your QSA comes for your annual assessment and your most recent pentest report is 14 months old, it will not satisfy the requirement, even if it was valid for the previous assessment period.

After Significant Changes

Penetration testing must also be performed after any "significant change" to the environment. PCI-DSS v4.0 provides guidance on what constitutes a significant change, but the definition ultimately depends on the organization's change management process and risk assessment. Common triggers include:

• Infrastructure changes: new network segments, firewall rule changes affecting the CDE, new servers or services in the CDE, migration to a new data center or cloud provider.
• Application changes: major version upgrades to payment applications, new payment channels, significant code changes to applications that handle cardholder data.
• Architectural changes: changes to segmentation controls, new third-party connections to the CDE, changes to encryption methods or key management.
• Organizational changes: mergers or acquisitions that introduce new payment processing systems, changes to payment processor relationships.

What the QSA Actually Looks for in Your Pentest Report

Your QSA is not a casual reader. They are reviewing your penetration test report against a specific set of criteria defined in the PCI-DSS ROC (Report on Compliance) Reporting Template. Here is what they are verifying:

1. Documented Testing Methodology

The QSA will check that your penetration test follows a documented, industry-accepted methodology. Acceptable methodologies include NIST SP 800-115, the OWASP Testing Guide, PTES (Penetration Testing Execution Standard), and CREST methodologies. The report must reference the methodology used and demonstrate that the testing followed it systematically. A report that reads like ad-hoc vulnerability scanning will not pass.

2. Complete CDE Coverage

The QSA compares the pentest scope against your documented CDE. Every system, application, and network segment in the CDE must be covered. If your network diagram shows 15 systems in the CDE and the pentest report only references 8, the QSA will ask about the missing 7. The report must explicitly list all in-scope assets and confirm that they were tested.

3. Both Network-Layer and Application-Layer Testing

A pentest that only covers network infrastructure is insufficient. A pentest that only covers web applications is also insufficient. PCI-DSS requires both. The QSA will verify that the report includes network-layer testing (port scanning, service enumeration, vulnerability exploitation, lateral movement) and application-layer testing (OWASP Top 10 coverage, authentication testing, authorization testing, business logic testing).

4. Testing from Both Inside and Outside the Network

The QSA will verify that external testing was performed against all public-facing CDE assets and that internal testing was performed from within the network. If the report only shows external testing, the QSA will flag the gap. Some organizations try to submit two separate reports from two different vendors, one for external and one for internal. While this is acceptable, it is cleaner and more cost-effective to have a single vendor cover both perspectives.

5. Segmentation Validation

If your scope is reduced through segmentation, the QSA will specifically look for segmentation testing results. They will verify that the testing confirmed the segmentation is effective and that no unauthorized paths exist between the CDE and out-of-scope networks. Missing segmentation validation is one of the most common reasons QSAs reject pentest reports.

6. Remediation and Retesting Evidence

For any exploitable vulnerabilities found, the QSA wants to see evidence that they were remediated and retested. PCI-DSS Requirement 11.4.4 explicitly states that "exploitable vulnerabilities and security weaknesses found during penetration testing are corrected and testing is repeated to verify the corrections." A report that lists findings but includes no retesting evidence is incomplete.

7. Tester Qualifications

The QSA will verify that the penetration testing was performed by a qualified individual or organization. PCI-DSS v4.0 requires that the tester be "qualified" and notes that this can be demonstrated through industry certifications (OSCP, GPEN, CEH, CREST), relevant experience, or organizational accreditation. Internal teams can perform the testing, but organizational independence must be maintained, meaning the tester cannot be responsible for the systems being tested.

Common PCI-DSS Pentest Failures and How to Avoid Them

Having worked with organizations across multiple industries on PCI-DSS compliance, these are the failure patterns we see most frequently:

• Submitting a vulnerability scan report as a pentest. This is the most common failure. Vulnerability scanning (automated tools like Nessus or Qualys) and penetration testing are fundamentally different activities. A vulnerability scan identifies potential weaknesses. A penetration test attempts to exploit them. PCI-DSS requires both, and they are assessed under different requirements. A scanner output is not a penetration test report.
• No retesting after remediation. Finding vulnerabilities is only half the requirement. PCI-DSS 11.4.4 requires that exploitable findings be corrected and retested. If your report shows five critical findings and no retest results, the QSA cannot confirm that the vulnerabilities were actually fixed. Always budget for at least one round of retesting.
• Scope mismatch with the CDE diagram. The QSA will compare your pentest scope against your CDE network diagram and data flow diagrams. If the pentest tested different systems than what your documentation shows as in-scope, that is a finding. Ensure your pentest provider has your current CDE documentation before scoping the engagement.
• Missing segmentation testing. Organizations that rely on segmentation to reduce scope but do not test the segmentation are guaranteed a finding. The QSA cannot accept a reduced scope without evidence that the segmentation actually works. This is a separate testing activity that must be explicitly included in the engagement.
• Pentest performed by the team that manages the CDE. Even if your internal security team has the skills to perform a penetration test, PCI-DSS requires organizational independence. The person testing the CDE cannot be the same person responsible for maintaining it. Either use a third-party firm or ensure your internal team structure provides clear separation of duties.
• Report lacks methodology documentation. A pentest report that jumps straight to findings without describing the methodology, tools, and approach will not satisfy a thorough QSA. The methodology section is not optional. It demonstrates that testing was systematic and comprehensive, not just opportunistic.

ASV Scanning vs. Penetration Testing: Requirement 11.3 vs. 11.4

One of the most frequent points of confusion in PCI-DSS is the difference between ASV scanning and penetration testing. They are separate requirements, serve different purposes, and are not interchangeable.

Both requirements must be satisfied independently. Passing your quarterly ASV scans does not satisfy the penetration testing requirement, and a clean penetration test does not exempt you from ASV scanning. Think of ASV scanning as your ongoing health check and penetration testing as the annual comprehensive exam.

Internal Vulnerability Scanning (Requirement 11.3.1)

In addition to external ASV scanning and penetration testing, PCI-DSS also requires internal vulnerability scanning at least quarterly (Requirement 11.3.1). Internal scans can be performed by qualified internal staff or a third party and do not need to be performed by an ASV. However, internal vulnerability scans are still not a substitute for internal penetration testing. Scanning identifies potential vulnerabilities. Penetration testing validates whether they are exploitable and assesses the actual risk.

Working with Your Pentest Vendor for PCI Compliance

Choosing the right penetration testing vendor for PCI-DSS is not the same as choosing a vendor for general security testing. The engagement needs to be structured specifically for PCI compliance, and your vendor needs to understand what the QSA expects.

What to Look for in a PCI Pentest Vendor

• PCI-DSS experience. Your vendor should have specific experience performing penetration tests for PCI-DSS compliance, not just general penetration testing. Ask for sample reports redacted for confidentiality. The report format should clearly map to PCI-DSS requirements.
• Qualified testers with relevant certifications. OSCP, GPEN, GWAPT, CREST, or equivalent certifications demonstrate that the individuals performing the testing have validated skills. Ask which certifications the assigned testers hold.
• Methodology documentation. The vendor should be able to provide their testing methodology before the engagement begins. It should reference an industry-accepted framework and cover both network and application layers.
• Retesting included in scope. Do not accept an engagement that does not include retesting. You will almost certainly have findings that need remediation verification. Retesting should be included in the base engagement price, not billed as an expensive add-on.
• Willingness to work with your QSA. A good PCI pentest vendor will engage directly with your QSA if needed, answer questions about methodology or findings, and adjust the report if the QSA requires additional detail.
• Segmentation testing capability. If you use segmentation to reduce scope, confirm that your vendor can perform segmentation validation testing. Not all pentest firms have the network expertise to properly test segmentation controls.

Before the Engagement: What to Provide Your Vendor

To ensure your PCI pentest is scoped correctly and covers everything the QSA needs, provide your vendor with the following before testing begins:

• CDE network diagram showing all systems that store, process, or transmit cardholder data, plus connected-to and security-impacting systems.
• Data flow diagrams showing how cardholder data moves through your environment, including all entry points, processing points, storage locations, and third-party connections.
• Asset inventory of all in-scope systems, including IP addresses, hostnames, application URLs, and the function of each system.
• Segmentation documentation if you are using segmentation to reduce scope, including firewall rules, VLAN configurations, and network architecture.
• Previous pentest reports so the vendor can verify that previously identified findings have been remediated and can look for regression.
• QSA contact information so the vendor can coordinate with your assessor on scope if needed.

PCI-DSS 4.0 Changes That Affect Pentest Requirements

PCI-DSS v4.0 introduced several changes that directly impact how penetration testing must be performed. If you were compliant under v3.2.1, do not assume your existing process will satisfy v4.0 without review.

Customized Approach

PCI-DSS v4.0 introduces the "customized approach" as an alternative to the traditional "defined approach." Under the customized approach, organizations can meet the intent of a requirement through alternative means, provided they can demonstrate equivalent or better security outcomes. For penetration testing, this means an organization could theoretically propose a different testing methodology or frequency if they can demonstrate it meets the requirement's objective. However, in practice, most QSAs expect traditional penetration testing, and the customized approach requires significantly more documentation and justification. For most organizations, following the defined approach for Requirement 11.4 is the path of least resistance.

Authenticated Internal Vulnerability Scanning

While not a penetration testing requirement per se, PCI-DSS v4.0 Requirement 11.3.1.2 introduces authenticated internal vulnerability scanning as a best practice until March 31, 2025, after which it becomes mandatory. This means internal scans must use credentials to log into systems and identify vulnerabilities that are not visible to unauthenticated scans. This change often surfaces additional findings that should be included in the scope of subsequent penetration testing.

Multi-Tenant Service Provider Requirements

PCI-DSS v4.0 adds new requirements for multi-tenant service providers (Requirement 11.4.7, effective March 31, 2025). Service providers that host multiple customers must support their customers' penetration testing and provide evidence that logical separation between tenant environments is effective. If you are a multi-tenant service provider, your penetration testing must validate tenant isolation, and you must be prepared to make testing evidence available to your customers and their QSAs.

Targeted Risk Analysis for Testing Frequency

PCI-DSS v4.0 introduces the concept of targeted risk analysis (Requirement 12.3.1) to determine the frequency of certain security activities. While the minimum frequency for penetration testing remains annual, organizations are expected to perform a risk analysis to determine whether more frequent testing is warranted based on their threat landscape, rate of change, and previous findings. Your QSA may ask to see this risk analysis as part of the assessment.

Building a PCI-DSS Penetration Testing Program

Rather than treating penetration testing as an annual compliance checkbox, organizations that consistently pass PCI-DSS assessments build a structured, repeatable testing program. Here is what that looks like:

Annual Planning

• Q1: Review and update the CDE scope, network diagrams, and data flow diagrams. Engage your pentest vendor and begin scoping the annual test. Coordinate timing with your QSA so the report falls within the assessment period.
• Q2: Conduct the annual penetration test (internal, external, and segmentation if applicable). Remediate findings and schedule retesting.
• Q3: Complete retesting to verify remediation. Address any residual findings. This gives you a clean report well before your annual assessment.
• Q4: Submit the final pentest report to your QSA as part of the annual assessment. Review findings trends against previous years. Update your penetration testing methodology documentation for the next cycle.

Change-Triggered Testing

In parallel with the annual cycle, maintain a process for evaluating whether changes to your environment trigger a penetration testing requirement. This process should be documented in your change management procedures and should include clear criteria for what constitutes a "significant change" in your environment. When a change meets the threshold, engage your vendor for a targeted test focused on the affected systems.

Continuous Improvement

Track your findings over time. Are the same types of vulnerabilities appearing year after year? If so, you have a systemic issue that needs to be addressed through training, process improvements, or technology changes. Your QSA will look favorably on organizations that demonstrate a downward trend in findings over multiple assessment periods, as it shows that the testing program is driving actual security improvement, not just checking a compliance box.

Frequently Asked Questions

Can we use our internal security team for PCI-DSS penetration testing?

Yes, but with conditions. The testers must be qualified (through certifications, training, or demonstrated experience) and must have organizational independence from the CDE they are testing. This means the person performing the test cannot be responsible for managing, administering, or securing the systems being tested. Many organizations find it simpler and more defensible to use a qualified third party.

How long does a PCI-DSS penetration test typically take?

The duration depends on the size and complexity of the CDE. A small e-commerce environment might require 5 to 7 days of testing. A large enterprise with multiple payment channels, extensive infrastructure, and complex segmentation could require 3 to 4 weeks. Retesting typically adds 1 to 3 additional days depending on the number of findings.

What happens if we fail the penetration test?

There is no pass or fail in the traditional sense. A penetration test identifies vulnerabilities. What matters for PCI-DSS is how you respond. Exploitable vulnerabilities must be remediated and retested (Requirement 11.4.4). As long as you remediate findings and can demonstrate through retesting that they are resolved, the initial findings do not cause a compliance failure. The failure scenario is when findings are identified and not remediated or retested.

Do we need to pentest systems managed by our payment processor?

Generally, no. Systems managed entirely by your payment processor fall under their PCI-DSS compliance, not yours. However, the connection points between your environment and the processor's environment are in your scope. Your pentest should test the security of those integration points, including the network connection, API authentication, data transmission encryption, and access controls on your side of the boundary.

Is a pentest required for SAQ merchants?

It depends on the SAQ type. SAQ A and SAQ A-EP merchants generally do not have a penetration testing requirement if they fully outsource payment processing and meet the eligibility criteria. SAQ C and SAQ D merchants do have penetration testing requirements. If you are unsure which SAQ applies to your environment, consult your acquirer or QSA. Getting the wrong SAQ type is a common source of compliance issues.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.