How to Prepare for PCI DSS 4.0 Penetration Testing Requirements

Summary

• PCI DSS 4.0.1 requires organizations handling cardholder data to run internal and external pentests at least annually, correct exploitable findings, and test segmentation controls every 12 months.
• Multi-tenant providers face added requirements for logical separation testing.
• Preparation, including clear scope, stakeholder alignment, and a remediation plan, determines whether the test delivers real security value or only a compliance artifact.

Key Terms

• Payment Card Industry Data Security Standard (PCI DSS): A security framework governing how organizations protect cardholder data.
• Cardholder Data Environment (CDE): The systems, networks, and processes that store, process, or transmit cardholder data.
• Requirement 11.4: The clause in PCI DSS 4.0.1 governing penetration testing methodology, scope, and remediation.
• Internal pentesting: Testing conducted from inside the CDE and from trusted and untrusted internal networks.
• External pentesting: Testing conducted against the CDE’s exposed perimeter from outside the network.
• Segmentation testing: Validation that controls isolating the CDE from other networks are actually holding.

What PCI DSS 4.0 Penetration Testing Requirements Mean for Your CDE

PCI DSS 4.0.1 doesn’t just tell organizations that they need to conduct pentesting. It tells them how often, from which vantage points, what to do with the results, and how long to store records of them. That level of specificity is new, and it’s exactly why so many security teams are re-scoping their testing programs before their next assessment window.

Released in June 2024, PCI DSS v4.0.1 is the current version of the standard. It applies to any organization that accepts, processes, or stores cardholder data, or that could otherwise affect the security of the CDE.

What Requirement 11.4 Actually Specifies

Requirement 11.4 defines the core obligation that organizations must regularly pentest and correct the exploitable vulnerabilities and weaknesses that testing uncovers. The sub-requirements spell out what “regularly” and “correct” mean in practice.

• Requirement 11.4.1 calls for a defined, documented methodology for simulating real attacks. That methodology has to cover the full CDE perimeter and every critical system in scope. In addition, results have to be retained for at least 12 months.
• Requirement 11.4.4 puts teeth on the findings by mandating that exploitable vulnerabilities get corrected according to the organization’s risk assessment process.
• Requirement 11.4.5 adds an annual check on segmentation controls, which are the barriers that keep the CDE isolated from the rest of the network.

Multi-tenant service providers carry two additional obligations.

• Requirement 11.4.7 requires supporting customers who need to run their own external pentests.
• Requirement A1.1.4 requires confirming every six months that the logical controls separating customer environments actually hold steady.

The standard also draws a sharper line than earlier versions between internal and external testing. Internal pentesting covers the CDE itself and the trusted and untrusted internal networks that connect into it. External pentesting covers the CDE’s exposed perimeter, the parts of the network reachable from public infrastructure. Both are required, at least annually, and both need to reflect the organization’s documented methodology. The tester running them should carry industry standard pentesting credentials and field experience, not just a scanning tool and a checklist.

Why Doesn’t Vulnerability Scanning Meet PCI DSS 4.0 Penetration Testing Requirements

PCI DSS 4.0.1 is explicit that vulnerability scanning alone doesn’t satisfy the pentesting requirement. A scanner flags individual weaknesses, but a human tester goes a step further by chaining them together the way an actual attacker would, moving through layers of defense that look solid in isolation but fail in sequence. That chaining is where the real risk usually lives, and it’s the piece automation still can’t fully replicate.

Proper Pentest Scoping Determines the Value

A pentest run without adequate preparation can still check the compliance box, but it rarely produces findings worth acting on. The organizations that get real value out of PCI DSS penetration testing treat scoping and preparation as part of the methodology.

That starts with thorough scope documentation, including in-scope assets, explicit exclusions, and testing depth. Documenting these before testers have access anything helps both focus the engagement and prevent unintended downtime on systems. The approach to PCI DSS 4.0 and penetration testing itself should be chosen deliberately rather than defaulted into, whether that’s white-box, black-box, or gray box penetration testing.

Internal alignment matters just as much as technical scope. IT, security, DevOps, and the business units that own tested systems need to agree on goals, timelines, and expectations before the engagement starts. Testers need an accurate, current asset inventory to test meaningfully, which is where an attack surface management solution earns its keep. Recent, verified backups of in-scope systems limit the potential damage in the case that something unexpected happens mid-test.

After testing is complete, the engagement isn’t finished when the report lands. The real value comes from what happens next. A structured remediation and retesting plan, one that prioritizes findings based on actual business risk rather than severity scores alone, helps security teams focus on the issues that matter most. Retesting then verifies that vulnerabilities have been properly addressed, turning a penetration test from a point-in-time assessment into a measurable improvement in security posture.

Meeting PCI DSS 4.0 Penetration Testing Requirements with BreachLock

Regularly testing and monitoring networks was one of the original 12 goals of PCI DSS, and it remains one of the harder ones to execute well at scale. BreachLock’s continuous, PCI DSS-focused pentesting is built around that specific problem. We accelerate testing timelines by up to 50% and cut total cost of ownership by the same margin, without reducing the depth that makes a pentest worth it.

BreachLock’s in-house PCI DSS experts scope engagement thoroughly and use the BreachLock Unified Platform to consolidate findings across the entire attack surface. That gives security teams contextual, real-time visibility into the attack paths that actually matter, so the CDE stays protected continuously. Request a demo today to get started.

FAQs about PCI DSS 4.0 Penetration Testing Requirements

How often does PCI DSS 4.0.1 require penetration testing?

PCI DSS 4.0.1 requires both internal and external penetration testing at least once every 12 months. Internal pentesting covers the cardholder data environment (CDE) itself along with the trusted and untrusted internal networks connected to it. External pentesting covers the CDE’s exposed perimeter, meaning the parts of the network reachable from public infrastructure. Segmentation controls that isolate the CDE from other networks also require testing on the same 12-month cycle under Requirement 11.4.5.

Why does PCI DSS require penetration testing instead of relying on vulnerability scanning alone?

Vulnerability scanning identifies individual weaknesses, but it doesn’t show how those weaknesses connect into a working attack path. A human tester chains vulnerabilities together the way a real attacker would, moving through layers of defense that look secure in isolation but fail when combined. That chaining behavior is the main gap automated scanning tools don’t close, which is why PCI DSS 4.0.1 treats pentesting and vulnerability scanning as separate, non-substitutable requirements.

What additional penetration testing requirements apply to multi-tenant service providers?

Multi-tenant service providers carry two requirements beyond the standard pentesting obligations. Requirement 11.4.7 requires the provider to support customers who need to run their own external penetration tests against the environment. Requirement A1.1.4 requires the provider to confirm, every six months, that the logical controls separating one customer’s environment from another are still effective.

How long must an organization retain PCI DSS penetration test results?

Organizations must retain penetration test results for at least 12 months under Requirement 11.4.1. This retention period applies to the documented findings from both internal and external testing conducted under the organization’s defined methodology.

What should an organization do before starting a PCI DSS penetration test?

Preparation should cover four areas before testing begins:

1. Document in-scope assets, explicit exclusions, and testing depth to focus the engagement and avoid unintended downtime.

2. Choose a testing methodology, either white-box, black-box, or gray-box.

3. Align IT, security, DevOps, and relevant business units on goals, timelines, and expectations.

4. Provide testers with a current asset inventory and confirm recent, verified backups of in-scope systems.

A remediation and retesting plan should also be in place, so findings translate into an actual reduction in risk.

Author

BreachLock Labs