What Requirement 11.4 demands of a penetration test — and why you searched for 11.3

Penetration testing is Requirement 11.4. It has been since PCI DSS v4.0 was published in March 2022. Requirement 11.3 in the current standard is vulnerability scanning: a different control, a different cadence, and in one of its sub-requirements a different category of provider entirely.

If the document in front of you cites 11.3 for penetration testing, it is written against PCI DSS v3.2.1. The standard's own version table retires v3.2.1 on 31 March 2024 and v4.0 on 31 December 2024. v4.0.1, published June 2024, is the only version whose retirement date is still "to be determined".

The Council filed the renumbering as a structure change: "Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headings". Most obligations survived intact under new labels. A statement of work citing 11.3 often describes the right work. It is still citing a number that no longer exists, in a document an assessor has to map.

The map, old number to new

Two rows in that table are traps.

Internal and external changed places. Under v3.2.1, 11.3.1 was the external test and 11.3.2 the internal one. Under v4.0.1 the order is reversed: 11.4.2 is internal, 11.4.3 is external. A report labelling its external section 11.4.2 out of habit has mis-mapped every finding in it, and that is a mapping an assessor checks first.

11.4 was already a number. In v3.2.1 it was intrusion detection and prevention, now 11.5.1. Searching a retired copy of the standard for "11.4" returns IDS and IPS, not penetration testing.

What 11.4 demands, sub-requirement by sub-requirement

11.4.1: the methodology, and it is the entity's

Nine elements, and the methodology must be "defined, documented, and implemented by the entity". A tester's proposal is not the entity's methodology. It covers industry-accepted approaches; the entire CDE perimeter and critical systems; testing from inside and outside the network; validation of any segmentation and scope-reduction controls; application-layer testing that finds at minimum the attack classes at Requirement 6.2.4; network-layer testing across all components supporting network functions and their operating systems; review of threats and vulnerabilities experienced in the last 12 months; a documented approach to assessing the risk posed by findings; and 12-month retention of results and remediation records.

Three of those arrived as clarifications when 11.3 became 11.4.1: entity ownership, the 12-month retention, and the documented risk-assessment approach. A methodology carried over from a v3.2.1 programme is likely to be missing all three.

The standard also defines the term people most often get wrong: "Testing from inside the network (or 'internal penetration testing') means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks." Internal is not "inside the CDE only".

11.4.2 and 11.4.3: internal and external

Identical conditions on both: per the entity's defined methodology; at least once every 12 months; after any significant infrastructure or application upgrade or change; by a qualified internal resource or qualified external third party; and organisational independence of the tester.

Twelve months is a floor. The clause that sets real cadence is "after any significant change", and the entity defines what counts as significant, then lives with that definition at assessment.

11.4.4: the retest is part of the requirement

Exploitable vulnerabilities and security weaknesses found during testing are corrected in accordance with the entity's own risk assessment as defined at Requirement 6.3.1, and "Penetration testing is repeated to verify the corrections." A report with open exploitable findings and no evidence of a repeat test does not satisfy 11.4.4, however good the testing was.

11.4.5 and 11.4.6: segmentation, and the six-month clock

If segmentation is used to reduce scope, it is tested at least every 12 months and after any change to the segmentation controls, covering every method in use, confirming they are "operational and effective, and isolate the CDE from all out-of-scope systems", and confirming the effectiveness of any isolation separating systems with differing security levels under Requirement 2.2.3.

For service providers, 11.4.6 imposes the same list at least once every six months. Their networks are larger and change more often, so a segmentation control is likelier to fail quietly. Two segmentation tests a year is a budget line that surprises providers who scoped to 11.4.5.

11.4.7: multi-tenant providers

A best practice until 31 March 2025 and mandatory since. A multi-tenant provider must either produce evidence of testing meeting 11.4.3 and 11.4.4 on the customer's subscribed infrastructure, or give the customer prompt access to test it themselves. The guidance leaves no room: "Multi-tenant service providers cannot forbid penetration testing."

Who is permitted to do the work

The standard answers this in the requirement text, not in guidance, and repeats it at 11.4.2, 11.4.3, 11.4.5 and 11.4.6:

"By a qualified internal resource or qualified external third party. Organizational independence of the tester exists (not required to be a QSA or ASV)."

The contrast sits one requirement above. 11.3.2, the quarterly external vulnerability scan, is the only control in Requirement 11 that names a provider category: "By a PCI SSC Approved Scanning Vendor (ASV)". It is also the only one marked "not eligible for the customized approach". Scanning and penetration testing are three separate requirements with no substitution between them.

The supplement you will be pointed at was written against a retired standard

v4.0.1 refers readers to the Information Supplement: Penetration Testing Guidance from 11.4.1, from 11.4.3, and again from Appendix A3. That supplement is version 1.1, September 2017, and its own front matter says: "The current version of PCI DSS at the time of publication is v3.2."

It shows. Its Appendix A quick-reference table is headed "PCI DSS 11.3.x Requirement". Its body reads "Per PCI DSS Requirements 11.3.1 and 11.3.2, penetration testing must be performed at least annually". Section 2.3.2 explains how to treat PA-DSS validated applications, and v4.0.1 records that programme as "retired in October 2022". Nothing in it covers 11.4.7, the customised approach, targeted risk analyses, or the six-month service-provider interval.

The practical rule: take report structure and evidence expectations from the supplement, and every requirement number from the standard. Sections 2.1 (why a scan is not a test), 2.6 (significant change), 5.2 (the report and retest outlines), 5.3 (evidence and retention) and 5.4 (the Report Evaluation Tool) still hold. The numbering, the coverage list and the applicability do not.

An 11.4 test is not a red team engagement

11.4.1 prescribes coverage: the entire CDE perimeter, critical systems, every segmentation method, application layer and network layer. Adversary simulation is scoped by objective and measures whether you detect and respond. Neither substitutes for the other: an engagement that reaches its objective by one path has, by design, not covered the perimeter 11.4.1 asks for.

What to change in your own documents

• Contract and scope language citing 11.3 for penetration testing: it is 11.4.
• Report section headings: internal is 11.4.2, external is 11.4.3.
• Segmentation testing as its own deliverable under 11.4.5, or under 11.4.6 twice a year if you are a service provider.
• A retest, evidenced, under 11.4.4.
• A methodology owned by the entity under 11.4.1, with results and remediation records retained 12 months.
• If you are a multi-tenant provider, a documented answer to 11.4.7: evidence, or access.

Getting the number right is the cheap half. The expensive half is a report whose scope, coverage and retest evidence survive the mapping. When they do not, that is what gets a PCI penetration test report rejected. Security Brigade delivers 11.4 testing as a network penetration testing engagement scoped and reported against these sub-requirement numbers.