PCI DSS 11.4 Penetration Testing: Requirements, Scope & Evidence

Quick answer: PCI DSS 11.4 penetration testing means testing your cardholder data environment (CDE) from the inside and the outside using a documented methodology, at least once every 12 months and after any significant change, fixing what is found, and retesting to prove the fixes worked. If segmentation is used to shrink PCI scope, the segmentation controls must be tested too.

If your business stores, processes or transmits payment card data, your assessor will ask for one document more often than almost any other: the penetration test report. Requirement 11.4 is the part of the standard that governs it, and it is also one of the easiest places to lose time in an audit, because the requirement is about more than "run a pen test once a year."

This guide explains PCI DSS 11.4 penetration testing in plain language: what each sub-requirement says, how often testing must happen, what has to be in scope, how segmentation testing works, and what evidence to hand your Qualified Security Assessor (QSA). If you are still choosing a provider, our PCI DSS penetration testing service page shows how Privaxi scopes and delivers these tests.

What Is PCI DSS 11.4 Penetration Testing?

PCI DSS 11.4 penetration testing is the set of controls in Requirement 11.4 of the Payment Card Industry Data Security Standard that require organizations to test their security defenses the way an attacker would. A penetration test goes beyond a vulnerability scan. A scan lists known weaknesses. A pen test tries to exploit them, chain them together and show what an attacker could actually reach.

Requirement 11 as a whole is titled "Test security of systems and networks regularly." Within it, 11.3 covers vulnerability scanning and 11.4 covers penetration testing. Both are needed. Passing one does not replace the other, a point we expand on in penetration testing in 2026: what it is and why a scan won't save you.

What Does Requirement 11.4 Actually Require?

PCI DSS v4.0 and v4.0.1 split Requirement 11.4 into several parts. Always confirm the wording against the current standard and with your QSA, but in summary the requirement breaks down like this:

The tester must be a qualified internal resource or a qualified external third party, and there must be organizational independence between the tester and the systems being tested. The tester does not need to be a QSA or an Approved Scanning Vendor.

How Often Is PCI Penetration Testing Required?

The answer has two triggers, and teams routinely miss the second one:

• Annually. Internal and external tests at least once every 12 months.
• After a significant change. A new payment application, a network redesign, a cloud migration or a change to segmentation all count. If you can describe the change as "significant," you should be asking whether it needs a retest before the next annual cycle.

Because the requirement is tied to change, many organizations find that an annual-only schedule leaves gaps. That is one reason teams look at continuous models such as penetration testing as a service, where external testing is repeated on a regular cadence and re-run when new hosts or services appear. A continuous model supports your testing program, but whether it satisfies a specific PCI requirement should always be confirmed with your assessor.

PCI Penetration Testing Requirements for Scope

Scope is where PCI DSS 11.4 penetration testing succeeds or fails. The methodology must cover the entire CDE perimeter and all critical systems, and testers must examine the environment from both inside and outside the network. Practically, that means your scope document should list:

• Every system that stores, processes or transmits cardholder data, plus systems that can affect the security of those systems (connected-to and security-impacting systems).
• Public-facing web applications and APIs that touch payment flows, tested at the application layer.
• Network devices, firewalls, VPN gateways and remote access paths into the CDE.
• Segmentation controls, if you use them to reduce PCI scope.
• Cloud-hosted components such as virtual networks, security groups and storage, if any part of the CDE runs there.

A narrow scope is the most common cause of a failed or reworked report: if the tester never touched a system the assessor considers in scope, the test will not be accepted as evidence for that system. Our guide to penetration testing scope walks through how to define it before you request quotes.

PCI DSS External Penetration Test vs Internal Penetration Test

Requirement 11.4 asks for both, and they answer different questions.

External penetration test

A PCI DSS external penetration test targets everything reachable from the internet: public IP addresses, web applications, APIs, VPN and remote access services, and email infrastructure. The question it answers is whether an outside attacker can get a foothold or reach the CDE. We explain the technique in more detail in our guide to external penetration testing.

Internal penetration test

An internal test starts from inside the network, often from a position that simulates a compromised workstation or an insider. It checks whether an attacker who is already inside can move laterally, escalate privileges and reach cardholder data. Internal testing is where weak segmentation, flat networks and over-privileged accounts usually appear.

PCI Segmentation Penetration Testing

Segmentation is the practice of isolating the CDE from the rest of your network so that fewer systems fall into PCI scope. It is a legitimate and common way to reduce audit effort and risk, but it comes with an obligation: you have to prove that the isolation actually works.

PCI segmentation penetration testing does that by attempting to cross the boundary from out-of-scope networks into the CDE, using the same techniques an attacker would. Under 11.4.5, this must happen at least once every 12 months and after any change to segmentation controls or methods. Service providers face a stricter cadence under 11.4.6, with testing every six months.

