Security Audit Standards

PCI DSS Penetration Testing Requirements: What You Need to Know in 2026

Let's Get One Thing Straight Right Away

Penetration testing is not the same as vulnerability scanning. I can’t tell you how many business owners I’ve spoken with who assume running an automated scan once a quarter checks the box for PCI compliance. It doesn’t.

A vulnerability scan is automated and identifies potential weaknesses. A penetration test, on the other hand, involves a live person actively digging into the complexities of your network, attempting to exploit vulnerabilities to see how far they can actually get. One identifies holes; the other proves they can be exploited.

With PCI DSS v4.0.1 now fully in effect (all future-dated requirements became mandatory in March 2025), the expectations around penetration testing have become significantly more rigorous. If you’re responsible for PCI compliance at your organization, here’s everything you need to know about the penetration testing requirements.

PCI DSS Penetration Testing Requirements

What Exactly Does PCI DSS Require for Penetration Testing?

The core requirement is found in PCI DSS Requirement 11.4, which mandates that organizations perform regular penetration testing to identify and correct exploitable vulnerabilities and security weaknesses. This is not a suggestion—it is mandatory for all entities that store, process, or transmit cardholder data.

Key Penetration Testing Requirements:

Annual Testing FrequencyPerform internal and external tests annually and after major scope changes.

Documented MethodologyFollow industry-accepted testing methodologies (OWASP, NIST, PTES, OSSTMM).

Tester IndependenceTesters must be independent and not responsible for system management.

Segmentation TestingValidate that segmentation controls isolate the CDE from out-of-scope networks.

Evidence RetentionRetain test logs, reports, and remediation evidence for at least 12 months.

Application & Network TestingPerform both application-layer and network-layer testing.

The Big Shift Under PCI DSS v4.0.1

The transition from v3.2.1 to v4.0.1 brought several critical changes that compliance teams must implement:

1. Requirement 11.4.1 (Formal Methodology)

Organizations must now formally define, document, and implement a penetration testing methodology that is based on industry-accepted standards. The testing scope must cover the entire CDE perimeter, all critical systems, and evaluate security controls from both inside and outside the network.

2. Stricter Multi-Tenant Service Provider Mandates

Multi-tenant service providers must now conduct segmentation testing twice per year (every six months) rather than annually. They are also required to support customer external pentests and document all lateral movement tests.

3. Expanded Infrastructure Scope

The scope under v4.0.1 explicitly includes cloud environments, serverless applications, container orchestrators, and CI/CD build pipelines (e.g. GitHub Actions, GitLab CI, Azure DevOps). If a component can affect CDE security, it must be included in the pentest scope.

Frequency: When and How Often?

At a minimum, PCI DSS requires testing at least once a year. However, organizations must perform testing after any "significant change".

Trigger 01

Infrastructure Upgrades

Replacing boundary firewalls, adding core databases, or migrating workloads to cloud platforms.

Trigger 02

Data Flow Changes

Modifying network paths or system configurations handling Primary Account Numbers (PAN).

Trigger 03

New Payment Software

Adding new point-of-sale systems, major OS updates, or new merchant API integrations.

Trigger 04

Network Topology Changes

Altering CDE boundary firewalls, routing rules, or network segmentation rules.

Trigger 05

Segmentation Controls

Modifications to access control lists (ACLs) or segmentation configurations.

Trigger 06

Service Provider Rules

Service providers must test segmentation controls at least every six months.

Understanding the Scope of a PCI Penetration Test

One of the most common audit failures is scoping a test too narrowly. Your pentest must target the complete cardholder data environment (CDE) boundary:

CDE Perimeter & Infrastructure

Includes all network-layer and host-layer components within the CDE boundary—such as firewalls, switches, application servers, and file stores.

Applications and APIs

Covers web applications, public APIs, client login dashboards, checkout checkout portals, and custom web services handling PAN or CVV.

Connected & Security Systems

Systems that can impact the security of the CDE—such as identity providers (Active Directory/Okta), deployment pipelines, and backup databases.

Segmentation Controls

Verifying that out-of-scope zones have zero network-layer connectivity to the systems within the CDE boundary.

What Makes a Valid Penetration Test?

Industry Methodologies: Must follow OWASP, NIST SP 800-115, OSSTMM, or PTES standards.
Manual Testing: Simulated attacks chaining exploits, bypassing security tools like a live hacker.
Application-Layer Testing: Evaluates business logic, access control, and injection flaws.
Retesting and Remediation: Post-audit checks verifying that all discovered security bugs are closed.

Segmentation Testing: Scope Verification

If your organization uses network segmentation to decrease PCI DSS audit scope, you must run segmentation tests. These tests attempt to compromise systems in the CDE from out-of-scope segments.

Testers verify firewall configuration rules, access control lists, and routing interfaces to prove that networks designated as "out-of-scope" have zero communication capabilities with sensitive cardholder data.

Common Mistakes to Avoid

Scans vs. Penetration Tests

Automated vulnerability scans identify potential issues; penetration tests manually exploit them.

Narrow Application Testing

Auditing only web forms while ignoring APIs, cloud integrations, and admin networks.

Assuming Segmentation Works

Failing to validate firewall configurations under live attack scenarios.

Lack of Tester Independence

Relying on internal staff who configure and manage the systems to run the audit.

No Retesting After Changes

Migrating to new infrastructure or updating applications without running a new pentest.

Poor Audit Documentation

Failing to document testing scope, methodology, logs, and remediation efforts.

Practical Methodology Tips

Building a continuous vulnerability management pipeline simplifies validation audits:

Gap Assessment

Perform self-assessments to resolve compliance holes before QSAs perform audits.

Map Data Flows

Work with experienced architects to document CDE scopes and network connections.

Schedule Early

Run scans months in advance to ensure sufficient time to remediate and retest flaws.

Choose QSA Tutors

Select compliance-focused audit teams who understand real-world exploits.

Integrate Findings

Feed pentest reports into enterprise vulnerability management platforms.

Frequently Asked Questions

The Bottom Line

PCI DSS penetration testing isn’t about checking a box. It’s about proving that your payment environment can withstand a real attack. A penetration test simulates what an actual attacker would do—chain vulnerabilities together, move laterally through your network, and try to access sensitive cardholder data.

The standard has become more prescriptive, more comprehensive, and more demanding. But here’s the silver lining: organizations that take penetration testing seriously—using it not just to satisfy compliance but to genuinely strengthen their security posture—will not only pass their audits more easily but will also significantly reduce their breach risk.

Talk to a QSA Specialist Explore VAPT Services

Related Resources

Continue your research with these relevant guides and services.