PCI DSS penetration testing: what Requirement 11.4 asks for

What PCI DSS asks for, and where penetration testing fits

You need to regularly run pentests. Requirement 11.4 sits inside Requirement 11, Test Security of Systems and Networks Regularly. The section heading reads: "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." It breaks into seven sub-requirements, 11.4.1 through 11.4.7.

Before cadence, the standard asks for a documented approach. Requirement 11.4.1 states that "A penetration testing methodology is defined, documented, and implemented by the entity" and lists what it includes — among them "Coverage for the entire CDE perimeter and critical systems", "Testing from both inside and outside the network", "Testing to validate any segmentation and scope-reduction controls", "Review and consideration of threats and vulnerabilities experienced in the last 12 months", and "Retention of penetration testing results and remediation activities results for at least 12 months."

Internal and external penetration testing are handled separately and worded almost identically. Both state that testing is performed "Per the entity's defined methodology", "At least once every 12 months", and "After any significant infrastructure or application upgrade or change."

Two things are worth reading closely. The frequency is "at least once every 12 months" — a floor, and the standard's own words, which is not the same statement as a yearly event. And change is a separate trigger sitting alongside it, not a footnote to it. An environment that ships weekly meets the second condition far more often than the first.

This is where PCI DSS is most often misread. Requirements 11.4.2 and 11.4.3 both state that testing is performed "By a qualified internal resource or qualified external third-party" and that "Organizational independence of the tester exists (not required to be a QSA or ASV)."

That parenthesis is in the standard, and it appears seven times across Requirement 11.4. PCI DSS does not ask for the penetration test to be performed by a QSA or an ASV. It asks for a qualified tester who is organisationally independent of the systems being tested. QSAs assess compliance; ASVs are separately named for the vulnerability scanning requirement, not for penetration testing. On qualifications the standard's guidance points to "Specific penetration testing certifications" and "Prior experience conducting penetration testing" as considerations, not as a defined bar.

Requirement 11.4.4 states that exploitable vulnerabilities and security weaknesses found during penetration testing are corrected "In accordance with the entity's assessment of the risk posed by the security issue", and then adds one line that changes the shape of the whole requirement: "Penetration testing is repeated to verify the corrections."

The test is not the deliverable. The verified fix is. A programme that produces a report and stops has met part of 11.4 and not the part that closes it.

Where segmentation isolates the CDE, the segmentation controls are tested too. For all entities, 11.4.5 states "At least once every 12 months and after any changes to segmentation controls/methods". For service providers, 11.4.6 states "At least once every six months and after any changes to segmentation controls/methods." Both ask for confirmation that the controls are "operational and effective, and isolate the CDE from all out-of-scope systems."

Multi-tenant service providers support their customers' external penetration testing per 11.4.3 and 11.4.4. It is the only sub-requirement in 11.4 that carried a future date: its applicability note read "This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment." That date has passed. 11.4.1 through 11.4.6 carried no such note and were effective immediately.

Strike is a continuous hybrid validation platform: AI-driven Threat Emulations with expert human validation before customer delivery. Against the shape of Requirement 11.4, three things line up.

Testing can be triggered by changes according to configured scope, which is the 11.4.2/11.4.3 change condition rather than a calendar. Findings are reproduced and confirmed before they reach you, at 97% precision / 3% false positives (Strike-reported — how we measure results), because a finding a QSA cannot follow is not evidence. And retesting — the 11.4.4 line — is part of the operating model rather than a separate engagement, though retesting availability depends on the subscribed scope.

Two honest limits. Coverage depends on authorised scope and access; a segmentation test under 11.4.5 or 11.4.6 has to be scoped deliberately, and it is a different exercise from perimeter testing. And Strike does not determine your compliance: Strike supports audit and compliance programmes and does not issue PCI DSS attestations. Sufficiency for 11.4 is your QSA's judgement.

Setup takes under 5 minutes on supported scopes, and the first curated findings arrive in 1–2 hours (both Strike-reported — how we measure results). Scoping and authorisation happen before that, and they are a separate clock from either number. To date, US$4.5B+ in risk mitigated (Strike-reported — how we measure results).

PCI DSS and penetration testing, answered

Does PCI DSS ask for an annual penetration test?

YES. The standard's wording is "At least once every 12 months", in Requirements 11.4.2 and 11.4.3. Both also name "After any significant infrastructure or application upgrade or change" as a separate condition, so twelve months is a floor rather than a schedule.

Does the penetration test have to be performed by a QSA?

No. Requirements 11.4.2, 11.4.3, 11.4.5 and 11.4.6 each state that testing is performed "By a qualified internal resource or qualified external third party" and that "Organizational independence of the tester exists (not required to be a QSA or ASV)."

Can our own team perform it?

The standard permits "a qualified internal resource", subject to organisational independence — the tester being separate from the management of the target systems. It does not define a certification bar; its guidance treats certifications and prior experience as considerations.

Is a vulnerability scan enough?

No. PCI DSS addresses scanning and penetration testing in different requirements. Requirement 11.4.1 asks the methodology to include "Application-layer penetration testing" and "Network-layer penetration tests", which a scan does not perform.

How often do service providers test segmentation?

Requirement 11.4.6, which applies only to service providers, states "At least once every six months and after any changes to segmentation controls/methods." For all other entities 11.4.5 sets twelve months.

Which version of PCI DSS is current?

PCI DSS v4.0.1, published June 2024. PCI SSC opened a request for comments on v4.0.1 in June 2026 as the starting point for the next iteration, and v4.0.1 remains the published version. No retirement date for v4.0.1 or publication date for a successor was found in the public materials reviewed on 29 July 2026.

Sources, accessed 29 July 2026. Requirement text quoted from PCI DSS v4.0.1 (June 2024), Requirement 11.4, as reproduced in the PCI DSS v4.0.1 Report on Compliance Template (PCI SSC). Current version confirmed against Request for Comments: PCI DSS v4.0.1 (PCI SSC, 3 June 2026). The standard itself is available from the PCI SSC Document Library and is released under a click-through licence agreement. Strike does not issue PCI DSS attestations and is not a QSA; this page summarises publicly available requirement text and is not legal or compliance advice. Sufficiency for Requirement 11.4 is determined by your assessor.