PCI DSS Penetration Testing Requirements: Requirement 11.4 Explained Line by Line

PCI DSS is the only major framework that tells you exactly what penetration testing it wants. Requirement 11.4 of PCI DSS v4.0.1 sets the methodology, the cadence, the scope, the independence of the tester, and the retest. This guide goes through it one sub-requirement at a time, then covers the parts the standard leaves to you: what “significant change” means, how segmentation testing differs from a normal test, and what your Qualified Security Assessor needs in the evidence.

If you want the whole standard in one place, start with our PCI DSS compliance checklist. For how we run the engagement, see PCI DSS penetration testing.

Requirement 11.4 at a glance

Sub-requirement	What it asks for	Cadence
11.4.1	A documented penetration testing methodology	Maintained continuously
11.4.2	Internal penetration test by a qualified, independent tester	Every 12 months and after significant change
11.4.3	External penetration test by a qualified, independent tester	Every 12 months and after significant change
11.4.4	Exploitable vulnerabilities corrected and the fix verified by retest	After every test
11.4.5	Penetration test of segmentation controls	Every 12 months and after changes to segmentation
11.4.6	Segmentation testing for service providers	Every 6 months and after changes
11.4.7	Multi-tenant service providers support customers’ external testing	Ongoing

11.4.1: the methodology

The standard requires a defined, documented and implemented penetration testing methodology that:

• is based on industry-accepted approaches (NIST SP 800-115 and PTES are the ones assessors expect to see named);
• covers the entire cardholder data environment perimeter and critical systems;
• tests from both inside and outside the network;
• validates any segmentation and scope-reduction controls;
• includes application-layer testing that, at minimum, covers the vulnerabilities listed in Requirement 6.2.4 (injection, cryptographic failures, broken authentication and access control, and the rest of the common application flaw classes);
• includes network-layer testing of all components that support network functions and operating systems;
• reviews and considers threats and vulnerabilities experienced in the last twelve months;
• documents the approach to assessing and addressing the risk posed by exploitable vulnerabilities found;
• retains test results and remediation activity for twelve months.

A vendor’s methodology document, or the methodology section of the report, satisfies this if it says these things and the test actually did them. Our methodology page is written to be handed to a QSA.

11.4.2 and 11.4.3: internal and external tests

Both are required at least once every twelve months and after any significant infrastructure or application upgrade or change. Both must be performed by a qualified internal resource or a qualified external third party, and the tester must have organizational independence from the systems being tested. Independence does not require an external firm, but it does mean the people who built and run the CDE cannot be the people who test it, which is why most merchants and service providers use an outside tester and file the tester’s qualifications with the report.

External means testing from outside the network against the CDE perimeter: internet-facing systems, remote access, the applications that touch cardholder data. Internal means testing from inside, with the access an attacker would have after compromising a workstation or a non-CDE segment, to see whether the CDE can be reached. Our external network and internal network engagements are scoped to these two sub-requirements respectively.

What counts as a “significant change”

PCI DSS leaves the definition to the entity, but the guidance and assessors are consistent on the kinds of change that trigger a test: a new or upgraded operating system or platform in the CDE, new network connections or firewall rule changes affecting CDE boundaries, a new payment application or a major version of one, migration to or between cloud providers, and changes to segmentation. Document the definition in your methodology, and document the decision each time a change happens, even when the decision is “no test needed.” Assessors ask for the record.

11.4.4: fix it and prove it

Exploitable vulnerabilities and security weaknesses found during testing must be corrected in accordance with your assessment of the risk (from 6.3.1), and the corrections must be verified by repeating the test. In practice this means the retest report is as much a piece of PCI evidence as the original. A test that ends with open critical findings and no retest is a test the QSA will write up. We include the retest in every engagement for this reason; see pricing.

11.4.5 and 11.4.6: segmentation testing

If you use network segmentation to keep systems out of PCI scope, you have to prove the segmentation works. Segmentation testing is different from a normal internal test: the tester starts in the out-of-scope segments and tries to reach the CDE through every path (network, shared services, jump hosts, management interfaces, cloud peering). Success means no path exists.

• Merchants: at least every twelve months and after any change to segmentation controls or methods.
• Service providers (11.4.6): at least every six months and after changes.

This is the sub-requirement most often missed, and the one most likely to fail a Report on Compliance, because it is easy to assume segmentation from the diagram and never test it from the wrong side.

11.4.7: multi-tenant service providers

If you host multiple customers on shared infrastructure, you have to support their external penetration testing, either by allowing them to test or by providing evidence of your own testing that covers their environment. Cloud and hosting providers write this into their customer agreements.

Requirement 11.3 is not 11.4

Requirement 11.3 requires internal vulnerability scans at least quarterly, and external scans at least quarterly by a PCI SSC Approved Scanning Vendor, with rescans until passing. Scans and penetration tests are separate requirements with separate evidence, and neither substitutes for the other. Our ASV scan vs penetration test guide explains the difference; our managed vulnerability scanning covers the internal side.

What the QSA wants in the evidence

1. The methodology document, or the methodology section of the report, covering the 11.4.1 list.
2. The internal and external test reports, dated within the assessment period, with scope that matches the CDE diagram.
3. The segmentation test report, with the starting segments and the paths tested named.
4. Tester qualifications and an independence statement.
5. Findings with severity, remediation, and the retest showing closure.
6. The record of significant changes and the testing decision for each.

Our report carries a PCI mapping section that cites each finding against its sub-requirement by number, plus an attestation letter with items 4 and 5 summarized on one page. The format is on the sample report page.

Frequently asked questions

Does PCI DSS require a specific certification for the tester? No. It requires that the tester is qualified, with experience in penetration testing, and organizationally independent. Your QSA decides whether the qualifications are sufficient.

Can our internal security team do the test? Yes, if it is organizationally independent of the CDE’s owners and operators. Many companies still use an outside firm to remove the question.

Does a web application firewall change the requirement? No. Requirement 6.4 covers application protection; 11.4 still requires application-layer penetration testing of the CDE.

Does using a hosted payment page remove the requirement? It reduces scope, sometimes to an SAQ A, but any system that could affect the security of cardholder data stays in scope, and your acquirer or QSA decides where the line sits.

How much does PCI penetration testing cost? Our fixed prices for the internal, external, application and segmentation components are on the PCI penetration testing cost page.

The short version

Requirement 11.4 wants a documented methodology, internal and external tests every year and after significant changes, a retest that proves the fixes, and segmentation testing on its own clock, all by a qualified tester who did not build the system. Get those six pieces of evidence right and the penetration testing section of the RoC writes itself. If you want it done at a published price, scope a PCI test.