PCI DSS 4.0 and Penetration Testing – What You Need to Know

Summary

• PCI DSS 4.0.1 Requirement 11.4 mandates framework-aligned, human-led penetration testing, not just automated scanning.
• Scope must cover the full CDE perimeter, including cloud, hybrid, and API layers.
• Authenticated vulnerability scanning replaced unauthenticated black box scanning for internal networks.
• Segmentation validation testing is required annually for merchants and every six months for service providers.
• All findings, remediation, and re-test results must be retained for a minimum of 12 months.

Key Terms

• Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit payment card data or that are connected to those systems.
• Requirement 11.4: The PCI DSS control governing penetration testing methodology, scope, frequency, tester qualifications, and reporting.
• Authenticated scanning: Vulnerability scanning that uses valid system credentials to inspect patch levels, registry configurations, and internal software from inside the environment.
• Segmentation validation testing: Active technical testing performed to confirm that network segments designated as out-of-scope cannot reach or influence the CDE.
• Qualified Security Assessor (QSA): A company certified by the PCI Security Standards Council to assess an organization’s compliance with PCI DSS requirements.
• Re-testing: A mandatory verification step performed after remediation to confirm that previously exploitable vulnerabilities have been effectively resolved.

Understanding PCI DSS 4.0 Penetration Testing Requirements

The transitional period for PCI DSS 4.0.1 has passed. Organizations that treated v4.0.x as a future concern are now under audit scrutiny they may not have planned for.

Most of the public discussion around the update addressed new requirements at a conceptual level. That framing is useful orientation, but it sidesteps the harder question: what do the PCI DSS penetration testing requirements actually demand at the technical and operational level? For Requirement 11.4 specifically, the gap between understanding the intent and executing against the specifics is wider than most teams may realize.

What PCI DSS Requirement 11.4 Actually Mandates

Requirement 11.4 governs internal and external penetration testing. It carries forward from Requirement 11.3 under v3.2.1 with substantially tighter specifications. Running a penetration test is not sufficient on its own. To satisfy the Defined Approach, organizations must build, document, and implement a formalized testing methodology. Qualified Security Assessors will review that methodology directly, and only processes that can be clearly articulated will pass.

4 Areas That Define PCI DSS 4.0 Penetration Testing Requirements

PCI DSS 4.0 penetration testing requirements raise the bar for what QSAs expect to see in a report. Four areas determine whether an assessment holds up under that scrutiny.

Framework Alignment

Testing cannot follow an ad-hoc process. The methodology must align with an industry-recognized offensive security framework: NIST SP 800-115, OWASP Testing Guides, PTES, or OSSTMM. Framework selection should be documented and defensible, not retrofitted after the fact.

Scope and CDE Mapping

The testing boundary must encompass the full perimeter of the CDE and all associated critical systems. Cloud environments, hybrid architectures, APIs, and any digital system connected to or capable of influencing CDE security fall within scope. Partial scoping is one of the most common findings in failed assessments.

Dual-Perspective Attack Simulations

Testing must address both external and internal threat scenarios. External testing simulates an unauthenticated attacker probing internet-facing infrastructure: public IPs, remote access services, cloud-exposed endpoints, and firewalls. Internal testing simulates an attacker who has already achieved initial access and must now move laterally, escalate privileges, and attempt to reach the CDE from within trusted network zones.

Application-Layer Exploitation Requirements

Application testing must explicitly attempt to exploit specific vulnerability classes at a minimum: SQL injection, LDAP injection, XPath injection, cross-site scripting, broken access controls, authentication bypasses, and insecure API endpoints. Checklist-based testing that documents these categories without genuine exploitation attempts will not satisfy QSA scrutiny.

Meeting these four areas is what separates compliant penetration testing from random acts of security. That distinction carries more weight under PCI DSS 4.0 than ever before.

Penetration Testing vs. Vulnerability Scanning

A recurring point of confusion in PCI audits is conflating vulnerability assessments and penetration testing. Under PCI DSS 4.0, these are distinct controls governed by separate requirements with different technical execution rules.

• Requirement 11.3 (Vulnerability Scanning): Runs on a quarterly cycle, is largely automated, and must be performed by a PCI SSC Approved Scanning Vendor (ASV) for external assessments. Its objective is to identify known vulnerabilities, unpatched systems, and misconfigurations across the environment.
• Requirement 11.4 (Penetration Testing): Runs on an annual cycle at minimum, must be human-led, and must be performed by an independent and qualified tester. Its objective is active exploitation: determining whether an attacker can actually reach and compromise the CDE, not just whether known vulnerabilities exist.