A successful segmentation test shows that traffic from out-of-scope segments cannot reach the CDE. A failed one is a finding with a real consequence, because the systems you thought were out of scope are now in scope and the assessment grows.

Vulnerability Scanning vs Penetration Testing for PCI

Teams sometimes assume that a clean quarterly scan covers 11.4. It does not. The two activities are separate requirements with different purposes:

How PCI DSS 4.0 Changed Penetration Testing

If your last assessment was under PCI DSS 3.2.1, the 4.0 generation of the standard tightened several things relevant to PCI DSS 4.0 penetration testing:

• The methodology requirement is more explicit, including documented approaches for assessing and addressing risks found, and a review of threats and vulnerabilities from the previous 12 months.
• Application-layer and network-layer testing are named separately.
• Segmentation testing is called out as its own requirement, with a separate, more frequent cadence for service providers.
• Multi-tenant service providers now have a defined obligation to support customers' external testing (11.4.7).
• Retesting after remediation is explicit in 11.4.4.

PCI DSS v4.0 was retired in favor of v4.0.1 at the end of 2024, and the requirements that were previously future-dated became mandatory from 31 March 2025. If you are preparing now, plan against the current version.

What Evidence Does a QSA Expect From a PCI Pen Test?

Passing the test is only half the job. You also need to be able to show it. Prepare a folder that contains:

1. The penetration testing methodology document (11.4.1), including the standards it follows, such as OWASP and NIST SP 800-115.
2. The scope statement, signed rules of engagement and the list of CDE systems and segmentation controls tested.
3. The final report with an executive summary, technical findings, severity ratings, exploit evidence and remediation guidance.
4. The tester's qualifications and a statement of independence.
5. Proof of remediation: change tickets, patch records or configuration evidence for every exploitable finding.
6. The retest report confirming that corrected issues no longer reproduce (11.4.4).
7. A record of the dates of testing and of any significant changes that triggered extra testing.

Retain results as your methodology and assessor require. A report with a clear remediation and retest trail is far easier to defend than a report with an open list of findings.

How to Prepare for a PCI DSS Penetration Test

1. Confirm your CDE boundary. Update the data flow and network diagrams before the test so the scope matches reality.
2. List every segmentation control. Firewalls, VLANs, security groups and access control lists should all be documented.
3. Provide test accounts. Authenticated testing of payment applications finds far more than anonymous testing.
4. Schedule around releases. Run the test after major changes land, not just before them.
5. Agree how findings are handled. Decide who owns remediation and how quickly critical issues are fixed.
6. Book the retest at the same time. It is cheaper and faster to plan retesting up front.

Cost depends heavily on scope and testing depth. Our breakdown of how much penetration testing costs explains the main drivers so you can compare quotes on equal terms.

Choosing a Provider for PCI Penetration Testing

Look for a provider that can show how its testing maps to Requirement 11.4 rather than one that sells a generic report. Ask whether the methodology is documented, whether segmentation testing is included, whether retesting is part of the price, and whether testers have experience with payment environments. Our guide to choosing a penetration testing company lists the questions worth asking.

If you also need help with the broader assessment, Privaxi's PCI DSS compliance services cover readiness and audit support alongside testing.

Frequently Asked Questions

What is PCI DSS 11.4 penetration testing?

PCI DSS 11.4 penetration testing is the testing required by Requirement 11.4 of the PCI DSS. It requires a documented methodology, internal and external penetration tests at least every 12 months and after significant changes, correction of exploitable findings with retesting, and segmentation testing if segmentation is used to reduce scope.

How often is penetration testing required for PCI DSS?

At least once every 12 months for both internal and external testing, and again after any significant infrastructure or application change. Segmentation controls must also be tested every 12 months, or every six months for service providers.

Is a vulnerability scan the same as a PCI penetration test?

No. PCI DSS treats them as separate requirements. Vulnerability scans (Requirement 11.3) identify known weaknesses at least quarterly, while penetration tests (Requirement 11.4) actively exploit weaknesses to show real impact.

What is PCI segmentation penetration testing?

It is testing that attempts to cross from out-of-scope networks into the cardholder data environment to prove that segmentation controls work. If it fails, the systems you assumed were out of scope become in scope.

Who can perform a PCI DSS penetration test?

A qualified internal resource or a qualified external third party with organizational independence from the systems tested. The tester does not have to be a QSA or an Approved Scanning Vendor.

Does PCI DSS require retesting after fixes?

Yes. Requirement 11.4.4 requires exploitable vulnerabilities to be corrected and the penetration testing repeated to verify the corrections.

Final Thoughts

Requirement 11.4 is manageable when you treat it as a repeatable process rather than a once-a-year scramble: document the methodology, define scope honestly, test inside and outside the network, prove segmentation, fix what is found and retest.

If you want testing that is built around the requirement and produces the evidence your assessor needs, talk to Privaxi about PCI DSS 11.4 penetration testing and book a scoping call.