PCI DSS penetration testing requirements, decoded

Most compliance frameworks imply penetration testing. PCI DSS names it outright. If you store, process, or transmit payment card data, the standard is unusually specific about what test you owe, how often, and to what methodology, which is good news: there is far less ambiguity to negotiate with an assessor. The controls live under Requirement 11.4, and here is what they actually demand.

Requirement 11.4: the anchor

In PCI DSS v4.0 (what was Requirement 11.3 in earlier versions), 11.4 is the control governing penetration testing. The future-dated parts of v4.0, including the strengthened methodology language, became mandatory on 31 March 2025, so this is current, not aspirational.

A documented methodology (11.4.1)

You need a defined penetration testing methodology based on an industry-accepted approach, with NIST's SP 800-115 named as an example. It must cover both the application and network layers, address the threats in Requirement 6, and define tester qualifications. An assessor will ask to see the methodology document, not just the results.

Frequencies you cannot fudge

• External penetration testing: at least once every 12 months, and after any significant change to infrastructure or applications.
• Internal penetration testing: at least once every 12 months, and after significant changes.
• Significant change is the phrase that bites: a major upgrade, a new component in scope, or a network change can reset your clock before the year is up.

Segmentation testing (11.4.5), the commonly missed one

If you rely on network segmentation to keep systems out of your cardholder data environment, and so shrink your PCI scope, you must prove that segmentation actually holds. The standard requires testing the segmentation controls at least every 12 months (every six months for service providers), and it is explicit that a configuration review is not enough: the tester has to actively attempt to cross the segmentation boundary. This is where teams that assumed a firewall rule was sufficient get a surprise.

What an assessor wants to see

Beyond the test itself: the methodology document, evidence the scope matched your actual cardholder data environment, findings with severity and remediation, and proof that exploitable issues were corrected and re-tested. A scan export will not satisfy 11.4. The requirement is for a penetration test that proves exploitability, not a list of potential issues.

For PCI, that is the whole engagement: a methodology-driven test against your real cardholder-data scope, exploitable findings proven rather than listed, and the fixes re-tested before your assessor sees the report. Uvy delivers exactly that. See how it works.