This distinction matters for compliance. A clean vulnerability scan report does not satisfy a penetration testing requirement, and a penetration test report does not substitute for quarterly ASV scans. For guidance on how to prepare for compliant testing, see our guide on PCI DSS 4.0 and penetration testing.

Authenticated Scanning Is Now Mandatory in PCI DSS 4.0

One of the more significant changes in the PCI DSS 4.0 framework is the shift to authenticated vulnerability scanning for internal networks. The legacy 3.2.1 standard accepted unauthenticated black box scans, but that is no longer sufficient.

Internal scans must now provide scanning tools with valid system credentials or an authenticated pathway into the environment. Unauthenticated perimeter scans cannot see local patch levels, registry configurations, or internal software vulnerabilities. Authenticated scanning closes that visibility gap, which is exactly why QSAs require it.

Third-Party Service Providers (TPSP) Requirements

Requirement 12.8 PCI DSS 4.0 identifies third-party service providers (TPSPs) as any third party acting as a service provider on behalf of an entity. PCI DSS 4.0 requires entities bound by PCI DSS compliance to do their due diligence in ensuring that their TPSPs that either store, process, transmit account data, or manage in-scope system components on the entity’s behalf at least once every 12 months. Since TPSPs can impact the security of a customer’s CDE, it’s important that they are adhering to PCI DSS third-party security requirements.

If a TPSP has already certified their PCI DSS Compliance or undergone a PCI DSS Attestation of Compliance (AOC), TPSPs are required to provide documentation upon request to demonstrate their compliance with PCI DSS 4.0. Third party service providers can alternatively opt for on-demand, targeted assessments with each of its customers’ assessors to confirm that requirements are met. These assessments are more commonly referred to as vendor assessments in which a customer establishes the terms of a vendor assessment per their organization’s requirements.

Many organizations require their third-party service providers to undergo annual penetration testing exercises as a part of their vendor assessment process to ensure that the vendors that they choose to work with take the security and confidentiality of their data seriously. Requiring vendors to undergo vendor assessments reduces the risk of a data breach being caused by TPSPs, especially when there are integrations connected or a part of the CDE.

PCI DSS 4.0 Penetration Testing Frequency and Segmentation Validation

Under PCI DSS, penetration testing is not a once-a-year checkbox. Frequency requirements are tied to environmental change, not just the calendar.

Annual testing is the baseline. But any significant upgrade or change to infrastructure or applications within the CDE path triggers an immediate re-test requirement. Major OS upgrades, network architecture changes, firewall replacements, and new software releases in the CDE all qualify. Organizations that test annually, but make substantial infrastructure changes in between, are out of compliance during those intervals.

Segmentation validation carries its own, separate requirements. If an organization uses network segmentation to reduce CDE scope, that segmentation must be tested to confirm it actually works. Documented segmentation architecture is not validation. Active testing is.

Merchants must validate segmentation at least annually. Service providers face a more demanding standard: segmentation testing is required at least every six months under Requirement A1.1.4, as well as after any modification to logical separation controls. The test itself must technically demonstrate that traffic from out-of-scope networks cannot reach the CDE, through active port scanning, routing analysis, and explicit exploitation attempts across segment boundaries.

PCI DSS 4.0 Penetration Testing Reporting, Qualifications, and Retention Requirements

The penetration test report functions as primary technical evidence during a QSA review. What that report must contain is specific:

• Remediation and re-testing: If the test uncovers exploitable vulnerabilities, and a credible test generally will, the standard requires a documented risk-based remediation workflow followed by verified re-testing. A report showing open critical or high-severity findings without a completed re-test will result in a non-compliant assessment. The loop must close, and the evidence must show that it did.
• Tester independence: Internal resources can perform penetration testing, but organizational independence is non-negotiable. Internal testers must be completely separated from the management and administration of the systems they are testing. The same principle applies to third-party firms: the testing team must be independent of the environment under review.
• Tester qualifications: QSAs look for recognized certifications as evidence of tester competency. Credentials that carry weight include CREST accredited penetration testing, OSCP, CISSP, and CEH. The specific certifications matter less than the ability to demonstrate that testers have validated, applied expertise in offensive security, not just theoretical knowledge.
• Data retention: All penetration testing results, raw data, and documented remediation history must be retained for a minimum of 12 months. QSAs reviewing an organization’s current-year compliance posture need to confirm that the testing lifecycle has been continuously maintained, not just executed once before the audit.

