Penetration Testing for PCI DSS Compliance: What You Need to Know (2026)

If your organisation processes, stores, or transmits payment card data, you are subject to the Payment Card Industry Data Security Standard (PCI DSS). Penetration testing is a core requirement of PCI DSS, and getting it wrong can result in compliance failures, fines, and increased transaction fees. Here is what you need to know.

PCI DSS Penetration Testing Requirements

PCI DSS Requirement 11.4 mandates regular penetration testing of both the internal and external network. The standard has specific expectations about scope, methodology, and frequency that go beyond a generic annual pen test.

As of PCI DSS v4.0.1, the key requirements are:

External penetration testing must be performed at least annually and after any significant change to the cardholder data environment (CDE). This tests your perimeter defences from the perspective of an external attacker.

Internal penetration testing is also required annually and after significant changes. This simulates a threat actor inside the network attempting to reach the CDE.

Application-layer testing must cover the vulnerabilities listed in PCI DSS Requirement 6.2, which aligns closely with the OWASP Top 10.

Network-layer testing must cover both the CDE itself and the systems that connect to or protect it.

Segmentation testing is critical. If you use network segmentation to reduce your PCI DSS scope, the penetration test must verify that segmentation controls are effective. This means testing whether an attacker on a non-CDE network segment can reach the CDE.

What "Significant Change" Means

PCI DSS requires retesting after "significant changes," but many organisations struggle with defining what qualifies. Generally, significant changes include installing new system components in the CDE, major changes to network architecture or firewall rules, upgrading or replacing critical software components, adding new network connections to or from the CDE, and changes to segmentation controls.

If in doubt about whether a change is significant, erring on the side of testing is the safer approach.

Scoping Your PCI DSS Pen Test

Correct scoping is essential. The penetration test must cover the entire CDE, including all systems that store, process, or transmit cardholder data. It must also cover any systems that connect to the CDE, systems that could affect the security of the CDE, and segmentation controls if you use network segmentation to limit scope.

Under-scoping is a common compliance failure. If your pen test does not cover the full CDE and connected systems, your QSA (Qualified Security Assessor) may flag it as insufficient during your PCI DSS assessment.

Methodology Requirements

PCI DSS v4.0 and 4.0.1 specify that the penetration test must follow a recognised industry methodology. Acceptable methodologies include NIST SP 800-115, OWASP Testing Guide, PTES (Penetration Testing Execution Standard), and CREST methodology.

The test must include both exploitation of vulnerabilities and, where possible, attempts to circumvent or defeat security features. Automated vulnerability scanning alone does not satisfy PCI DSS penetration testing requirements. Manual testing is essential.

The test must cover both network-layer and application-layer attacks. A test that only covers network infrastructure without testing applications, or vice versa, will not meet the requirement.

Choosing a Provider for PCI DSS Testing

Your penetration testing provider does not need to be a PCI QSA, but they should have demonstrable experience with PCI DSS testing requirements. Look for providers who explicitly mention PCI DSS penetration testing in their service offerings, can articulate the specific PCI DSS requirements and how their testing addresses them, hold CREST accreditation or equivalent, and can provide a report that maps findings to PCI DSS requirements.

Ask potential providers how they handle segmentation testing specifically. This is a common area of weakness, and a provider experienced in PCI environments will have a clear approach.

Report Requirements

Your pen test report needs to satisfy your QSA during your PCI DSS assessment. It should clearly state the scope of testing and confirm it covers the CDE, describe the methodology used, document all findings with severity ratings, include evidence of exploitation attempts, specifically address segmentation testing results, confirm whether the testing met PCI DSS Requirement 11.4, and provide remediation recommendations.

Common Pitfalls

Insufficient scope is the most common issue. Organisations often test only their external perimeter and miss internal network segments, connected systems, or segmentation controls.

Using vulnerability scanning as a substitute for penetration testing is another frequent problem. PCI DSS explicitly requires penetration testing with manual components. An automated scan is a different requirement (Requirement 11.3 for ASV scanning) and cannot substitute for pen testing.

Failing to retest after significant changes catches many organisations off guard. If you make a major change to your CDE and do not retest before your next assessment, you may face a compliance finding.

Not addressing findings promptly is risky. PCI DSS expects that identified vulnerabilities are remediated and retested. Having open critical findings at assessment time is a compliance issue.

Timing and Frequency

Plan your annual pen test to complete well before your PCI DSS assessment. This gives you time to remediate findings and retest. Many organisations schedule their pen test three to four months before their assessment date.

For segmentation testing specifically, PCI DSS v4.0 requires this to be performed at least every six months if you rely on segmentation to reduce scope. This is more frequent than the annual penetration test requirement.

Browse our compliance pages for more detail on PCI DSS requirements, or use our provider directory to find penetration testing companies with PCI DSS experience.