What PCI DSS 4.0 Penetration Testing Requirements Mean for Your Testing Program

Organizations that have historically treated penetration testing as an annual box to check will find the PCI DSS 4.0 penetration testing requirements harder to satisfy than the previous standard. The requirement now governs how testing is scoped, who performs it, what they must attempt to exploit, how findings are remediated, and how long evidence is kept.

The teams that will have the fewest audit surprises are those that have already moved toward continuous validation, including programs where testing cadence, scope, and documentation are tied to actual change management cycles, not arbitrary annual schedules.

BreachLock is a certified, compliant penetration testing provider and a recognized leader in Penetration Testing as a Service (PTaaS). Supporting strong compliance and security outcomes for customers drives every one of our engagements.

• Final reports are audit-ready and map directly to the PCI DSS 4.0 standard, giving QSAs a clear view of your environment’s actual security posture.
• BreachLock’s Client Portal gives customers access to their results for a full 12 months, starting from the first day of the pen testing engagement.
• For third-party security, BreachLock helps customers obtain the Attestation of Compliance (AOC) required to meet third-party service provider requirements.
• BreachLock meets PCI DSS 4.0 TPSP requirements directly and undergoes annual testing to maintain SOC 2 Type 2 compliance.

Schedule a PCI DSS 4.0 discovery call to see how BreachLock can help you prepare for compliance.

Frequently Asked Questions about PCI DSS 4.0.1 Penetration Testing Requirements

What is the Cardholder Data Environment within the context of PCI DSS compliance?

The Cardholder Data Environment (CDE) refers to the specific people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, alongside any connected systems that can impact their security. To define the scope of a penetration test, an organization must map every asset that touches or influences this perimeter. Critical systems include firewalls, authentication servers, and applications that interface directly with payment flows.

What is the difference between an internal penetration test and an external penetration test?

An external penetration test targets an organization’s internet-facing assets from outside the network perimeter, whereas an internal penetration test simulates an attacker who has already gained a foothold inside the internal network. The external test focuses on bypassing perimeter defenses like firewalls and web application gateways to access the cardholder data environment. The internal test evaluates lateral movement, privilege escalation, and access control effectiveness from trusted network segments.

How often must an organization perform network segmentation validation testing?

Merchants must perform network segmentation validation testing at least once every 12 months, while service providers must conduct this testing at least once every six months. Organizations must also execute this validation after any significant change to logical separation controls or network architecture. The test requires a qualified professional to actively probe the boundaries and confirm that out-of-scope networks cannot communicate with the cardholder data environment.

When does an infrastructure or application change trigger a mandatory out-of-cycle penetration test?

A mandatory out-of-cycle penetration test is triggered whenever a modification impacts the security of the cardholder data environment or introduces new attack vectors into the network. Significant changes that require immediate testing include:

• Moving core payment applications or databases to a new cloud environment or physical data center.
• Replacing primary network security controls such as perimeter firewalls, file integrity monitoring tools, or web application firewalls.
• Upgrading operating systems, network protocols, or database management systems that handle transaction data.
• Reconfiguring network segmentation boundaries or access control lists that isolate payment environments.

What technical criteria must an internal resource meet to conduct a compliant PCI penetration test?

To conduct a compliant test, an internal resource must possess documented testing expertise, hold relevant technical certifications, and maintain complete organizational independence from the target systems. The tester cannot be involved in the daily administration or management of the networks, firewalls, or applications being evaluated. Qualified internal testers typically hold recognized offensive certifications such as CREST Penetration Testing qualifications or the Offensive Security Certified Professional (OSCP) designation.

How must an organization address exploitable security weaknesses discovered during a compliance penetration test?

Organizations must remediate identified vulnerabilities using a documented, risk-based approach and perform a formal re-test to verify that each exposure is closed. The remediation process follows a specific compliance lifecycle:

1. Document the technical findings, assigned severity levels, and root causes of the vulnerabilities.

2. Prioritize patches, configuration changes, or code fixes based on the risk posed to account data.

3. Apply the technical remediation measures across all affected systems in the cardholder data environment.

4. Engage the qualified penetration tester to perform an active re-test confirming the flaw can no longer be exploited.

5. Retain both the initial test report and the successful re-test report for at least 12 months.

Author

BreachLock Labs